<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    UDP remains the "weapon of choice" for sip trunking applications and
    for many subscriber applications.  However, feature-rich subscriber
    implementations frequently require SIP messages to be substantially
    larger than the (approximately) 1500 byte MTU (maximum transmission
    unit) supported in the public internet.   UDP has a mechanism for
    dealing with messages greater than MTU size, but it doesn't work
    reliably for SIP over UDP in the public internet.   <br>
    <br>
    When you need to go > 1500 bytes, you need to go to TCP.   <br>
    <br>
    Although SIP registration state and SIP call state can be replicated
    over a pair of SBC's (Acme or Sonus), TCP state cannot be
    maintained.  There is way to much going on at the driver level for
    that to be practical.  When switchover occurs, the TCP "transmission
    control" parameters are stale.   So, there will be a TCP RST, and
    the endpoints need to start over with the whole SYN / SYN,ACK
    "three-way handshake" drill.   <br>
    <br>
    Although the subscriber device will in all likelihood need to
    restart the TCP session, the worst-case disruption will be only as
    long as the re-registration interval.  And even then, only outbound
    calls (toward the subscriber device) will be affected.  But even in
    that unlucky instance, voice mail should save the day.<br>
    <br>
    The Acme "TCP session leak" was fixed several years ago  At least
    three.   Any software having that leak has been End of Support for
    long time.   <br>
    <br>
    If anybody would like further discussion, feel free to contact me
    directly.<br>
    <blockquote>John S. Robinson<br>
      jsr (at) communichanic dot com<br>
      Communichanic Consultants, Inc.<br>
    </blockquote>
    <br>
    <br>
    <div class="moz-cite-prefix">On 7/17/2017 08:32, Pete Eisengrein
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAHm=SaLWY9a5SqnmCoOrM7dsHdSAQsGFXxDEqyEbAr5zb+9dbQ@mail.gmail.com">
      <div dir="ltr">Perfect example. With an Acme SBC as a redundant
        pair, if (when) the primary fails and switches to the standby,
        all UDP immediately goes to the standby and is generally
        unnoticed by the end users. However, if the SIP is over TCP in
        that scenario, the switch still happens but the TCP session must
        re-establish itself to the secondary SBC and therefore is an
        outage for those users until they re-register. I suppose it is
        possible to share TCP session info, but I am not aware of any
        SBC's that do this any differently (though would love to hear
        from the group if one exists).
        <div><br>
        </div>
        <div>Somewhat related, but not really: It's since been patched
          but Acme (Oracle) had a bug at one point where it was not
          releasing TCP sessions after they were gone and you'd end up
          using all available resources (TCP ports); if that happened
          you'd begin blocking new sessions and the only workaround was
          a forced switchover which, of course, then meant a forced
          outage for those users. </div>
        <div><br>
        </div>
        <div>-Pete</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Mon, Jul 17, 2017 at 9:01 AM, Colton
          Conor <span dir="ltr"><<a
              href="mailto:colton.conor@gmail.com" target="_blank"
              moz-do-not-send="true">colton.conor@gmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="ltr">Thanks for the replies. I am mainly talking
              about using TCP for SIP signaling for <span
                style="font-size:12.8px">access/customer side of the
                network only. I think trunk connections to carriers will
                stay UDP only for a long time. </span>
              <div><br>
              </div>
              <div>Overwhelming it seems like using TCP for signaling
                doesn't seem to be a bad thing, and preferred by many.
                Peter, I have a question about what you mean by "<span
                  style="font-size:12.8px">But the biggest reason I
                  prefer UDP is for failover/redundancy. In the event of
                  a system failure/failover, UDP will be in-disrupted
                  but TCP will." </span>
                <div><span style="font-size:12.8px"><br>
                  </span></div>
                <div><span style="font-size:12.8px">Lets assume we are
                    using Broadsoft with an Acme Packet SBCs, and have
                    redundancy having one on the West coast and one on
                    the east cost. </span></div>
                <div><span style="font-size:12.8px"><br>
                  </span></div>
                <div><span style="font-size:12.8px">Using TCP for
                    signaling, how would this be different than using
                    UDP in a fail over secenario? Assume the client is
                    closer to the West cost node, and the West coast
                    node rebooted or shut down due to power failure. </span></div>
                <div><span style="font-size:12.8px"><br>
                  </span></div>
                <div><span style="font-size:12.8px"><br>
                  </span></div>
                <div>Using UDP for RTP makes perfect sense. Sorry for
                  asking the stupid question about RTP. </div>
              </div>
            </div>
            <div class="HOEnZb">
              <div class="h5">
                <div class="gmail_extra"><br>
                  <div class="gmail_quote">On Sun, Jul 16, 2017 at 9:59
                    PM, Peter E <span dir="ltr"><<a
                        href="mailto:peeip989@gmail.com" target="_blank"
                        moz-do-not-send="true">peeip989@gmail.com</a>></span>
                    wrote:<br>
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">The
                      SIP protocol already has some built in reliability
                      techniques built in (timers, retransmission) for
                      which TCP is usually used. Yes, TCP is a bit more
                      resource intensive due to the TCP overhead. But
                      the biggest reason I prefer UDP is for
                      failover/redundancy. In the event of a system
                      failure/failover, UDP will be in-disrupted but TCP
                      will. Your TLS argument is valid, however.<br>
                      <br>
                      RTP will always be UDP. Think about it... TCP will
                      retransmit when packers are lost, but in real time
                      communication there is no need to retransmit.
                      While packet loss is problematic, a retransmission
                      of lost packets would be unexpected and cause
                      further quality issues.<br>
                      <div>
                        <div class="m_-1292223908235040841h5"><br>
                          <br>
                          <br>
                          On Jul 16, 2017, at 22:28, Colton Conor <<a
                            href="mailto:colton.conor@gmail.com"
                            target="_blank" moz-do-not-send="true">colton.conor@gmail.com</a>>
                          wrote:<br>
                          <br>
                          I know UDP seems to be the gold standard for
                          SIP, and is in use by most service providers
                          that are offering hosted voice today. My
                          question is why not use TCP instead of UDP for
                          SIP signaling?<br>
                          <br>
                          Overall with small business clients we run
                          into firewalls with SIP ALGs, short UDP
                          session time out limits, and all sorts of
                          connectivity issues with UDP. Some small
                          business routers and modems have built in SIP
                          ALGs that can't be disabled at all. The second
                          we switch to TCP for signaling most of the
                          issues go away for our hosted voice customers.
                          Overall TCP just always seems to work, and UPD
                          depends on the situation of the network. TCP
                          is better for battery consumption on mobile
                          sip applications as well.<br>
                          <br>
                          With more providers switching to encryption
                          using TLS which uses TCP, is there any need
                          for us UDP for signaling anymore? Assuming
                          most IP phones from Polycom, Yealink, and
                          Cisco support TCP why not use it? Is it more
                          resouce intensive on the SBCs?<br>
                          <br>
                          What about on the media side? Does the RTP use
                          UDP or TCP? If it uses UDP can TCP be used?
                          What about for encryption like SRTP? Is SRTP
                          TCP or UDP?<br>
                          <br>
                          <br>
                        </div>
                      </div>
                      ______________________________<wbr>_________________<br>
                      VoiceOps mailing list<br>
                      <a href="mailto:VoiceOps@voiceops.org"
                        target="_blank" moz-do-not-send="true">VoiceOps@voiceops.org</a><br>
                      <a
                        href="https://puck.nether.net/mailman/listinfo/voiceops"
                        rel="noreferrer" target="_blank"
                        moz-do-not-send="true">https://puck.nether.net/mailma<wbr>n/listinfo/voiceops</a><br>
                    </blockquote>
                  </div>
                  <br>
                </div>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
VoiceOps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>