<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    <font color="#000000"><tt>Hi Arnold,<br>
        <br>
      </tt><tt>Just to summarize the discussion and conclusion we had
        via IRC on #opensips.<br>
        <br>
      </tt><tt>What you say is correct, on the other hand, B2B "abuses"
        the late media negotiation and because of that, there are some
        delays in ACK propagation<br>
        <br>
        <font size="3">The ACK is not sent by b2b (to the 200 OK for
          re-INVITE), as the ACK is triggered only by the 200 OK on the
          callee side -</font><span style="font-weight: normal;"></span><span
          style="font-weight: bold; color: rgb(32, 74, 135);"> </span><font
          size="3">so the entire ringing on the callee side will fit
          between the 200 OK and ACK on caller side</font><br>
        <span style="font-weight: normal;"><font size="3">T</font></span><font
          size="3">hat's the way the B2B works in order to allow direct
          SDP exchange</font><span style="font-weight: bold; color:
          rgb(32, 74, 135);"> </span><font size="3">- on the caller
          side it uses late SDP negotiation (200 OK + ACK) and on callee
          normal negotiation (INVITE + 200 OK)</font><br>
        <span style="font-weight: normal;"></span><font size="3">And you
          are right, that caller cannot hangup while callee in ringing,
          as caller have not received the ACK yet.<br>
          <br>
        </font></tt><tt><font size="3">As a work around to this issue,</font><font
          size="3">use provisional media while calling to callee</font>
        - <span style="font-weight: normal;"></span><span
          style="font-weight: bold; color: rgb(32, 74, 135);"></span><font
          size="3">so, instead of having the caller "waiting / stuck"
          for the callee to wait, you can "park" caller call into a
          media server, for a provisional media - you just need to </font><font
          size="3">to have the &lt;provisional_media&gt; node in your
          bridging:<br>
          Ex:<br>
          <br>
          &lt;bridge&gt;<br>
          &nbsp;&nbsp; &lt;client&gt; &lt;id&gt;server1&lt;/id&gt; &lt;/client&gt;<br>
          &nbsp;&nbsp; &lt;client&gt; &lt;id&gt;client2&lt;/id&gt;
          &lt;destination&gt; &lt;value
          type=&#8220;initial&#8221;&gt;server1&lt;/value&gt; &lt;/destination&gt;
          &lt;/client&gt;<br>
          &nbsp;&nbsp;
          &lt;provisional_media&gt;<a class="moz-txt-link-freetext" href="sip:moh@asterisk">sip:moh@asterisk</a>&lt;/provisional_media&gt;<br>
          &lt;/bridge&gt;</font></tt></font><font color="#000000"><br>
      <br>
      <tt>Regards,</tt></font><br>
    <tt></tt>
    <pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
    <br>
    On 07/04/2012 11:41 AM, Arnold Vriezekolk NETZOZEKER B.V. wrote:
    <blockquote
      cite="mid:alpine.DEB.2.02.1207040920430.29312@desktop.globalminds.it"
      type="cite">Hello,
      <br>
      <br>
      I'm using B2B to play a soundfile before connecting to an
      endpoint. My
      <br>
      opensips is connected to a SIP provider for incoming calls.
      <br>
      <br>
      Whenever a call comes in from my provider the b2b will send an
      invite to
      <br>
      asterisk to play a soundfile. Whenever the soundfile is done
      playing the b2b
      <br>
      will invite the endpoint.
      <br>
      <br>
      At packet 18 in the pcap dump[1] i hung up the call from the
      provider side, but
      <br>
      the provider keeps sending the "200 OK" to establish a dialog.
      Without the ACK
      <br>
      being sent from the opensips (or endpoint) side there will never
      be a dialog. According to
      <br>
      the RFC3261[2] a BYE must not be send while there hasn't been an
      ACK to
      <br>
      establish the dialog.
      <br>
      <br>
      What happens now is that the caller hangs up the call and the
      callee is still
      <br>
      ringing. The callee will ring for 30 seconds or so before the
      provider times
      <br>
      out the call and sends a BYE. If the callee would pick up his
      ringing phone,
      <br>
      nobody would be on the other end because the caller had hung up
      the phone. So
      <br>
      my question is: how do i solve this problem. Should my provider
      send a CANCEL
      <br>
      when the caller hangs up the call? Should OpenSIPS send the ACK to
      establish
      <br>
      the dialog?
      <br>
      <br>
      Thanks in advance,
      <br>
      Best Regards,
      <br>
      <br>
      Arnold Vriezekolk
      <br>
      <br>
      [1] Pcap Dump: <a class="moz-txt-link-freetext" href="http://vriezekolk.org/~tuxx/03-07-b2b.pcap">http://vriezekolk.org/~tuxx/03-07-b2b.pcap</a>
      <br>
      [2] RFC3261: However, the callee's UA MUST NOT send a BYE on a
      confirmed dialog until it has received an ACK for its 2xx response
      or until the server transaction times out.
      <br>
      <br>
      <br>
      _______________________________________________
      <br>
      Users mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
      <br>
      <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>
      <br>
      <br>
    </blockquote>
  </body>
</html>