| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
StackThread should not spin a tight loop – during periods of inactivity it should block for 25ms (see StackThread::getTimeTillNextProcessMS).
Note: there is a more efficient implementation of StackThread that removes this 25ms loop during periods of inactivity. It is called: InterruptableStackThread – it requires you to create a SelectInterruptor and to pass to both InterruptableStackThread and SipStack constructors.
Scott
From:
resiprocate-users-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-users-bounces@xxxxxxxxxxxxxxx] On Behalf Of Subramanian
Kasi Subramanian
Sent: Wednesday, January 30, 2008 9:26 PM
To: Byron Campen; Ali Ziad
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] SIP Registration Renewal/"Keep
Alive"
Hi guys
I'am having a similar problem. The main problem
for me seems to be the CPU usage when I run the Stackthread.
The only reason I used to stack thread is because the process loop(like the one
used in the basic call example) hogged cpu
since it was continuously spinning
How did you guys handle this problem.?
Thanks
Subbu
----- Original Message ----
From: Byron Campen <bcampen@xxxxxxxxxxxx>
To: Ali Ziad <aziad@xxxxxxxxxxxxxx>
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Sent: Wednesday, January 9, 2008 2:50:47 PM
Subject: Re: [reSIProcate-users] SIP Registration Renewal/"Keep
Alive"
Yeah, that's it, just make sure to call run after your stack
is
configured.
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 Campen
>
>
>> 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:7c2c4f86
>>> 6
>>> e
>>> 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
>>>
>>
>
>
-----Inline Attachment Follows-----
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.