<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><font size="-1">Ben,</font></p>
    <p><font size="-1">Thank you that is so helpful.</font></p>
    <p><font size="-1">Adrian.</font><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 24/01/18 19:35, Ben Newlin wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:0142210E-B0A3-4A3A-8350-0F4378A26BCB@genesys.com">
      <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>
      <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
              <a class="moz-txt-link-rfc2396E" href="mailto:users-bounces@lists.opensips.org"><users-bounces@lists.opensips.org></a> on behalf of
              Adrian Fretwell <a class="moz-txt-link-rfc2396E" href="mailto:adrian.fretwell@topgreen.co.uk"><adrian.fretwell@topgreen.co.uk></a><br>
              <b>Reply-To: </b>OpenSIPS users mailling list
              <a class="moz-txt-link-rfc2396E" href="mailto:users@lists.opensips.org"><users@lists.opensips.org></a><br>
              <b>Date: </b>Wednesday, January 24, 2018 at 2:06 PM<br>
              <b>To: </b>OpenSIPS users mailling list
              <a class="moz-txt-link-rfc2396E" href="mailto:users@lists.opensips.org"><users@lists.opensips.org></a><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" moz-do-not-send="true"><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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>