< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index | Next in Thread > |
Best regards, Byron Campen
Thanks Byron. Since my application has a lot going on in the main thread, a separate StackThread sounds like a good idea. Is this how it would work: On startup: : StackThread st(myStack); St.run();Then in my main application idle loop, I would call dumUac->Process () ?Thanks, Ali Ziad -----Original Message----- From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx] Sent: Wednesday, January 09, 2008 1:11 PM To: Ali Ziad Cc: resiprocate-users@xxxxxxxxxxxxxxx Subject: Re: [reSIProcate-users] SIP Registration Renewal/"Keep Alive" StackThread will give the stack its own thread, and this is generally the recommended way to use the stack. Since all communication into and out-of the stack is threadsafe, this should not upset the thread-safety of your app. Best regards, Byron CampenI am integrating ReSIProcate into an existing application which has toattend to other functions and cannot be held up for a long time waiting for SIP events. So, In my global application idle loop, I call the stack processing sequence with the minimal timeout of 1ms for the select, assuming I will revisit it within the second for the next avail message. int someInt=0; if (!uacShutdownHandler->dumShutDown) { FdSet fdset; stackUac->buildFdSet(fdset); int err = fdset.selectMilliSeconds(resipMin((int) stackUac->getTimeTillNextProcessMS(), 1)); assert ( err != -1 ); stackUac->process(fdset); while(dumUac->process()); } Spending too much time waiting here (50ms) was interfering with the RTP media timing. Is using StackThread a reliable/recommended approach? How does it interact with my DUM and Event handler classes? -ali -----Original Message----- From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx] Sent: Wednesday, January 09, 2008 11:08 AM To: Ali Ziad Cc: resiprocate-users@xxxxxxxxxxxxxxxSubject: Re: [reSIProcate-users] SIP Registration Renewal/"Keep Alive"It looks like the stack thread is being cycle-starved. Note the very long time between the sending of the second REGISTER request from DUM (at 10:00:33), and the next time the transaction state machine fires up (10:00:40), in the logs below. Are you using a StackThread to give cycles to the stack? Or are you using some other method? Best regards, Byron CampenDEBUG | 20080109-100033.000 | Sytech:ResipLib | RESIP:DUM | 2704 | DialogUsageManager.cxx:832 | SEND: REGISTER sip:192.168.10.212 SIP/2.0 Via: SIP/2.0/ ;branch=z9hG4bK-d8754z-216c1c5d9e22083a-1--- d8754z-;rport Max-Forwards: 70 Contact: <sip:ali_pc;rinstance=e5646707bb14480b> To: <sip:ali_pc@xxxxxxxxxxxxxx> From: <sip:ali_pc@xxxxxxxxxxxxxx>;tag=a70cf259 Call-ID: ZTM4NjgwYWQ3M2VlOTQxNDE2MmU1YTU5ZjExOWRjZDY. CSeq: 3 REGISTER Expires: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE Proxy-Authorization: Digestusername="ali_pc",realm="192.168.10.212",nonce="12844364358:7c2c4f86 6e 569c98 c2cf13c15744fb03",uri="sip: 192.168.10.212",response="e2831ec987ad218b7774b20 ae402516f",cnonce="04756c683133255f",nc=00000002,qop=auth- int,algorithm=MD5 Content-Length: 0 DEBUG | 20080109-100033.000 | Sytech:ResipLib | RESIP:DUM | 2704 | DialogId.cxx:50 | DialogId::DialogId: ZTM4NjgwYWQ3M2VlOTQxNDE2MmU1YTU5ZjExOWRjZDY.-a70cf259- DEBUG | 20080109-100033.000 | Sytech:ResipLib | RESIP:DUM | 2704 | DialogUsageManager.cxx:963 | Send: SipReq: REGISTER 192.168.10.212 tid=216c1c5d9e22083a cseq=REGISTER contact=ali_pc / 3 from(tu) DEBUG | 20080109-100033.000 | Sytech:ResipLib | RESIP | 2704 | SipStack.cxx:307 | SEND: SipReq: REGISTER 192.168.10.212 tid=216c1c5d9e22083a cseq=REGISTER contact=ali_pc / 3 from(tu) DEBUG | 20080109-100040.437 | Sytech:ResipLib | RESIP:TRANSACTION | 2704 | TimerQueue.cxx:85 | Adding timer: Timer F tid=216c1c5d9e22083a ms=32000 DEBUG | 20080109-100040.437 | Sytech:ResipLib | RESIP:TRANSPORT | 2704 | TransportSelector.cxx:275 | Looking up dns entries for sip: 192.168.10.212 DEBUG | 20080109-100040.437 | Sytech:ResipLib | RESIP:DNS | 2704 | DnsResult.cxx:221 | DnsResult::lookup sip:192.168.10.212 DEBUG | 20080109-100040.437 | Sytech:ResipLib | RESIP:DNS | 2704 | DnsResult.cxx:405 | Numeric result so return immediately: [ V4
Attachment:
smime.p7s
Description: S/MIME cryptographic signature