[Spce-user] BYE not correct when sent by called party

[Jirka Jirout]

Hello,

I have a problem with my client app. Both ends are connected via TLS on port 5889 of the LB. When the calling party terminates the call, it sends this and the call terminates correctly:

> BYE sip:127.0.0.1:5080 SIP/2.0'
> ...
> Record-Route: <sip:127.0.0.1:5888;ngcplb=yes;ftag=334359690;lr=on>'
> Record-Route: <sip:SERVER_PUBLIC_IP:5889;transport=tls;ftag=334359690;lr=on>'
> Via: SIP/2.0/UDP 127.0.0.1:5888;branch=z9hG4bKa6f1.654eced0f96edbfaf849c6c2ce831b08.0;i=d951'
> Via: SIP/2.0/TLS 192.168.178.23:54256;received=83.161.151.39;rport;branch=z9hG4bK685900316;rport=54256'
> From: <sip:611092 at OUR_DOMAIN>;tag=334359690'
> To: <sip:279208 at OUR_DOMAIN>;tag=46CD768A-5141E4A8000DAE1F-D32F2700'
> ...
> Route: <sip:127.0.0.1:5888;nat=yes;ngcplb=yes;ftag=334359690;lr=on>'
> Route: <sip:127.0.0.1:5062;lr=on;ftag=334359690;did=f08.4e81;mpd=ii;rtpprx=yes;vsf=dU5ZM1lleEZ6TkxNaUpYTlBkZk11TlkzWWV4Rno->'

When however the called party terminates the call, the packet looks like:

> BYE sip:127.0.0.1:5080 SIP/2.0'
> ...
> Record-Route: <sip:127.0.0.1:5888;ngcplb=yes;ftag=1501122437;lr=on>'
> Record-Route: <sip:SERVER_PUBLIC_IP:5889;transport=tls;ftag=1501122437;lr=on>'
> Via: SIP/2.0/UDP 127.0.0.1:5888;branch=z9hG4bKcc48.1dec6a8cec99aabfe552815890f9cfa7.0;i=8351'
> Via: SIP/2.0/TLS 192.168.178.46:60714;received=83.161.151.39;rport;branch=z9hG4bK1819339446;rport=60714'
> From: <sip:279208 at OUR_DOMAIN>;tag=1501122437'
> To: <sip:611092 at OUR_DOMAIN>;tag=0A95611E-5141E52C000C3E89-D81C3700'
> ...
> Route: <sip:127.0.0.1:5888;ftag=0A95611E-5141E52C000C3E89-D81C3700;lr=on>'

And the called party receives 403 Domain not served here

The kamailio log shows:

Mar 14 15:56:57 server /usr/sbin/kamailio[399]: WARNING: <core> [forward.c:268]: WARNING: get_send_socket: protocol/port mismatch (forced udp:127.0.0.1:5888, to tls:83.161.151.39:60714)

Now, I was under the impression, that the answers are always sent by using Via headers. Here it does not appear to be the case and . We will of course try to solve this in our client app's code, but I was wondering whether this could be somehow fixed on the server side only.

regards, jj