3 May
2006
3 May
'06
5:31 p.m.
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