[Serusers] NAT Traversal using nathelper module

[O.]

Hi Kostas and samuel,

In the case you are describing, using nathelper will replace the
rtpproxy or medianproxy? It looks to me that in this case the rtp will
be route in between the sip client, without any proxy. In the
configuration you mentioned the ser is on public IP?     
if this is the case it looks much better the proxy from the load
prospective.   

thanks, 
O.


On Thu, 2006-05-04 at 14:52 +0300, Kostas Marneris wrote:
> thanks a lot.
> 
> I use the following and everything seems Ok ...
> 
> 
> onreply_route[1] {
>         if (status=~"(180)|(183)|2[0-9][0-9]") {
>                 if (!search("^Content-Length:[ ]*0")) {
>                         if (nat_uac_test("13")) {
>                                 log(1, " - Reply behind NAT...");
>                                 setflag(7);
>                                 force_rport();
>                                 fix_nated_contact();
>                                 fix_nated_sdp("3");
>                         };
>                 };
>         };
> 
> }
> 
> 
> Kostas
> 
> samuel wrote:
> > I would add a condition like
> > 
> >  if (!search("^Content-Length:[ ]*0")) {
> >        fix_mated_sdp()
> >  }
> > 
> > So replies without body (180,100,101,...) will not raise the ERROR you
> > have in the logs.
> > 
> > It would be also nice to check wether the reply is not an error (>299)
> > so you do not need to use NAT transversal for error replies.
> > if (status=~"(180)|(183)|2[0-9][0-9]") {
> > 
> > }
> > I recommend you to check www.onsip.org and the discussion about the
> > on_reply route in the getting started and the config files.
> > 
> > Hope it helps,
> > 
> > Samuel.
> > 
> > 
> > 2006/5/3, Kostas Marneris <K.Marneris at otenet.gr>:
> > 
> >>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
> >>
> >>_______________________________________________
> >>Serusers mailing list
> >>serusers at lists.iptel.org
> >>http://lists.iptel.org/mailman/listinfo/serusers
> >>
> > 
> > 
> > 
> > 
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers