Life without UDP 5060

[bolvan]

Seems like no calls possible if there's no udp listener on port 5060.
If default listener is tcp or tls  then both client hang up in 15 seconds, no voice is transmitted.
If I setup 2 listeners, one tcp, another udp, setup both clients to use tcp - then calls proceed.
In log file I see that client on some stage sends udp message and server receives it. This fact recovers situation. But its wrong, because udp should not be used.
My task is to setup secure tls communication (TLS+SRTP).
I tried on eyebeam 1.5 and 3CXphone 6. Situation is the same.

First log i made with only tcp listener (calls hangup in 15 secs) :
http://pastebin.com/yYHEFUgb

Second log I made with tcp+udp listener, calls proceed :
http://pastebin.com/gCDsx9t5

c1.c1.c1.c1 - IP of first client
c2.c2.c2.c2 - IP of second client
s.s.s.s - IP of server

difference starts at line 303.

[marian]

It seems there is an issue with the Contact header.
Yate sends the Contact header with local ip/port.
The second log shows the ACK to OK comes on UDP (which uses the same port as TCP, 5060).
I suspect the failure in the first log is due to the fact the remote client sends the ACK on UDP port 5061.

If you can, try to set the contact header when answering:

regexroute example:

[extra]
call.answered=50

[call.answered]
.*=;osip_Contact=sip:103@s.s.s.s:5061$(chr,59)transport=TLS

Replace your s.s.s.s with your ip.
This should work.

If you try a Yate Client with a TLS only listener it will work anyway.

[bolvan]

Seems  you're right.
The problems is missing ";transport=TLS" in "Contact:".

I managed to setup freeswitch in the same configuration. It works just fine.
The only SIP server I managed to configure for my task without problems at all. Even asterisk failed directmedia with SRTP.

Here is the log :
http://pastebin.com/c5hfKgrg


I believe this problem should be treated as BUG and submitted to yate developers.
Because more than one popular SIP clients have major incompatibility

[Atik]

Its a maybe TLS implementation bug, pjsip drop calls, see the ticket bellow.

https://trac.pjsip.org/repos/ticket/1735

[Atik]

Any update on this? This break compatibility with other TLS client, hope this bug will be fixed soon, :-)

[fheynert]

I like to bring this topic up again :-)


I do have a separate Listener Configured for TLS with NAT,
It Works if I call in via TLS-NAT and the internal Endpoint uses UDP Only..
As soon as I use TCP or TLS on the Internal Client I do have bidirectional RTP, but the call gets disconnected after 15 sec.

So question:
Optimising th call.answer section is probably on solution.
But I do not get the advantage / disadvantage of the contact type set with the transport type or not.

I updated to release 6.0 but it is still the same .
Could someone colaborate on this?