[SR-Users] loose_route to find transport=tcp
Ryan Kendrick
kendrick.ryan.c at gmail.com
Wed Jun 17 21:45:01 CEST 2015
Daniel, see attached (attachment sent in a duplicate email sent just to
your miconda address earlier today 10:26 CDT -- I'm told you don't
routinely check that one). I added some logging with "RCK" in them. It
should be pretty clear what I'm logging with them. You can see r2 and
transport=tcp are set.
I checked for the protocol on puri and it is TCP, I also logged the socket
force_send_socket in loose_route is called with and it is tcp. So up to
that point it seems that kamailio has found the socket I need. Then a
little lower I see this:
[forward.c:268]: get_send_socket2(): protocol/port mismatch (forced
tcp:xx.xxx.x.xx:5070, to udp:yy.yyy.yy.yyy:16929)
The 66.68 is my local machine connected to kamailio solely via tcp.
But I only get that message when I remove udp 5070 as a listen=
When I listen on tcp 5070 and udp 5070 it still chooses udp but doesn't
make that log write. So in either case it looks like it did find tcp in the
second route header, calls set_force_socket() with a tcp socket, but
somewhere down the line gets sent udp. We don't have any explicit force
sends that would trigger for this message in our routing.
Regards,
Ryan
On Wed, Jun 17, 2015 at 2:29 AM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:
> t_relay() after loose_route() should simply use TCP if the second Route
> has r2=on and transport TCP.
>
> If not, send the log messages with debug=3 when handling the re-INVITE,
> maybe you force send socket via some other functions.
>
> Cheers,
> Daniel
>
>
> On 16/06/15 22:50, Ryan Kendrick wrote:
>
> After enabling and deciphering debugging it appears there may be a bug.
> I also reviewed https://tools.ietf.org/html/rfc5658#section-6
>
> I cross-referenced my pcap to ensure I was looking at the reINVITE and
> see:
>
> Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG: rr
> [loose.c:785]: after_loose(): *Topmost route URI:
> 'sip:xx.xxx.x.xx;lr;r2=on;ftag=a30a720a;did=b75.65a1;nat=yes' is me*
> 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]
> 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
> 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]
> 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
> 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]
> 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
> 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]
> 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
> Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG: <core>
> [parser/msg_parser.c:106]: get_hdr_field(): found end of header
> Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG: rr
> [loose.c:181]: find_next_route(): *No next Route HF found*
> Jun 16 15:01:29 xxxxxxxxxxxxx /usr/sbin/kamailio[643]: DEBUG: rr
> [loose.c:847]: after_loose(): no next URI found
>
> There is definitely another Route header immediately below the one found
> above, but find_next_route() doesn't find it
> . I added my own debugging to loose.c and
>
> if ((_m->last_header->type!=HDR_ROUTE_T) || (_m->last_header==*_hdr)) {
> LM_DBG("No next Route HF found\n");
> LM_DBG("_m->last_header->type: %d\n", _m->last_header->type);
> return 1;
> }
>
> 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.
>
> If this is getting overly complicated for this mailing list please let
> me know...
>
> Ryan
>
>
> On Tue, Jun 16, 2015 at 11:40 AM, Ryan Kendrick <kendrick.ryan.c at gmail.com
> > wrote:
>
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> The specific problem I am having is on a reINVITE such as this one from
>> our platform to the a-leg:
>>
>> INVITE sip:xxxxxx at xxxxxxxxxxxxx:42679;user=phone SIP/2.0
>> Via: SIP/2.0/UDP
>> xxxxxxxxxxxxx:5060;branch=z9hG4bK218cc8e12ll5035f67INV6a67885312aad
>> Max-Forwards: 35
>> Route: <sip:xxxxxxxxxxx;lr;r2=on;ftag=daba971c;did=b57.4872;nat=yes>
>> Route:
>> <sip:xxxxxxxxxxx:5070;transport=tcp;lr;r2=on;ftag=daba971c;did=b57.4872;nat=yes>
>> Contact: <sip:xxxxxxxxxx at xxxxxxxxxxxxx:5060>
>> To: "xxxxxx"<sip:xxxxxx at xxxxxxxxxxxxxxxxxxxxxxxxxxx:5070>;tag=daba971c
>> From: <sip:xxxxxxxxxx at xxxxxxxxxxxxxxxxxxxxxxxxxxx:5070>
>> ;tag=6a678853-co76461-INS002
>> Call-ID: MDI4ZmFjNmZhN2Y1NWE2ZTViNTkyZGUwNWE2YzUzYmU
>> CSeq: 7646101 INVITE
>> Allow:
>> INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,INFO,UPDATE
>> Content-Type: application/sdp
>> Date: Mon, 15 Jun 2015 20:10:18 GMT
>> User-Agent: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> Content-Length: 262
>>
>> As you might notice, we have rr:enable_double_rr set:
>>
>> *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. *
>>
>> 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.
>>
>> 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().
>>
>> I do have a functional workaround but would prefer to avoid such manual
>> handling by utilizing built-in functionality properly.
>>
>> #
>> # relay the message
>> #
>> if(route(TEST_TOGW)) {
>> if (!t_relay_to_udp()) {
>> sl_reply_error();
>> }
>> }
>> else {
>> if ($(hdr(Route)[-1]) =~ "tcp") {
>> if(!t_relay_to_tcp()) {
>> sl_reply_error();
>> }
>> }
>> else if (!t_relay()) {
>> sl_reply_error();
>> }
>> }
>>
>> I'm not 100% sure how reliable or fast this will be, but it does work
>> so far in my simple tests.
>>
>> 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?
>>
>> Please let me know if I can further explain and rest assured any
>> assistance will be much appreciated!!!
>>
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Book: SIP Routing With Kamailio - http://www.asipto.com
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150617/b968fa87/attachment.html>
More information about the sr-users
mailing list