<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 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: 'sip:xx.xxx.x.xx;lr;r2=on;ftag=a30a720a;did=b75.65a1;nat=yes' 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 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 sip:xxxxxx@xxxxxxxxxxxxx:42679;user=phone SIP/2.0<br>Via: SIP/2.0/UDP xxxxxxxxxxxxx:5060;branch=z9hG4bK218cc8e12ll5035f67INV6a67885312aad<br>Max-Forwards: 35<br>Route: <sip:xxxxxxxxxxx;lr;r2=on;ftag=daba971c;did=b57.4872;nat=yes><br>Route: <sip:xxxxxxxxxxx:5070;transport=tcp;lr;r2=on;ftag=daba971c;did=b57.4872;nat=yes><br>Contact: <sip:xxxxxxxxxx@xxxxxxxxxxxxx:5060><br>To: "xxxxxx"<sip:xxxxxx@xxxxxxxxxxxxxxxxxxxxxxxxxxx:5070>;tag=daba971c<br>From: <sip:xxxxxxxxxx@xxxxxxxxxxxxxxxxxxxxxxxxxxx:5070>;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>