<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1167786095;
mso-list-type:hybrid;
mso-list-template-ids:-1615269218 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Adrian,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol;color:black"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:10.0pt;font-family:"Courier New";color:black">If the initial offer is in an INVITE, the answer MUST be in a<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> reliable non-failure message from UAS back to UAC which is<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> correlated to that INVITE. For this specification, that is<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> only the final 2xx response to that INVITE. That same exact<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> answer MAY also be placed in any provisional responses sent<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> prior to the answer. The UAC MUST treat the first session<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> description it receives as the answer, and MUST ignore any<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> session descriptions in subsequent responses to the initial<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:black"> INVITE.<o:p></o:p></span></p>
<pre style="margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-family:Symbol;color:black"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman""> </span></span></span><![endif]><span style="color:black">Once the UAS has sent or received an answer to the initial<o:p></o:p></span></pre>
<pre><span style="color:black"> offer, it MUST NOT generate subsequent offers in any responses<o:p></o:p></span></pre>
<pre><span style="color:black"> to the initial INVITE. This means that a UAS based on this<o:p></o:p></span></pre>
<pre><span style="color:black"> specification alone can never generate subsequent offers until<o:p></o:p></span></pre>
<pre><span style="color:black"> completion of the initial transaction.<o:p></o:p></span></pre>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Of course, only your provider can confirm if this is, in fact, their issue with the exchange.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Ben<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Users <users-bounces@lists.opensips.org> on behalf of Adrian Fretwell <adrian.fretwell@topgreen.co.uk><br>
<b>Reply-To: </b>OpenSIPS users mailling list <users@lists.opensips.org><br>
<b>Date: </b>Wednesday, January 24, 2018 at 2:06 PM<br>
<b>To: </b>OpenSIPS users mailling list <users@lists.opensips.org><br>
<b>Subject: </b>[OpenSIPS-Users] SDP version increment without a change in SDP<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p><a name="_MailOriginalBody"><span style="font-size:10.0pt">Hello All, I have an issue for which I have not been able to find a definitive answer in the RFCs.</span><o:p></o:p></a></p>
<p><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt">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.</span><o:p></o:p></span></p>
<p><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt">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.</span><o:p></o:p></span></p>
<p><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt">I read that RFC 4566 says:
</span><o:p></o:p></span></p>
<p><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt">" <i>
<sess-version> is a version number for this session description. Its<br>
usage is up to the creating tool, so long as <sess-version> is<br>
increased when a modification is made to the session data. Again,<br>
it is RECOMMENDED that an NTP format timestamp is used</i>."</span><o:p></o:p></span></p>
<p><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt">The problem is I can't find an RFC stating "You MUST NOT increment<br>
version number if no change is made to the SDP".</span><o:p></o:p></span></p>
<p><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt">So I must either:
</span><o:p></o:p></span></p>
<p><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt">1. Prove that it should be OK to increment the version number without any change to the SDP. Or</span><o:p></o:p></span></p>
<p><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt">2. Find a way of not passing through the incremented version number to the upstream side where the SDP has not actually changed.</span><o:p></o:p></span></p>
<p><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt">I hope that makes sense... As always any help very nuch appreciated.</span><o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Verdana",sans-serif">Kind regards,<br>
<br>
Adrian Fretwell<br>
Nottinghamshire<br>
UK</span></span><span style="mso-bookmark:_MailOriginalBody"><o:p></o:p></span></p>
</div>
</div>
</body>
</html>