<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    t_relay() after loose_route() should simply use TCP if the second
    Route has r2=on and transport TCP.<br>
    <br>
    If not, send the log messages with debug=3 when handling the
    re-INVITE, maybe you force send socket via some other functions.<br>
    <br>
    Cheers,<br>
    Daniel<br>
    <br>
    <div class="moz-cite-prefix">On 16/06/15 22:50, Ryan Kendrick wrote:<br>
    </div>
    <blockquote
cite="mid:CAHvL_fQNJdqizHRP-cDpbvvOdJjynY0Rt0BTkPVTJQ9x5VZ4tg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_default" style="font-family:tahoma,sans-serif">After
          enabling and deciphering debugging it appears there may be a
          bug. I also reviewed <a moz-do-not-send="true"
            href="https://tools.ietf.org/html/rfc5658#section-6">https://tools.ietf.org/html/rfc5658#section-6</a><br>
          <br>
        </div>
        <div class="gmail_default" style="font-family:tahoma,sans-serif">I
          cross-referenced my pcap to ensure I was looking at the
          reINVITE and see:<br>
          <br>
          Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG:
          rr [loose.c:785]: after_loose(): <b>Topmost route URI:
            '<a class="moz-txt-link-freetext" href="sip:xx.xxx.x.xx;lr;r2=on;ftag=a30a720a;did=b75.65a1;nat=yes">sip:xx.xxx.x.xx;lr;r2=on;ftag=a30a720a;did=b75.65a1;nat=yes</a>'
            is me</b><br>
          Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG:
          <core> [socket_info.c:583]: grep_sock_info():
          grep_sock_info - checking if host==us: 11==11 &&
          [xx.xxx.x.xx] == [xx.xxx.x.xx]<br>
          Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG:
          <core> [socket_info.c:587]: grep_sock_info():
          grep_sock_info - checking if port 5060 (advertise 0) matches
          port 5061<br>
          Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG:
          <core> [socket_info.c:583]: grep_sock_info():
          grep_sock_info - checking if host==us: 11==11 &&
          [xx.xxx.x.xx] == [xx.xxx.x.xx]<br>
          Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG:
          <core> [socket_info.c:587]: grep_sock_info():
          grep_sock_info - checking if port 5070 (advertise 0) matches
          port 5061<br>
          Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG:
          <core> [socket_info.c:583]: grep_sock_info():
          grep_sock_info - checking if host==us: 11==11 &&
          [xx.xxx.x.xx] == [xx.xxx.x.xx]<br>
          Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG:
          <core> [socket_info.c:587]: grep_sock_info():
          grep_sock_info - checking if port 5090 (advertise 0) matches
          port 5061<br>
          Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG:
          <core> [socket_info.c:583]: grep_sock_info():
          grep_sock_info - checking if host==us: 11==11 &&
          [xx.xxx.x.xx] == [xx.xxx.x.xx]<br>
          Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG:
          <core> [socket_info.c:587]: grep_sock_info():
          grep_sock_info - checking if port 5061 (advertise 0) matches
          port 5061<br>
          Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG:
          <core> [parser/msg_parser.c:106]: get_hdr_field(): found
          end of header<br>
          Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG:
          rr [loose.c:181]: find_next_route(): <b>No next Route HF
            found</b><br>
          Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG:
          rr [loose.c:847]: after_loose(): no next URI found<br>
          <br>
        </div>
        <div class="gmail_extra">There is definitely another Route
          header immediately below the one found above, but
          find_next_route() doesn't find it
          <div class="gmail_default"
            style="font-family:tahoma,sans-serif;display:inline">​. I
            added my own debugging to loose.c and<br>
            <br>
            <span style="font-family:monospace,monospace">   if
              ((_m->last_header->type!=HDR_ROUTE_T) ||
              (_m->last_header==*_hdr)) {<br>
                    LM_DBG("No next Route HF found\n");<br>
                    LM_DBG("_m->last_header->type: %d\n",
              _m->last_header->type);<br>
                    return 1;<br>
                 }</span><br>
            <br>
          </div>
          <div class="gmail_default"
            style="font-family:tahoma,sans-serif;display:inline">logs
            find_next_route(): _m->last_header->type: 12 which is
            HDR_CONTENTLENGTH_T which is indeed the LAST header in the
            message. We have done very little work in the Kamailio
            source...just some database escaping in odbc for things to
            work properly with our database engine...but unless I'm
            missing something isn't it very wrong to be looking at the
            last header right here? I may attempt to figure out the
            message and/or hdr_field data structures and change it. It
            may also be that the issue doesn't occur when
            find_next_route is called with a valid _hdr which does seem
            to search for the "next" one vs going straight to the final
            header in the entire message.<br>
            <br>
          </div>
          <div class="gmail_default"
            style="font-family:tahoma,sans-serif;display:inline">If this
            is getting overly complicated for this mailing list please
            let me know...<br>
          </div>
          <div class="gmail_default"
            style="font-family:tahoma,sans-serif;display:inline"><br>
          </div>
          <div class="gmail_default"
            style="font-family:tahoma,sans-serif;display:inline">Ryan<br>
          </div>
          <div class="gmail_default"
            style="font-family:tahoma,sans-serif;display:inline">​</div>
          <br>
          <div class="gmail_quote">On Tue, Jun 16, 2015 at 11:40 AM,
            Ryan Kendrick <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:kendrick.ryan.c@gmail.com" target="_blank">kendrick.ryan.c@gmail.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div dir="ltr">
                <div style="font-family:tahoma,sans-serif">​​</div>
                <div style="font-family:tahoma,sans-serif">We are using
                  Kamailio 4.2.5 as a registrar and proxy between many
                  dispersed end-users of a soft phone app and our
                  calling platform / switch.<br>
                  <br>
                </div>
                <div style="font-family:tahoma,sans-serif">Until now we
                  have used udp exclusively but are trying to introduce
                  tcp between end-users and Kamailio, leaving udp
                  between Kam and our switch...while maintaining the
                  ability for some end-users to use udp to Kam.<br>
                  <br>
                </div>
                <div style="font-family:tahoma,sans-serif">With some
                  simple address checks I am able to always send to our
                  switch over udp. If all end-users used tcp I could
                  send everything else tcp, but I need to maintain udp
                  support.<br>
                  <br>
                </div>
                <div style="font-family:tahoma,sans-serif">The specific
                  problem I am having is on a reINVITE such as this one
                  from our platform to the a-leg:<br>
                  <br>
                  INVITE <a class="moz-txt-link-freetext" href="sip:xxxxxx@xxxxxxxxxxxxx:42679;user=phone">sip:xxxxxx@xxxxxxxxxxxxx:42679;user=phone</a>
                  SIP/2.0<br>
                  Via: SIP/2.0/UDP
                  xxxxxxxxxxxxx:5060;branch=z9hG4bK218cc8e12ll5035f67INV6a67885312aad<br>
                  Max-Forwards: 35<br>
                  Route:
                  <a class="moz-txt-link-rfc2396E" href="sip:xxxxxxxxxxx;lr;r2=on;ftag=daba971c;did=b57.4872;nat=yes"><sip:xxxxxxxxxxx;lr;r2=on;ftag=daba971c;did=b57.4872;nat=yes></a><br>
                  Route:
<a class="moz-txt-link-rfc2396E" href="sip:xxxxxxxxxxx:5070;transport=tcp;lr;r2=on;ftag=daba971c;did=b57.4872;nat=yes"><sip:xxxxxxxxxxx:5070;transport=tcp;lr;r2=on;ftag=daba971c;did=b57.4872;nat=yes></a><br>
                  Contact: <a class="moz-txt-link-rfc2396E" href="sip:xxxxxxxxxx@xxxxxxxxxxxxx:5060"><sip:xxxxxxxxxx@xxxxxxxxxxxxx:5060></a><br>
                  To:
                  "xxxxxx"<a class="moz-txt-link-rfc2396E" href="sip:xxxxxx@xxxxxxxxxxxxxxxxxxxxxxxxxxx:5070"><sip:xxxxxx@xxxxxxxxxxxxxxxxxxxxxxxxxxx:5070></a>;tag=daba971c<br>
                  From:
<a class="moz-txt-link-rfc2396E" href="sip:xxxxxxxxxx@xxxxxxxxxxxxxxxxxxxxxxxxxxx:5070"><sip:xxxxxxxxxx@xxxxxxxxxxxxxxxxxxxxxxxxxxx:5070></a>;tag=6a678853-co76461-INS002<br>
                  Call-ID: MDI4ZmFjNmZhN2Y1NWE2ZTViNTkyZGUwNWE2YzUzYmU<br>
                  CSeq: 7646101 INVITE<br>
                  Allow:
                  INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,INFO,UPDATE<br>
                  Content-Type: application/sdp<br>
                  Date: Mon, 15 Jun 2015 20:10:18 GMT<br>
                  User-Agent:
                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br>
                  Content-Length: 262<br>
                  <br>
                </div>
                <div style="font-family:tahoma,sans-serif">As you might
                  notice, we have rr:enable_double_rr set:<br>
                  <br>
                  <i>There are some situations when the server needs to
                    insert two Record-Route header fields instead of
                    one. For example when using two disconnected
                    networks or doing cross-protocol forwarding from
                    UDP->TCP. This parameter enables inserting of 2
                    Record-Routes. The server will later remove both of
                    them. </i><br>
                  <br>
                </div>
                <div style="font-family:tahoma,sans-serif">and I believe
                  it is necessary to keep this way. Without it Kamailio
                  doesn't even see the reINVITE...the switch probably
                  tries tcp and that's not setup between the two.<br>
                  <br>
                </div>
                <div style="font-family:tahoma,sans-serif">The invite
                  above is sent to the a-leg over udp but I would expect
                  and need it to be tcp in this case. The reINVITE is
                  part of an existing dialog. We call loose_route()
                  followed by some simple bflag setting and flag
                  checking, t_on_reply(), ... then t_relay().<br>
                  <br>
                </div>
                <div style="font-family:tahoma,sans-serif">I do have a
                  functional workaround but would prefer to avoid such
                  manual handling by utilizing built-in functionality
                  properly.<br>
                  <span style="font-family:monospace,monospace"><br>
                       #                              <br>
                       # relay the message            <br>
                       #                              <br>
                       if(route(TEST_TOGW)) {         <br>
                          if (!t_relay_to_udp()) {    <br>
                             sl_reply_error();        <br>
                          }                           <br>
                       }                              <br>
                       else {<br>
                          if (</span><span
                    style="font-family:monospace,monospace"><span
                      style="font-family:monospace,monospace">$(hdr(Route)[-1])</span>
                    =~ "tcp") {     <br>
                             if(!t_relay_to_tcp()) {  <br>
                                sl_reply_error();     <br>
                             }                        <br>
                          }                           <br>
                          else if (!t_relay()) {      <br>
                             sl_reply_error();        <br>
                          }          <br>
                       }  </span>                            <br>
                  <br>
                </div>
                <div style="font-family:tahoma,sans-serif">I'm not 100%
                  sure how reliable or fast this will be, but it does
                  work so far in my simple tests.<br>
                  <br>
                </div>
                <div style="font-family:tahoma,sans-serif">Is
                  loose_route supposed to see and use the transport=tcp
                  but isn't for some reason? It seems like the right
                  thing to do to me. If not, is there anything else I
                  can/should be doing in the tm and/or rr modules to
                  make Kamailio realize it needs to send this message
                  over TCP? If not in those two modules is there some
                  recommended way perhaps via registrar or usrloc etc.
                  to make Kamailio remember/store when a user is
                  connected via TCP and be able to do a quick lookup
                  before sending to them? Anything else I'm missing or
                  not thinking of?<br>
                  <br>
                </div>
                <div style="font-family:tahoma,sans-serif">Please let me
                  know if I can further explain and rest assured any
                  assistance will be much appreciated!!!<br>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Book: SIP Routing With Kamailio - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a></pre>
  </body>
</html>