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 <[email protected]> on behalf of Adrian
Fretwell <[email protected]>
*Reply-To: *OpenSIPS users mailling list <[email protected]>
*Date: *Wednesday, January 24, 2018 at 2:06 PM
*To: *OpenSIPS users mailling list <[email protected]>
*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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
