[OpenSIPS-Users] SDP version increment without a change in SDP
schoolhouse at a2es.co.uk
Wed Jan 24 15:33:34 EST 2018
Thank you that is so helpful.
On 24/01/18 19:35, Ben Newlin wrote:
> 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
> 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
> ·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
> 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.
> *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
> Users mailing list
> Users at lists.opensips.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users