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

[Greger V. Teigre]

Normally this happens because you haven't fixed the Contact if the 
original INVITE or OK.
g-)

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
>>
>>
>>     
>
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20070320/2ecab8d5/attachment.htm>