[asterisk-bugs] [JIRA] (ASTERISK-22071) chan_sip doesn't respect Via ..completely
Mark Michelson (JIRA)
noreply at issues.asterisk.org
Mon Jul 29 16:21:03 CDT 2013
[ https://issues.asterisk.org/jira/browse/ASTERISK-22071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=208348#comment-208348 ]
Mark Michelson edited comment on ASTERISK-22071 at 7/29/13 4:19 PM:
--------------------------------------------------------------------
So, this issue is interesting.
Follow along with me using {{issue_22071_0715_11.5.0-rc2}}. We'll skip ahead to the 200 OK that Asterisk receives in response to the INVITE. The 200 OK has two Record-Route headers. The top one specifies address 5.6.7.8:5060. Asterisk constructs a route set that specifies that messages in this dialog should be sent to 5.6.7.8:5060. Presumably, the ACK that Asterisk sends should go to this address. The ACK is not sent to this address, which seems wrong to me. But this is a separate issue.
Later, a BYE arrives from 1.2.3.4:5062. The top-most Via header has 1.2.3.4:5062, so we should send our response to that address. In fact, several lines lower you'll see a line that says "Sending to 1.2.3.4:5062". It seems like things should go correctly.
In the code, however, the issue arises as part of the {{respprep()}} function. At the very end of it, you'll find the following lines:
{code}
/* default to routing the response to the address where the request
* came from. Since we don't have a transport layer, we do this here.
* The process_via() function will update the port to either the port
* specified in the via header or the default port later on (per RFC
* 3261 section 18.2.2).
*/
p->sa = p->recv;
if (process_via(p, req)) {
ast_log(LOG_WARNING, "error processing via header, will send response to originating address\n");
}
{code}
The first line below the comment is setting the send address to be the same as the receive address, overriding what we had correctly determined to be the proper send address. As the comment states, the process_via() function updates the port based on what is in the Via header. However, for some reason, the process_via() function does not try to set the send address to the address that is in the Via header. Thus Asterisk ends up sending the 200 OK to the oddball address of 5.6.7.8:5062. Asterisk sends to the address from the route set but the port from the Via header in the BYE request.
Worst of all, this behavior is *completely unaffected* by NAT settings.
I can provide a fix for this, and it likely will solve your problem. The problem is that making the change to respect the Via header could potentially lead to broken interoperability with specific clients. We'll see.
was (Author: mmichelson):
So, this issue is interesting.
Follow along with me using {{issue_22071_0715_11.5.0-rc2}}. We'll skip ahead to the 200 OK that Asterisk receives in response to the INVITE. The 200 OK has two Record-Route headers. The top one specifies address 5.6.7.8:5060. Asterisk constructs a route set that specifies that messages in this dialog should be sent to 5.6.7.8:5060. Presumably, the ACK that Asterisk sends should go to this address. The ACK is not sent to this address, which seems wrong to me. But this is a separate issue.
Later, a BYE arrives from 1.2.3.4:5062. The top-most Via header has 1.2.3.4:5062, so we should send our response to that address. In fact, several lines lower you'll see a line that says "Sending to 1.2.3.4:5062". It seems like things should go correctly.
In the code, however, the issue arises as part of the {{respprep()}} function. At the very end of it, you'll find the following lines:
{code}
/* default to routing the response to the address where the request
* came from. Since we don't have a transport layer, we do this here.
* The process_via() function will update the port to either the port
* specified in the via header or the default port later on (per RFC
* 3261 section 18.2.2).
*/
p->sa = p->recv;
if (process_via(p, req)) {
ast_log(LOG_WARNING, "error processing via header, will send response to originating address\n");
}
{code}
The first line below the comment is setting the send address to be the same as the receive address, overriding what we had correctly determined to be the proper send address. As the comment states, the process_via() header updates the port based on what is in the Via header. However, for some reason, the process_via() header does not try to set the send address to the address that is in the Via header. Thus Asterisk ends up sending the 200 OK to the oddball address of 5.6.7.8:5062. Asterisk sends to the address from the route set but the port from the Via header in the BYE request.
Worst of all, this behavior is *completely unaffected* by NAT settings.
I can provide a fix for this, and it likely will solve your problem. The problem is that making the change to respect the Via header could potentially lead to broken interoperability with specific clients. We'll see.
> chan_sip doesn't respect Via ..completely
> -----------------------------------------
>
> Key: ASTERISK-22071
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-22071
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_sip/General
> Affects Versions: 11.4.0
> Environment: CentOS 6.4
> Reporter: Alex Zarubin
> Assignee: Mark Michelson
> Attachments: ASTERISK-22071.patch, AsteriskJira22071.txt, issue_22071_0715_11.5.0-rc2, issue_22071_gen, issue_22071_log11.2.1, issue_22071_sipsettings, sip.conf, sipsettings
>
>
> The same exact sip call works in 11.2.1 and fails in 11.4. Outbound call is established normally via proxy. BYE comes from proxy with <proxy ip/port> in first Via header. 11.4 adds received=<carrier ip/port> and sends OK there. BYE is repeated several times.
> Will try to attach sip.conf and trace once this jira issue is created. Thank you.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list