reSIProcate

Mailing Lists

Source Code

< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate-users] SIP Registration Renewal/"Keep Alive"

I am integrating ReSIProcate into an existing application which has to
attend 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@xxxxxxxxxxxxxxx
Subject: 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 Campen


> DEBUG | 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: Digest
> username="ali_pc",realm="192.168.10.212",nonce="12844364358:7c2c4f866e 
> 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
>