Summary:	ASTERISK-15001: chan_sip breaks RFC by incrementing session version between non-reliable 1xx and 200
Reporter:	Andrew Pogrebennyk (andrew_pogrebennyk)	Labels:
Date Opened:	2009-10-17 04:41:40	Date Closed:	2011-07-27 09:21:26
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:	is related to ASTERISK-21204 Asterisk increments the session version in 2xx message even if a '183 Session in Progress' with SDP has already been sent in response to initial INVITE. is related to ASTERISK-17540 SDP origin attribute modified when issuing re-INVITE because of directmedia=yes
Environment:		Attachments:
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.
Comments:	By: Leif Madsen (lmadsen) 2009-10-26 09:10:06 Assigned to oej to review; not necessarily a request to fix, but just to review. Please un-assign yourself and set to Acknowledged after you've confirmed. Thanks! By: Olle Johansson (oej) 2010-01-13 05:35:15.000-0600 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. By: Andrew Pogrebennyk (andrew_pogrebennyk) 2010-01-22 04:20:51.000-0600 Well, on seconds thoughts (following a conversation with another expert) I'm not sure this is a bug. If we have implication A => B, it doesn't require B => A. RFC requires that SDP change needs version increase, but there is no reverse requirement - if SDP isn't changed, version still may be changed. In Linksys/Sipura devices both SDP session ID and version are timestamps since session start, even if nothing has been changed in the contents. And definitely changing the tags in the 200 OK is more ugly (and would cause more issues, I think) than always incrementing the session version. So we'd better leave it as is. By: Olle Johansson (oej) 2010-01-22 04:24:34.000-0600 One offer/answer session can only have one answer per device. So if you're calling Asterisk the 183 SDP and the 200 OK SDP *must* be the same. In many cases, the two are different. Now, as I said, we could potentially fake it by simulating another SIP device in the 200 OK. By: Rob Gagnon (rgagnon) 2011-03-21 16:05:44 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 section 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. By: Rob Gagnon (rgagnon) 2011-04-01 18:57:51 A small note to say that the behaviour noted by the OP does not exist under v1.6.0 and higher.  There was code added at the time session handling was inserted that will not increment the session-version part of the origin SDP line ("o=") I would imagine that it will not be back-ported to 1.4 as it was quite a big patch (r98978 it seems is the revision) By: Russell Bryant (russell) 2011-07-27 09:21:21.110-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks! By: Eran Benjamin (buffpuff) 2012-10-01 07:23:23.519-0500 I think there might be a regression of some sort with Asterisk 1.8.14.1 where an SDP version gets incremented between the 183 and the 200 messages without the content changing. I have pcap files that can show this clearly. By: Torrey Searle (tsearle) 2013-02-20 10:44:52.298-0600 Issue is also present in asterisk-11 By: Olle Johansson (oej) 2013-10-31 04:42:14.273-0500 Was this fixed or not?