[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:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16088
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.4.26.1 
JIRA:                       SWP-709 
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:              2011-03-21 16:05 CDT
====================================================================== 
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.
====================================================================== 

---------------------------------------------------------------------- 
 (0133055) rgagnon (reporter) - 2011-03-21 16:05
 https://issues.asterisk.org/view.php?id=16088#c133055 
---------------------------------------------------------------------- 
My 2 cents, which might make it appear the RFC for SDP might contradict
what is going on here....

RFC4566 (Session Description Protocol) Section 5.2 

This discusses the Origin ("o=") value....

Format for Origin:
o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>

Now, in regard to "<sess-version>" and "<sess-id>"...
====================================================================
"<sess-id> is a numeric string such that the tuple of <username>,
      <sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a
      globally unique identifier for the session.  The method of
      <sess-id> allocation is up to the creating tool, but it has been
      suggested that a Network Time Protocol (NTP) format timestamp be
      used to ensure uniqueness [13]."

<sess-version> is a version number for this session description.  Its
      usage is up to the creating tool, so long as <sess-version> is
      increased when a modification is made to the session data.  Again,
      it is RECOMMENDED that an NTP format timestamp is used.
====================================================================

Note that <sess-version> is NOT included in the definition of a GUID for
the <sess-id>, and that <sess-version> is said to have its usage up to the
creating tool.  Are people reading this session too fast, and assuming that
<sess-version> IS part of the GUID, and thus creating a non-compliant
UAC/UAS?

The correlation that the OP speaks of in RFC3261 13.2.1 can still be done
using all the components of the Origin, with the exception of the
<sess-version>, and thus, this would mean the current Origin format (with
the <sess-version> incrementer) is valid. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-03-21 16:05 rgagnon        Note Added: 0133055                          
======================================================================