[asterisk-bugs] [Asterisk 0012391]: route information is lost for incoming calls before sending BYE
noreply at bugs.digium.com
noreply at bugs.digium.com
Wed Apr 9 15:47:34 CDT 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=12391
======================================================================
Reported By: benjaminbohlmann
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 12391
Category: Channels/chan_sip/General
Reproducibility: always
Severity: major
Priority: normal
Status: new
Asterisk Version: 1.4.19
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 04-09-2008 04:56 CDT
Last Modified: 04-09-2008 15:47 CDT
======================================================================
Summary: route information is lost for incoming calls before
sending BYE
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
======================================================================
----------------------------------------------------------------------
putnopvut - 04-09-08 15:47
----------------------------------------------------------------------
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.
Issue History
Date Modified Username Field Change
======================================================================
04-09-08 15:47 putnopvut Note Added: 0085253
======================================================================
More information about the asterisk-bugs
mailing list