[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=199219#comment-199219 ] 

Matt Jordan edited comment on ASTERISK-20644 at 11/5/12 8:13 AM:
-----------------------------------------------------------------

These kinds of changes - particularly in release branches - worry me.  Often when we change behavior such as this, we end up dealing with a litany of regression issues for several minor release versions.

Asterisk's behavior may not be "correct" (although like Walter, I haven't found the language in RFC 3261 that explicitly forbids it - but I could certainly be missing it).  For sweeping changes like this it'd be nice to know what we're currently breaking.  For what devices and/or scenarios is the current behavior detrimental?
                
      was (Author: mjordan):
    These kinds of changes - particularly in release branches - worry me.  Often when we change behavior such as this, we end up dealing with a litany of regression issues for several minor release versions.

While Asterisk's behavior may not be "correct" (although like Walter, I haven't found the language in RFC 3261 that explicitly forbids it - but I could certainly be missing it), but for sweeping changes like this it'd be nice to know what we're currently breaking.  For what devices and/or scenarios is the current behavior detrimental?
                  
> 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