Hello all,
I'm trying to find a solution to overcome the NAT issue using only the nathelper module. (I've already successfully worked with 'STUN' & 'MediaProxy' solutions but I'm trying also this).
1. OUTBOUND direction: --- INVITE handler --- ... # NAT Traversal mechanism for INVITEs if (nat_uac_test("19")) { setflag(7); force_rport(); fix_nated_contact(); fix_nated_sdp("3"); }; # ...
The solution above works fine for OUTBOUND calls, either on-net (a) or off-net (b). (For off-net calls I use a Cisco GW).
a/ SIP_UA_behind_NAT -------- SER ------- SIP_UA_on_public_IP b/ SIP_UA_behind_NAT -------- SER ------- Cisco_PSTN_GW ------- PSTN
2. INBOUND direction: route[1] { # Default Message Handler t_on_reply("1"); if (!t_relay()) { log(1, " - Cannot RELAY !!!"); sl_reply_error(); }; }
onreply_route[1] { if (nat_uac_test("19")) { log(1, " - Response behind NAT..."); setflag(7); force_rport(); fix_nated_contact(); fix_nated_sdp("3"); };
}
Although I have two-way audio between calling and called parties, I get the following logging mesgs :
May 3 17:22:26 server ./ser[13705]: ERROR: extract_body: message body has length zero May 3 17:22:26 server ./ser[13705]: ERROR: fix_nated_sdp: cannot extract body from msg! May 3 17:22:26 server ./ser[13705]: ERROR: on_reply processing failed
My question is : Is the above the correct way for NAT traversal of SIP Responses (200 OK) ? Do I have to add something else somewhere in ser.cfg ? Any idea on the log mesgs above ?
thanks in advance for any help, Kostas