[asterisk-bugs] [JIRA] (ASTERISK-20644) Don't always use the existing TCP connection for in-dialog requests

[Matt Jordan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199229#comment-199229 ] 

Matt Jordan commented on ASTERISK-20644:
----------------------------------------

Thanks for describing where this behavior would cause a problem.  Given the scope of this change, I think the best way to treat this bug is to attempt to fix it in the next major version branch (Asterisk 12), rather than trying to patch it in the current release branches and potentially break phones using TCP connections.  Plus, as you pointed out, this feels like it fits into the same category of problems Asterisk has when it sits behind a SIP Proxy, and adding Path support would be nice to get done for Asterisk 12 as well.

For now I'm going to ack this issue and tag it as something to consider for Asterisk 12.
                
> Don't always use the existing TCP connection for in-dialog requests
> -------------------------------------------------------------------
>
>                 Key: ASTERISK-20644
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20644
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Interoperability, Channels/chan_sip/TCP-TLS
>    Affects Versions: 11.0.0
>            Reporter: Iñaki Baz Castillo
>
> If Asterisk receives an INVITE via TCP comming from a SIP proxy, answers the call and later Asterisk sends a re-INVITE or BYE for that dialog, Asterisk sends such an in-dialog request over the existing TCP connection previously opened by the SIP proxy. This is incorrect. Asterisk should open a NEW TCP connection to the address given in the top Record-Route header.
> So for example, Asterisk receives the following INVITE from TCP 1.2.3.4 port 8888:
> {code}
> # TCP 1.2.3.4:8888 => ASTERISK:5060
> INVITE sip:test at domain.com SIP/2.0
> Record-Route: <sip:1.2.3.4:5060;transport=tcp>
> {code}
> When Asterisk sends a BYE or a re-INVITE in this leg, it MUST respect the address in the top Route of the BYE or re-INVITE, which is: TCP 1.2.3.4 port 5060. So it should send the BYE to:
> {code}
> # TCP ASTERISK:5060 => 1.2.3.4:5060
> BYE sip:abc at 9.8.7.6 SIP/2.0
> Route: <sip:1.2.3.4:5060;transport=tcp>
> {code}
> This is something really basic in RFC 3261 and mandatory. Asterisk could use the existing TCP connection just in case nat=yes (or some other new values I don't fully know in the latest version), but by default, if "nat" parameter is not set for the Proxy peer, please DON'T reuse the existing TCP connection because that is a violation of RFC 3261.
> In fact, it's perfectly legal for a SIP proxy or SIP server to refuse/reject SIP requests coming from a TCP connection that the proxy/server itself opened against a remote proxy/server. These are RFC 3261 rules, really.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira