| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
|
Looks good and tested without
any issues. -Aron From: Scott Godin
[mailto:slgodin@xxxxxxxxxxxx] Hi Aron, I made an additional fix for 4xx
level retry errors that happen mid-dialog. The code used to create a new
dialog (ie. makeNewSubscription) – this doesn’t seem right to me - I modified
the code to just call requestRefresh instead. New complete diff/patch
attached. If I don’t hear from anyone on
why mRemoteTarget (ie. Remote Contact header) was used on retries – then
I will commit this fix, that includes removal of that as well. To all - Please review
this patch and provide feedback. Scott From: Aron Rosenberg
[mailto:arosenberg@xxxxxxxxxxxxxx] Scott, I tested your patch combined with
my patch and I no longer get the crash or the issue with empty to/from values.
Attached is the combined patch against ClientSubscription.cxx -Aron From: Scott Godin
[mailto:slgodin@xxxxxxxxxxxx] In this case onNewSubscription
was never called, so there shouldn’t be a onTerminated callback. Scott From: Aron Rosenberg
[mailto:arosenberg@xxxxxxxxxxxxxx] I was testing and came across a
potential pathway which might need a onTerminated callback, but I am not sure 1.
ClientSubscription
is created 2.
onRequestRetry is
called due to initial/local 408/503/etc and >0 is returned. 3.
DUM timer is added
for DumTimeout::SubscriptionRetry 4.
ClientSubscription::dispatch(const DumTimeout& timer) gets called and
mOnNewSubscriptionCalled is false 5.
Do
we need to add an onTerminated callback since it appears this pathway doesn’t
fire one -Aron From: Scott Godin
[mailto:slgodin@xxxxxxxxxxxx] I’m not sure I fully understand
yet why the crash is happening. The logs seem to indicated that the
ClientSubscription is handling two 408 responses???? For some reason the
two 408’s have the same TID, but a different to tag – very strange. SIP:
[.\ClientSubscription.cxx:59] ClientSubscription::dispatch SipResp: 408
tid=151dd73cc5746622 cseq=SUBSCRIBE / 2 from(wire) SIP:
[.\ClientSubscription.cxx:114] processing client subscription response SIP: [.\ClientSubscription.cxx:168]
Received 408 to SUBSCRIBE
<sip:kristie.lomond@xxxxxxxxxxxxxxxxxx>;tag=10.11374.1216071735.678374 … SIP:
[.\ClientSubscription.cxx:59] ClientSubscription::dispatch SipResp: 408
tid=151dd73cc5746622 cseq=SUBSCRIBE / 2 from(wire) SIP:
[.\ClientSubscription.cxx:114] processing client subscription response SIP:
[.\ClientSubscription.cxx:168] Received 408 to SUBSCRIBE
<sip:kristie.lomond@xxxxxxxxxxxxxxxxxx>;tag=10.11385.1216071758.680732 But I did find another issue
with ClientSubscriptions, and the fix for this may end up stopping the crash as
well. The problem is that when
ClientSubscription::end is called, an un-subscribe message is sent out.
Normally if this is successful, then we wait for a Notify to arrive with
subscription-state terminated, before destroying the ClientSubscription.
However if this un-subscribe request fails, then the whole AppDialogSet reuse
and ClientSubscription retry logic kicks in. However the retry request
generated is not an unsubscribe request, it is a new subscription that is
retried. I’ve attached a patch that will just terminate the
ClientSubscription, if we call end() then receive an error response to the
unsubscribe. It seems that the whole
ClientSubscription usage needs a makeover. : ) Scott From:
resiprocate-devel-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Aron
Rosenberg I was finally able to get
a working pcap, resip log and debug crash at the same time. Here is what is
going on 1.
Client makes
subscription 2.
Client ends the
subscription by invoking end() on the handle 3.
This end results in
a local 408 error, which calls onRequestRetry 4.
Our code returns 0
to onRequestRetry(ClientSubscriptionHandle) to retry the request since we want
the server to know we ended the sub 5.
"Application requested immediate retry on Retry-After" is printed to log 6.
Crash happens in the
else statement in ClientSubscription.cxx:198 when trying to call getAppDialogSet()->reuse(). I have a full log (over 100MB of
resip data which I can send to a developer who wants to look at it along with
the matching pcap error file -Aron From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Aron
Rosenberg Here is a little bit more
information gleaned from a pcap trace. The stack seems to be crashing
when dealing with a 400 error where the “From:” header looks like this “From:
<sip:>;tag=5b461e50” I was able to find the outbound
SUBSCRIBE request and it also has an empty From address so something strange is
going on in the stack. Still working on getting the resip logs. -Aron From:
resiprocate-devel-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Aron
Rosenberg Resip ver: SVN rev 8128 on 1.3 branch Call Stack: resip::AppDialogSet::getHandle() Line 22 + 0x3 bytes C++ The crash is because the appDialogSet returned in
DialogUsage::getAppDialogSet() is NULL. It came from our production client and is reasonable
repeatable, so I am working on getting the resip logs that would go with it. -Aron --------------------------------------------- Aron Rosenberg Founder and CTO SightSpeed - http://www.sightspeed.com/ 918 Parker St, Suite A14 Berkeley, CA 94710 Email: arosenberg@xxxxxxxxxxxxxx Phone: 510-665-2920 Cell: 510-847-7389 Fax: 510-649-9569 SightSpeed Video Link: http://aron.sightspeed.com |