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

Kostas Marneris K.Marneris at otenet.gr
Tue Mar 20 21:06:08 CET 2007


Hello,
What I understand (from Frame12)

Session Initiation Protocol
    Request-Line: BYE sip:000003 at 1.255.ua_priv__IP SIP/2.0

is that your GW does not comply with the fixed SIP UA Contact address
    Contact: <sip:000003 at 213.156.ua_pub_IP:1176>
which SER seems to correctly fix it (from Frame6).

GW must send the BYE request back to the fixed addr : 213.156.ua_pub_IP:1176.


Try a different PSTN-GW or try to isolate the RTP-Proxy solution.

I am really confused of your ser.cfg.
You use force_rtp_proxy("l") on Loose Route Section / INVITE block,
but you don't use force_rtp_proxy() on INVITE handler (Route[3])
and you don't also use rtp_proxy on BYE block at Loose Route Section.


I tried this senario without Mediaproxy or RTPproxy with success.


regards,
Kostas

---
K.Marneris at otenet.gr

----- Original Message ----- 
From: "Fabio Macchi" <f.macchi at keeptelecom.com>
To: <greger at teigre.com>
Cc: "'Kostas Marneris'" <K.Marneris at otenet.gr>; <serusers at lists.iptel.org>
Sent: 20 March 2007 19:56
Subject: R: R: [Serusers] SER -> PSTN Gateway+NAT: BYE handling problem


Hi Greger,



I attached an ethereal SIP call trace of a test call ( summary and detailed,
I simple maskerade final ip numbers ): below only the INVITE relayed from
proxy to gateway:



Session Initiation Protocol

    Request-Line: INVITE sip:9999001234 at 194.244.gatewayIP:5060 SIP/2.0

        Method: INVITE

        [Resent Packet: False]

    Message Header

        Record-Route: <sip:194.244.Proxy__IP;ftag=12e1e2e19d527792;lr=on>

        Via: SIP/2.0/UDP 194.244.Proxy__IP;branch=z9hG4bKb24f.5133a2c4.0

            Transport: UDP

            Sent-by Address: 194.244.Proxy__IP

            Branch: z9hG4bKb24f.5133a2c4.0

        Via: SIP/2.0/UDP
1.255.ua_priv__IP;rport=1176;received=213.156.ua_pub_IP;branch=z9hG4bK35ca7a
df63e3094f

            Transport: UDP

            Sent-by Address: 1.255.ua_priv__IP

            RPort: 1176

            Received: 213.156.ua_pub_IP

            Branch: z9hG4bK35ca7adf63e3094f

        From: "000003" <sip:000003 at 194.244.Proxy__IP>;tag=12e1e2e19d527792

            SIP Display info: "000003"

            SIP from address: sip:000003 at 194.244.Proxy__IP

            SIP tag: 12e1e2e19d527792

        To: <sip:9999001234 at 194.244.Proxy__IP>

            SIP to address: sip:9999001234 at 194.244.Proxy__IP

        Contact: <sip:000003 at 213.156.ua_pub_IP:1176>

            Contact Binding: <sip:000003 at 213.156.ua_pub_IP:1176>

                URI: <sip:000003 at 213.156.ua_pub_IP:1176>

                    SIP contact address: sip:000003 at 213.156.ua_pub_IP:1176

        Supported: replaces

        Call-ID: 953e8996cfcc4ccc at 1.255.ua_priv__IP

        CSeq: 60577 INVITE

            Sequence Number: 60577

            Method: INVITE

        User-Agent: Grandstream HT386 1.0.3.64 FXS0

        Max-Forwards: 16

        Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE

        Content-Type: application/sdp

        Content-Length: 327

    Message body



As you can see, contact informations are correctly fixed with the pubblic UA
address, but when the callee hungs up, the BYE is relayed to the private IP
address: am I missing something ?

In this invite I see UA private address only in VIA: does BYE look to this
parameter ?

Later caller hangs up too, and the OK is relayed to the correct IP/port.



Any help would be high appreciate, thanks in advance.



Fabio





  _____

Da: Greger V. Teigre [mailto:greger at teigre.com]
Inviato: martedμ 20 marzo 2007 9.59
A: Fabio Macchi
Cc: 'Kostas Marneris'; serusers at lists.iptel.org
Oggetto: Re: R: [Serusers] SER -> PSTN Gateway+NAT: BYE handling problem



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"  <mailto:f.macchi at keeptelecom.com>
<f.macchi at keeptelecom.com>
To:  <mailto:serusers at lists.iptel.org> <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






--------------------------------------------------------------------------------


No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.15/728 - Release Date: 20/03/2007 08:07




More information about the sr-users mailing list