[Kamailio-Devel] [ openser-Bugs-2663512 ] Kamailio 1.5.0:attempt to relay using TCP when source is UDP

SourceForge.net noreply at sourceforge.net
Mon Mar 30 11:42:33 CEST 2009


Bugs item #2663512, was opened at 2009-03-05 01:50
Message generated for change (Comment added) made by miconda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2663512&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: ver devel
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Thomas Mangin (thomasmangin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Kamailio 1.5.0:attempt to relay using TCP when source is UDP

Initial Comment:
I think I triggered a bug in kamailio. if I have disable_tcp set to no , it will try to relay some of my udp message using tcp and it will fail with
(failed to fwd to af 2, proto 2).
Nowhere in the config do I try to change the transport to TCP and the message received has no information about the transport neither (simple UDP
register).
Changing the option to yes, and the problem disappear.

Mar 4 23:24:08 proxy1 /usr/sbin/kamailio[14118]: ERROR:tm:update_uac_dst:
failed to fwd to af 2, proto 2 (no corresponding listening socket)
Mar 4 23:24:08 proxy1 /usr/sbin/kamailio[14118]: ERROR:tm:t_forward_nonack: failure to add branches

The destination is changed as follow to force the message to a particular
registrar machine using internal DNS routing.
$du = $fu;

U 82.219.212.1:5060 -> 82.219.7.1:5060
REGISTER sip:sip.mangin.com SIP/2.0.
Via: SIP/2.0/UDP 82.219.212.1:5060;branch=z9hG4bK-nWP-12227.
From: heidi <sip:heidi at sip.mangin.com:5060>;tag=isD-31803.
To: <sip:heidi at sip.mangin.com:5060>.
Call-ID: nAE-15238 at 82.219.212.1.
CSeq: 100 REGISTER.
Contact: <sip:heidi at 82.219.212.1>.
Max-Forwards: 70.
Expires: 600.
User-Agent: DrayTek UA-1.1.
Content-Length: 0.
.

#
U 82.219.7.1:5060 -> 82.219.212.1:5060
SIP/2.0 500 Server error occurred (2/TM).
Via: SIP/2.0/UDP
82.219.212.1:5060;branch=z9hG4bK-nWP-12227;rport=5060;received=82.219.212.1
.
From: heidi <sip:heidi at sip.mangin.com:5060>;tag=isD-31803.
To:
<sip:heidi at sip.mangin.com:5060>;tag=3196f0cfb660bda1c7e7428889893144-295c.
Call-ID: nAE-15238 at 82.219.212.1.
CSeq: 100 REGISTER.
Server: Exa SIP Proxy.
Content-Length: 0.
.

Feel free to contact me at : user thomas dot mangin domain exa-networks dot
co dot uk



----------------------------------------------------------------------

>Comment By: Daniel-Constantin Mierla (miconda)
Date: 2009-03-30 12:42

Message:
Can you print $ru and $du before calling t_relay() and post the output
here?

----------------------------------------------------------------------

Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-03-05 12:48

Message:
Please, open a thread in the user maillist instead of re-opening this
invalid bug.
As I already explained, Kamailio does a NAPTR DNS query (following RFC
3263, please read it) so:


- First does a NAPTR query for "mangin.com" (NOTE: I see you have removed
the TCP entry):

~$ host -t naptr mangin.com.
mangin.com has NAPTR record 10 100 "s" "SIP+D2U" "" _sip._udp.mangin.com.


- After it, chooses the appropiate entry (depending on the protocols the
proxy supports) and does a SRV query for it:

~$ host -t srv _sip._udp.mangin.com.
_sip._udp.mangin.com has SRV record 10 100 5060 in.sip.mangin.com.


- Later, chooses a result and does a A query:

~$ host -t a in.sip.mangin.com.
in.sip.mangin.com is an alias for in.sip.exa-voice.co.uk.
in.sip.exa-voice.co.uk has address 82.219.7.17


> So if it is normal for Kamailio to try a tcp connection, why did it fail
?

No idea, but this is not a bug in Kamailio, but in your network or
server.


> And if it is impossible to Kamailio to convert a UDP message to TCP why
is
> it attempted  it instead of using the UDP transport.

Why you say that about "converting a UDP into a TCP message"? It doesn't
make sense. A proxy can receieve a request via UDP/TCP/SCTP and forward it
via any protocol UDP/TCP/SCTP, why not?


PD: Please, follow this issue opening a new thread in users-mailist.
Thanks.

----------------------------------------------------------------------

Comment By: Thomas Mangin (thomasmangin)
Date: 2009-03-05 02:55

Message:
Thank you for the comment.

I will fully read RFC 3263 and RFC 2915 to make sure I understand your
conclusion. However the server pointed by _sip._tcp.mangin.com (which is
not the same as you can resolve) does indeed listen on TCP.

So if it is normal for Kamailio to try a tcp connection, why did it fail ?
And if it is impossible to Kamailio to convert a UDP message to TCP why is
it attempted  it instead of using the UDP transport.

I will fix the DNS now and remove TCP now that Kamailio is the destination
of all the SRV record for that domain.



----------------------------------------------------------------------

Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-03-05 02:37

Message:
~$ host -t naptr mangin.com
mangin.com has NAPTR record 10 100 "s" "SIP+D2T" ""
_sip\._tcp\.mangin\.com.
mangin.com has NAPTR record 10 100 "s" "SIP+D2U" ""
_sip\._udp\.mangin\.com.

SIP+D2T means TCP. Please take a look to RFC 3263 in which NAPTR DNS is
explained. The behaviour of Kamailio is just perfect in this case :)
So I close this bug as invalid.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2663512&group_id=139143



More information about the Devel mailing list