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
----- 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
>>>
>>
>
>