Summary: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.
Reporter:NITESH BANSAL (nbansal)Labels:
Date Opened:2013-03-04 07:21:54.000-0600Date Closed:2013-10-14 16:41:02
Versions:11.2.0 Frequency of
is related toASTERISK-15001 chan_sip breaks RFC by incrementing session version between non-reliable 1xx and 200
Environment:Debian Squeeze x86_64Attachments:( 0) dont-increment-session-version-in-2xx-after-183.patch
Description:Scenario: Asterisk receives a dialog initiating INVITE. It responds with 183 "Session in Progress" with SDP and then it answers the call by sending a 200 OK, the SDP in 200 OK is exactly the same as SDP in 183 (which is in compliance with RFC 3261), but it increments the session version in SDP of 200 OK.
Expected Result: Session version should remain the same if there is no change in SDP.
Actual Result: Asterisk increments the session version.
This issue is causing a call disconnect with one of our customers who is using a ERICSSON PLATFORM, ericsson platform drops the calls because of the increment in session version in oline (with error “EOS 3766 Interworking unspecified” which is a protocol error).
And as per RFC 3261, section 13.2.1,
   o  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.  The UAC MUST treat the first session
        description it receives as the answer, and MUST ignore any
        session descriptions in subsequent responses to the initial
So according to this, SDP in 200 OK should be exactly same as SDP in 183 and which implies the session version should not change from 183 to 200.

Nitesh Bansal

Comments:By: NITESH BANSAL (nbansal) 2013-03-04 07:27:09.578-0600


I have made a patch for this.
Please review this.

Nitesh Bansal

By: Rusty Newton (rnewton) 2013-03-07 12:09:33.523-0600

Linking to ASTERISK-15001, also marked as regression.