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

[Schoolhouse Filing]

Ben,

Thank you that is so helpful.

Adrian.


On 24/01/18 19:35, Ben Newlin wrote:
>
> 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
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180124/83355565/attachment.html>