-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx [mailto:resiprocate-
devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Sunitha Beeram
Sent: Wednesday, September 19, 2007 5:50 PM
To: David Thompson; Adam Roach
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] "opt" builds
Thanks David. I manage higher level state for my calls
which takes into account the callbacks from resip. So,
when I get an onTerminated() call back, I mark the state
approriately so no more resip calls are made.
>From what I could reconstruct in one case, this was the
sequence of exchange ( btw, I am using the latest resip
version 1.1 ):
1. Remote Server sends us a reInvite ; We send an answer
; we don't get back an ACK for it.
2. In the meantime, the client ends the call, causing
end() to be called on the session; resip returns with a
503 error code:
RESIP:TRANSACTION::TransactionState.cxx:1390:Ran out
of dns entries for 10.0.110.41. Send 503
RESIP:DUM::DialogUsageManager.cxx:1227:Got: SipResp:
503 tid=9efa891343ea7100 cseq=BYE / 2 from(wire)
RESIP:DUM::InviteSession.cxx:1466:InviteSession::dispatch
Terminated SipResp: 503 tid=9efa891343ea7100 cseq=BYE / 2
from(wire)
3. In almost the same second, I see this:
RESIP:DUM::InviteSessionHandler.cxx:25:InviteSessionHandl
er::onAckNotReceived
RESIP:DUM::ClientInviteSession.cxx:174:InviteSession::Ter
minated: end
It looks like this second call to end() was out of my
control ( may be I am holding onto some object longer
than needed here or missing something else..) - the
assertion fires anyway, causing a crash.
So, summarizing my issues:
A) Why is end() being called twice?
A) why is invoking end() twice being treated with an
assertion?
B) I expected assertions to be turned off in the 'opt'
build, so an assertion firing in production env is
unsettling.
Thanks,
~Sunitha
-----Original Message-----
From: David Thompson [mailto:mrdatman@xxxxxxxxx]
Sent: Wednesday, September 19, 2007 1:17 PM
To: Sunitha Beeram; 'Adam Roach'
Cc: 'Byron Campen';
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] "opt" builds
Sunitha, I've gotten around accidently calling an end
twice
by always checking the isTerminated() before I call
end().
David
-----Original Message-----
From: Sunitha Beeram [mailto:Sunitha.Beeram@xxxxxxxxxx]
Sent: Wednesday, September 19, 2007 3:00 PM
To: Adam Roach; David Thompson
Cc: Byron Campen;
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] "opt" builds
Hi,
Thanks for all the responses. I agree with the views
presented here. We had a resip assert earlier that
helped us
figure out a problem with our usage and it was
definitely helpful.
My follow-up question to my earlier post is this. I
have
run into a few instances where resiprocate has asserted
here:
ClientInviteSession.cxx:224:
Void ClientInviteSession::end(EndReason reason) .....
.....
case Terminated:
assert(0); <=====
break;
To me, this looks like a case where end has been
invoked
twice ( I have verified my usage of end() and I don't
think
am calling it twice; this happens when we are handling
a high
volume of calls and when the server initiated the
disconnect
- unfortunately I don't have any more traces/logs that
will
help me understand why this gets triggered so ). In
anycase,
without understanding much of the state transitions, I
can't
judge if the
assert() is called for. Can't resip handle this case
better?
It just makes me suspicious if asserts are being used
to bail
out of conditions that can probably still be handled
better....
Any help is understanding why resip is asserting on
line
224 will be really great!
Thanks,
~Sunitha
-----Original Message-----
From: Adam Roach [mailto:adam@xxxxxxxxxxx]
Sent: Wednesday, September 19, 2007 7:16 AM
To: David Thompson
Cc: 'Byron Campen';
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx;
Sunitha Beeram
Subject: Re: [reSIProcate] "opt" builds
David Thompson wrote:
Thank you for your thoughts and I agree with you.
In
production we
*shouldn't* ever get to the asserts in the first
place. In
my case, my
program will run into it once every couple of days,
and with a high
volume of other concurrent calls, I was attempting
to
not have the
entire program recycle due to the one anomaly (for
accounting reasons).
Even without the assert()s, though, it's likely to
dump
core
anyway. If the condition enforced by an assert() is
false,
you're probably going to end up dereferencing a null
or
stepping through a bad pointer in fairly short order.
BTW, am I correct in assuming the OPT build is the
best for final
production build?
I'm not certain that any thorough characterization of
the
resip stack with regards to compilation options has
been
undertaken recently enough to be relevant. If you're
concerned with
getting the most performance out of
resip, you
might want to spend some time tinkering around with
various
compile and link flags and profiling the resultant
code. You
also might consider purchasing Intel's Linux
compiler,
which
is largely gcc compatible and produces somewhat
faster
code than gcc.
<shameless-plug>
Alternately, if performance is a primary concern, you
might
check with Estacado Systems, which has a
performance-and-footprint
optimized,
commercially-supported
version of the resip stack that runs about 30% faster
than
the publicly-available resip code. See
<http://www.estacado.net/SIPBasis.html#foundation>
for
information.
(For full disclosure, I _am_ affiliated with Estacado
Systems).
</shameless-plug>
/a
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel