[asterisk-bugs] [Asterisk 0016088]: chan_sip breaks RFC by incrementing session version between non-reliable 1xx and 200

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16088 
====================================================================== 
Reported By:                andrew_pogrebennyk
Assigned To:                oej
====================================================================== 
Project:                    Asterisk
Issue ID:                   16088
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.26.1 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-10-17 04:41 CDT
Last Modified:              2010-01-13 05:35 CST
====================================================================== 
Summary:                    chan_sip breaks RFC by incrementing session version
between non-reliable 1xx and 200
Description: 
There is a contradiction to RFC in the current chan_sip implementation. In
SIP the answerer may send the SDP answer in some or all of the provisional
responses, but it must ultimately send the answer in a "reliable" response,
either a reliable provisional response or a 2xx response. If PRACK isn't
used all of these answers must be the same, including session version in
the origin field.

This is defined in the section 13.2.1 of RFC 3261:

If the initial offer is in an INVITE, the answer MUST be in a reliable
non-failure message from UAS back to UAC which is correlated to that
INVITE. For this specification, that is only the final 2xx response to
that INVITE. That same exact answer MAY also be placed in any
provisional responses sent prior to the answer.

According to this, session version in the o-line must be the same in the
non-reliable provisional response and 200 OK. Asterisk however increments
the session version each time it sends a new SDP:

        /* Set RTP Session ID and version */
        if (!p->sessionid) {
                p->sessionid = getpid();
                p->sessionversion = p->sessionid;
        } else
                p->sessionversion++;

This behavior has been there since Nov 2003:
http://lists.digium.com/pipermail/svn-commits/2003-November/000534.html

I'm using Asterisk 1.4.24.1 however all newer versions contain this issue
and it causes interoperability problems with some carriers.
====================================================================== 

---------------------------------------------------------------------- 
 (0116565) oej (manager) - 2010-01-13 05:35
 https://issues.asterisk.org/view.php?id=16088#c116565 
---------------------------------------------------------------------- 
Yes, this is a known issue. We can in fact be ugly (as we're a b2bua) and
just change the tags on the 200 ok, indicating that we're another device
that answers. THis is needed since the SDP in the 183 can differ from the
200 ok. Kevin and I discussed this at SIPit a while ago. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-01-13 05:35 oej            Note Added: 0116565                          
======================================================================