R: R: [Serusers] SER -> PSTN Gateway+NAT: BYE handling problem

Fabio Macchi f.macchi at keeptelecom.com
Fri Mar 16 14:04:54 CET 2007


Hello,
I'm using Nathelper + RTPproxy ( can't use Nathelper-only because my gateway
doesn't support passive mode ) : route part of ser.cfg attached.

In the invite block I use force_rport before authorize block ( as previous
discussed ) and the NAT block after:

route[4] {

        # -----------------------------------------------------------------
        # NAT Traversal Section
        # -----------------------------------------------------------------
        if (isflagset(6)) {
                force_rport();
                fix_nated_contact();
                force_rtp_proxy();
        }

}



The original BYE comes from Gateway with the wrong request URI ( private UA
ip )

Request-Line: BYE sip:xxxxxx at 1.255.17.9 SIP/2.0
        Method: BYE
        [Resent Packet: False]


Fabio


-----Messaggio originale-----
Da: Kostas Marneris [mailto:K.Marneris at otenet.gr] 
Inviato: venerdì 16 marzo 2007 13.19
A: Fabio Macchi
Cc: Kostas Marneris
Oggetto: Re: R: [Serusers] SER -> PSTN Gateway+NAT: BYE handling problem

Hello,

Which 'NAT Traversal mechanism' do you use ?
Nathelper only or Mediaproxy ?

Do you change the Contact address somewhere in INVITE block ?

                        force_rport();
                        fix_nated_contact();
                        fix_nated_sdp("3");

Check (with a tcpdump at SER) how the original BYE comes from GW.
What is the R-URI at the original BYE request (comes from GW) ?


Kostas


Fabio Macchi wrote:
> First, thanks for answer.
> 
> I've tryed your trik and in effect this solve the problem of the '200 ok'
> forwarded to the UA, but my problem still remain alive: when BYE is sent
> from Gateway, it reaches correctly SER, but it still forward it to the
> private UA address. I was wondering about the nat_uac_test in this case,
as
> the source of the BYE message is the gateway ( not natted ) and not the
UA.
> 
> Have any idea about this ?
> 
> Fabio
> 
> -----Messaggio originale-----
> Da: Kostas Marneris [mailto:K.Marneris at otenet.gr] 
> Inviato: giovedì 15 marzo 2007 20.39
> A: Fabio Macchi
> Cc: serusers at lists.iptel.org
> Oggetto: Re: [Serusers] SER -> PSTN Gateway+NAT: BYE handling problem
> 
> Hello, 
> I was working on about the same problem today either with 'Mediaproxy
> solution' 
> or with 'SER's Nathelper only solution' .
> 
> The NAT issue is a nightmare, not because of SER but because of 
> different implementations on NAT boxes.
> 
> Actually my problem was :
> if the NATed UA send a BYE to SER, SER forward it to PSTN-GW,
> then the '200 Ok' Response from PSTN-GW is forwarded by SER to UA
> to the wrong port (Contact or Via header port).
> 
> I used the following block on Loose Route section, 
> (because BYE is loose_routed if you use Record-Route),
> and it seems to work.
> 
>         # ---------------------------------------
>         # Loose Route Section
>         # ---------------------------------------
>         if (loose_route()) {
>                 # mark routing logic in request
>                 if (method == "BYE") {
>                         if (nat_uac_test("22")) {
>                                 xlog("L_NOTICE", "*** LR -> NATed BYE -
Use
> force_rport()");
>                                 force_rport();
>                         };
>                 };
>                 route(1);
>                 break;
>         };
> 
> 
> 
> 
> I faced up your second problem too. 
> The solution was to move the NAT handling block before proxy_authorize
> block.
> 
> I think that the different behaviour does not come with the 'standard
> RFC1918 addresses',
> but with the different NAT type.
> 
> I realize that the provisional mesgs '100 Trying' and '407 Proxy
> Authentication Required' 
> are relayed back to the real IP addr of NATed UA (this is correct),
> but to the WRONG port (that of Contact/Via header and not the signalling
> received port).
> It seems that these mesgs use the IP address part of 'Received' field of
> Location DB
> but not the port. 
> 
> It happens to work if NAT box use the SAME port (eg. 5060) on NAT
> translation
> (10.10.10.1:5060  --> Real_IP:5060) (eg. with a SAGEM1500 Router)
> But it does not work if NAT box doesn't use the same port
> (10.10.10.1:5060  --> Real_IP:38181)
> 
> 
> I think that this has to be verified by SER developers or SER experts. 
> 
> 
> 
> Kostas
> 
> ---
> K.Marneris at otenet.gr
> 
> ----- Original Message ----- 
> From: "Fabio Macchi" <f.macchi at keeptelecom.com>
> To: <serusers at lists.iptel.org>
> Sent: 15 March 2007 19:34
> Subject: [Serusers] SER -> PSTN Gateway+NAT: BYE handling problem
> 
> 
>> Hi all,
>>
>>
>>
>> I'm running the following schema:
>>
>>
>>
>> UA ( possibly natted ) -> SER -> PSTN Gateway 
>>
>>
>>
>> I have a problem with UA belonging to a particular network with private
>> address not RFC1918 compliant ( class 1.x.x.x ), SER and PSTN Gateway
have
>> pubblic address.
>>
>>
>>
>> The problem is that, after a succesfull call, if the PSTN gateway send a
> BYE
>> to SER, then SER forward BYE to the private address of UA instead of
> pubblic
>> one.
>>
>>
>>
>> I don't understand which is the section that handle BYE messages and how
> can
>> I solve this problem: anyone may help ?
>>
>>
>>
>>
>>
>>
>>
>> Second, another question: with this particular network I had problem with
>> INVITE too, because SER was sending "proxy authorization request" to the
>> wrong TCP port. To solve this, I've moved the nat handling ( with
>> force_rport ) before the proxy_authorize block and it's working, but why
>> this is not necessary on standard RFC1918 compliant natted address ? 
>>
>>
>>
>> Many thanks for any explanation
>>
>>
>>
>> Fabio
>>
>>
> 
> 
> 
> 

-- 
Kostas Marneris
e-mail: K.Marneris at otenet.gr
Tel   : +30-210-6151886
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ser.cfg route block.txt
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20070316/53fe3a74/attachment.txt>


More information about the sr-users mailing list