[OpenSIPS-Users] SDP version increment without a change in SDP

[Ben Newlin]

Adrian,

I can’t help with a way not to increment the version number on RTPProxy, but I believe I know why the provider is not happy with the exchange.

The problem is not that the version number has incremented without a change to the SDP. As you have pointed out, RFC 4566 does not prohibit changing the version number and I think the provider was wrong to point you to that RFC. I think it’s likely the issue isn’t with the SDP itself, but with the exchange. It is covered in RFC 3261, Section 13.2.1, specifically these two bullets:


·         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
         INVITE.

·         Once the UAS has sent or received an answer to the initial

         offer, it MUST NOT generate subsequent offers in any responses

         to the initial INVITE.  This means that a UAS based on this

         specification alone can never generate subsequent offers until

         completion of the initial transaction.

So the problem is that the SDP is changing between the 183 and 200 OK, even though it is only the version. When providing SDP in an unreliable response, the SDP in the final response is required to be exactly the same. You are not allowed to change the SDP once it has been sent without initiating a new offer/answer, which you can’t do in the 200 OK as you haven’t completed the previous exchange with a final response.

Having said that, this is not a widely enforced rule. Nearly all SIP implementations are tolerant of this or at least will simply ignore SDP’s after the first without terminating the call. Many even support receiving multiple different SDP’s in multiple 183 responses during a single INVITE exchange. But I have worked with some who do not tolerate it and unfortunately the RFC is on their side.

Of course, only your provider can confirm if this is, in fact, their issue with the exchange.

Thanks,
Ben



From: Users <users-bounces at lists.opensips.org> on behalf of Adrian Fretwell <adrian.fretwell at topgreen.co.uk>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: Wednesday, January 24, 2018 at 2:06 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: [OpenSIPS-Users] SDP version increment without a change in SDP


Hello All,  I have an issue for which I have not been able to find a definitive answer in the RFCs.

I use RTPProxy as part of NAT traversal so RTP streams are set up between upstream provider and my proxy, and between my proxy and the UAC.

The problem I have, is UAC changes it's RTP port between 183 and 200 OK and thus increments the SDP version number, BUT the ports DO NOT change between proxy and upstream provider but the SDP version number does, because it is passed through.  The upstream provider says this violates RFC 4566 and sends an immediate BYE after the final ACK.

I read that RFC 4566 says:

" <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."

The problem is I can't find an RFC stating "You MUST NOT increment
version number if no change is made to the SDP".

So I must either:

1. Prove that it should be OK to increment the version number without any change to the SDP.  Or

2. Find a way of not passing through the incremented version number to the upstream side where the SDP has not actually changed.

I hope that makes sense...  As always any help very nuch appreciated.
Kind regards,

Adrian Fretwell
Nottinghamshire
UK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180124/de2a88d0/attachment-0001.html>