| Summary: | ASTERISK-11805: route information is lost for incoming calls before sending BYE | ||
| Reporter: | Benjamin Bohlmann (benjaminbohlmann) | Labels: | |
| Date Opened: | 2008-04-09 04:56:14 | Date Closed: | 2008-04-09 15:51:54 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) callflow.txt | |
| Description: | Hello, I'm seeing the following problem and I even found a solution for it (see below ;): This issues seems to be related to issues 0011545 and 0001491, but I don't think that it is a duplicate. Please correct me If I'm wrong. When I call my asterisk through an openser proxy and asterisk natively bridges the call to another phone connected to the proxy, asterisk looses the record-routing information set by the proxy for the calling phone if the called phone is hung up. This results in asterisk trying to send the BYE directly to the calling phone and not through the proxy. Therefore the BYE requests don't reach the calling Phone. All the record route headers of the initial invite requests and responses are set correctly by the openser. The call flow is the following (provisional responses are ignored, A is the caller and B is the callee): Phone A Openser Asterisk Openser Phone B | | | | | | | | | | |-- Invite B -->| | | | | |-- Invite B -->| | | | | | | | | | |- Invite B -->| | | | | | | | | | |- Invite B -->| | | | | | | | | |<---- OK -----| | | | | | | | |<---- OK -----| | | | | | | | |<---- OK ------| | | | | | | | |<---- OK ------| | | | | | | | | |---- ACK ----->| | | | | | | | | | |---- ACK ----->| | | | | | | | | | |---- ACK ---->| | | | | | | | | | |---- ACK ---->| | | | | | .... reinvites for native bridging (they work) ..... | | | |<---- BYE ----| | | | | | | | |<---- BYE ----| | | | | | | | | |----- OK ---->| | | | | | | | |<-- Invite A --| |----- OK ---->| | | | | | |<-- Invite A --| | | | | | | | | |---- OK ------>| | | | | | | | | | |---- OK ------>| | | | | | | | |<-------------ACK -------------| | | | | | | | | | | | | |---- OK ------>| | | | | | | | | | |---- OK ------>| | | | | | | | |<-------------ACK -------------| | | | | | | | |<------------ BYE -------------| | | | | | | | |---- OK ------>| | | | | | | | | | |---- OK ------>| | | | | | | | |<-------------ACK -------------| | | | | | | | |<------------ BYE -------------| | | | | | | | |---- OK ------>| | | | | | | | | | |---- OK ------>| | | | | | | | |<-------------ACK -------------| | | | | | | | |<------------ BYE -------------| | | | | | | | The problem seem to be that at some point the routing information for caller A gets overwritten. The fix I applied to solve this problem is in chan_sip.c in function static void build_route(struct sip_pvt *p, struct sip_request *req, int backwards); I changed the line p->route_persistant = backwards; to p->route_persistant = 1; This results in routing sets not beeing overwritten once they are set. This should be compliant with the SIP rfc since only the record-route headers of the initial invite or the response to the initial invite in a dialog determine the route that should be used throughout the dialog. Another comment: I couldn't understand why this value was set to the value of "backwards" since backwards only determines the sorting order of the route header fields, but maybe I misunderstood something. At this point I can't overlook the side-effects of my code-change, therefore I didn't submit a patch yet. Please give me feedback on this issue. regards Benjamin Bohlmann | ||
| Comments: | By: Benjamin Bohlmann (benjaminbohlmann) 2008-04-09 04:57:39 The call flow is messed up. I'll attach it as a textfile By: Mark Michelson (mmichelson) 2008-04-09 15:47:33 I agree with your analysis. chan_sip seems to be under the impression that receiving a response to an INVITE is the only way to not overwrite the route set. This should not make a difference. Instead, what's important is to construct a route set based on the INVITE and not change it on re-invites. I'm going to change chan_sip to reflect your local change. Thanks for bringing this to our attention. By: Digium Subversion (svnbot) 2008-04-09 15:49:47 Repository: asterisk Revision: 113927 U branches/1.4/channels/chan_sip.c ------------------------------------------------------------------------ r113927 | mmichelson | 2008-04-09 15:49:45 -0500 (Wed, 09 Apr 2008) | 8 lines We need to set the persistant_route [sic] parameter for the sip_pvt during the initial INVITE, no matter if we're building the route set from an INVITE request or response. (closes issue ASTERISK-11805) Reported by: benjaminbohlmann Tested by: benjaminbohlmann ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=113927 By: Digium Subversion (svnbot) 2008-04-09 15:51:33 Repository: asterisk Revision: 113928 _U trunk/ U trunk/channels/chan_sip.c ------------------------------------------------------------------------ r113928 | mmichelson | 2008-04-09 15:51:31 -0500 (Wed, 09 Apr 2008) | 16 lines Merged revisions 113927 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r113927 | mmichelson | 2008-04-09 15:54:31 -0500 (Wed, 09 Apr 2008) | 8 lines We need to set the persistant_route [sic] parameter for the sip_pvt during the initial INVITE, no matter if we're building the route set from an INVITE request or response. (closes issue ASTERISK-11805) Reported by: benjaminbohlmann Tested by: benjaminbohlmann ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=113928 By: Digium Subversion (svnbot) 2008-04-09 15:51:54 Repository: asterisk Revision: 113929 _U branches/1.6.0/ U branches/1.6.0/channels/chan_sip.c ------------------------------------------------------------------------ r113929 | mmichelson | 2008-04-09 15:51:53 -0500 (Wed, 09 Apr 2008) | 24 lines Merged revisions 113928 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r113928 | mmichelson | 2008-04-09 15:56:14 -0500 (Wed, 09 Apr 2008) | 16 lines Merged revisions 113927 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r113927 | mmichelson | 2008-04-09 15:54:31 -0500 (Wed, 09 Apr 2008) | 8 lines We need to set the persistant_route [sic] parameter for the sip_pvt during the initial INVITE, no matter if we're building the route set from an INVITE request or response. (closes issue ASTERISK-11805) Reported by: benjaminbohlmann Tested by: benjaminbohlmann ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=113929 | ||