[SR-Users] ACK and BYE routing - wrong interface problem and TCP/UDP conversion troubles

[Dmitry Sytchev]

Hi all!

I'm still working on incorrect routing of ACKs/BYEs with certain
conditions and asking for guru help.

My network looks like this:

192.168.4.218 -> TCP -> NAT (1.2.2.94) -> (1.2.0.160) Kamailio
(1.2.0.160) -> UDP-> backend servers (1.2.2.44).

IP address 1.2.0.16 is a 1.2.0.160/32  on loopback interface lo, and
it is announced via BGP to neighbours. There is also 1.2.3.46/30,
which is used to maintain BGP session.

Backends are Asterisk 11 machines with "outboundproxy" sip peer
setting set to Kamailio address.
Kamailio forwards registrations to Asterisk servers with
authentication and caches successful attempts to its internal DB.
Natted clients are managed adding 'received' param to reg contact.
When backend calls client, Kamailio takes correct URI from 'received'
and forwards request.

There is a possibility Kamailio will have several IP addresses for
outbound clients. To specify source address of forwarded packets I set
$fs. For initial requests and responses all works fine, but there are
troubles when dealing with ACKs and BYEs.

In case I don't specify interfaces with 'listen' , Kamailio listens on
1.2.0.160 and 1.2.3.46.
I use $fs to set 1.2.0.160 as outgoing interface, and it works for
requests. But when Kamailio forwards ACKs and BYEs, it uses 3.46
instead of 1.2.0.160, especially in case of TCP client and UDP
backend.

If I set mhomed = 0 and specify Kamailio to listen only to 1.2.0.160,
everything works fine, except UDP <-> TCP signalling conversion.
When natted TCP client receives call from backend, it answers with 200
OK and ACK from backend is never back to client. At the same time
UDP<->UDP works fine.

I've noted that TCP and UDP ACKs differ in Record-route headers, in
case of TCP there are two records of Kamailio UDP/TCP. I have
enable_double_rr = 1.

UDP ACK:
ACK sip:0097242 at 192.168.4.218:5063 SIP/2.0.
Via: SIP/2.0/UDP 1.2.2.44:5060;branch=z9hG4bK31d1a26c;rport.
Route: <sip:1.2.0.160;lr=on;ftag=as7af34000>.
Max-Forwards: 70.
From: <sip:8121230000 at 1.2.2.44>;tag=as7af34000.
To: <sip:0097242 at 192.168.4.218:5063;received=sip:1.2.2.94:64825>;tag=3122411720.
Contact: <sip:8121230000 at 1.2.2.44:5060>.
Call-ID: 56c5362d2250df6777e6665523964729 at 1.2.2.44:5060.
CSeq: 102 ACK.
User-Agent: Zero vPBX.
Content-Length: 0.

This ack forwarded to destination correctly (to external IP
1.2.2.94:64825). Actually, I don't understand why, because $du is null
and no functions logged that rURI was modified...

TCP ACK:
ACK sip:0097242 at 192.168.4.218:5062;transport=TCP SIP/2.0
Via: SIP/2.0/UDP 1.2.2.44:5060;branch=z9hG4bK08f7b9f2;rport
Route: <sip:1.2.0.160;r2=on;lr=on;ftag=as5cc06d60>,<sip:1.2.0.160;transport=tcp;r2=on;lr=on;ftag=as5cc06d60>
Max-Forwards: 70
From: <sip:8121230000 at 1.2.2.44>;tag=as5cc06d60
To: <sip:0097242 at 192.168.4.218:5062;transport=TCP;received=sip:1.2.2.94:57735;transport=TCP>;tag=4089422268
Contact: <sip:8121230000 at 1.2.2.44:5060>
Call-ID: 3a72968b552bdb8875e3215431f1522d at 1.2.2.44:5060
CSeq: 102 ACK
User-Agent: Zero vPBX
Content-Length: 0

This ack doesn't get forwarded anywhere, although Kamailio says:

DEBUG: <core> [forward.c:592]: forward_request(): Sending:#012ACK
sip:0097242 at 192.168.4.218:5062;transport=TCP SIP/2.0#015#012Via:
SIP/2.0/TCP 1.2.0.160;branch=z9hG4bK42a6.5e57399c6a2c1dae96f28c7381b6c64e.0#015#012Via:
SIP/2.0/UDP 1.2.2.44:5060;received=1.2.2.44;branch=z9hG4bK26130626;rport=5060#015#012Max-Forwards:
69#015#012From: <sip:8121230000 at 1.2.2.44>;tag=as74c521ed#015#012To:
<sip:0097242 at 192.168.4.218:5062;transport=TCP;received=sip:1.2.2.94:65535;transport=TCP>;tag=547751151#015#012Contact:
<sip:8121230000 at 1.2.2.44:5060>#015#012Call-ID:
10dfa7d00a9848c411a28bb54edf0f14 at 1.2.2.44:5060#015#012CSeq: 102
ACK#015#012User-Agent: Zero vPBX#015#012Content-Length:
0#015#012#015#012.

So I'm trying to understand - how Kamailio get correct destination
address to send to in case of UDP <-> UDP ack, and why the same
doesn't work in case of TCP?

If I turn on mhomed = 1, it breaks forwarding of UDP ACKs too... Maybe
it is because of 1.2.0.160/32 IP address it is placed on lo iface, or
there should be some entries in IP routing table on Kamailio host
allowing selection of 1.2.0.160?

Thanks in advance!


-- 
Best  regards,

Dmitry Sytchev,
IT Engineer