[Home]

Summary:ASTERISK-11743: SIP reinvite record-route problem after hangup
Reporter:Roel van Meer (rolek)Labels:
Date Opened:2008-03-28 06:10:47Date Closed:2011-06-07 14:07:27
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip.c_12322_reinvite_after_hangup_3.patch
( 1) chan_sip.c_12322_reinvite_after_hangup.patch
( 2) chan_sip.c_8993_8995_1.4.19.patch
( 3) sip-conf_12322.txt
( 4) sip-debug-12322_2.txt
( 5) sip-trace_12322_1.txt
Description:Situation: phone1 - *a - *b - provider - phone2

When making a call from phone2 to phone1, both *b and provider use re-invites to get out of the RTP stream. After phone1 hangs up, *b tries to send BYE directly to the RTP server of the provider instead of its SIP peer. The result is that phone2 does not see that the call has ended.

****** ADDITIONAL INFORMATION ******

*a: asterisk 1.4.18.1 on slackware 10.1
*b: asterisk 1.4.18.1 on slackware 10.2

The problem is reproducible always, but it only happens when phone2 makes a call to phone1, it does not happen when phone1 makes a call to phone2. Attached are the sip config file of *b and a SIP trace of a call, also from *b.
Comments:By: Roel van Meer (rolek) 2008-03-28 06:19:59

According to our provider this problem was caused by ASTERISK-11033 . I tried both 1.4.16 with that particular patch and 1.4.18.1 and the problem happens with both, so it might be related, but if it is, it's not solved.


By: Roel van Meer (rolek) 2008-03-28 06:21:03

Please let me know if I need to provide additional details, traces or logs, or if you want shell access on any of the * boxen.
By: Roel van Meer (rolek) 2008-03-28 06:41:44

This might be similar to what has been reported in ASTERISK-6082 .
By: Roel van Meer (rolek) 2008-04-16 08:36:51

I've uploaded the patch that oej wrote (in bug ASTERISK-6082 ), manually applied to 1.4.19. Original patch was taken from
http://svn.digium.com/view/asterisk/team/oej/strictrouting/channels/chan_sip.c?view=patch&r1=8993&r2=8994&pathrev=64190


By: Roel van Meer (rolek) 2008-04-17 03:19:51

No luck, even with the patch the problem persists.
Right now I have a dedicated test setup available for anyone interested in assisting debugging this thing.
By: Roel van Meer (rolek) 2008-04-17 03:26:48

I've added a debug listing of a single call where the problem happens. This listing is made on the *b box (see bug Description).

At the end of the listing you can see that the BYE is sent to the wrong host.
By: Roel van Meer (rolek) 2008-04-17 08:29:20

I'm getting somewhere. The patch of # 11545 ensures that handle_response_invite() does not call build_route() in case of a reinvite. However, pouring over debug traces shows that after the hangup, we send a reinvite, we receive a 200 OK, but when we send the ACK to that sequence, for some reason we're back to a 'standard' invite (which causes build_route to be called, which causes the bug).
By: Roel van Meer (rolek) 2008-04-18 01:59:40

When doing reinvites, after a hangeup, we get the following exchange:
INVITE ---->
<-------- OK
ACK ------->
However, after the INVITE, sip_hangup() is called, which sets the call owner to NULL, causing the test for reinvite in handle_response_invite() to incorrectly state it is not a reinvite.

To ensure the ACK is sent correctly, we have to avoid calling build_route(). The attached patch fixes this just before calling build_route() from handle_response_invite() [but I don't know if there are other situations which would by caught by this test, so this might not be a good way]. Perhaps it is better to improve the test for reinvite so it works even after sip_hangup() is called.
By: Roel van Meer (rolek) 2008-04-29 10:19:41

chan_sip.c_12322_reinvite_after_hangup.patch solved the problem, but broke calls in some cases.

chan_sip.c_12322_reinvite_after_hangup_2.patch was one of my test patches which can be removed. Please ignore it.

chan_sip.c_12322_reinvite_after_hangup_3.patch uses a dedicated variable to indicate the call is a reinvite being hung up. This fixes the problem in a much better way, without breaking any calls (AFAIK).
By: Olle Johansson (oej) 2008-07-01 09:06:13

I need a full debug with verbose and everything you get at the console. I don't see the issue here as I don't get all information. Please upload the output of all logging channels, not only the debug channel, and from the start of the call to the failed bye. Thank you.
By: Leif Madsen (lmadsen) 2008-09-08 14:26:57

Ping on this? oej has requested some additional information which will be required to move this bug forward. Thanks!
By: Olle Johansson (oej) 2009-01-29 07:29:10.000-0600

No reply. Closing this while waiting...