no audio from caller when using nathelper

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

no audio from caller when using nathelper

Gabriel Bermudez
Hi everyone,

I'm using the nathelper and dispatcher module to send calls to an
Asterisk server.  I'm using the Asterisk as a SIP to H.323 converter
because our PSTN gateway only speaks H.323
For some reason *sometimes* the caller does not send RTP traffic to the
opensips (one way audio).  The caller's UA is behind a NAT, but it
doesn't gets detected as a nated UA, so the RTP flow is between the
client's public IP and the Asterisk public IP (rtpproxy is not used).  
I'm not sure if this problems happens also with UAs that get NAT
detected (not seen it happen).  I used tshark to capture the invite from
an undetected NAT UA (changed the UA ip with *uac_public_ip* and
opensip's ip with *opensips_public_ip*)

Session Initiation Protocol
    Request-Line: INVITE sip:0059389954277@opensips_public_ip SIP/2.0
        Method: INVITE
        [Resent Packet: False]
    Message Header
        To: <sip:0059389954277@opensips_public_ip>
            SIP to address: sip:0059389954277@opensips_public_ip
        Accept:
application/dtmf-relay,application/sdp,text/plain,message/sipfrag,application/sip
        User-Agent: YV1/1.2.0
        Via: SIP/2.0/UDP uac_public_ip:10759;rport;branch=z9hG4bK474bfa15
            Transport: UDP
            Sent-by Address: uac_public_ip
            Sent-by port: 10759
            RPort: rport
            Branch: z9hG4bK474bfa15
        From: "710406702"<sip:710406702@opensips_public_ip>;tag=41a8c40d
            SIP Display info: "710406702"
            SIP from address: sip:710406702@opensips_public_ip
            SIP tag: 41a8c40d
        Allow: UPDATE,INFO,PRACK,REFER,NOTIFY,INVITE,ACK,OPTIONS,BYE,CANCEL
        Allow-Events: refer
        Call-ID: 27f2a0fb-390a1f2a-5e9e57cd-1ee3a7b0@uac_public_ip
        Max-Forwards: 70
        Contact: <sip:710406702@uac_public_ip:10759>
            Contact Binding: <sip:710406702@uac_public_ip:10759>
                URI: <sip:710406702@uac_public_ip:10759>
                    SIP contact address: sip:710406702@uac_public_ip:10759
        Session-Expires: 1800
        Content-Length: 313
        Content-Type: application/sdp
        Supported: timer,100rel,join,tdialog,replaces,norefersub,histinfo
        CSeq: 57741 INVITE
            Sequence Number: 57741
            Method: INVITE
    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): ipr1B24E8AED4 4453550 4453550
IN IP4 uac_public_ip
                Owner Username: ipr1B24E8AED4
                Session ID: 4453550
                Session Version: 4453550
                Owner Network Type: IN
                Owner Address Type: IP4
                Owner Address: uac_public_ip
            Session Name (s): -
            Connection Information (c): IN IP4 uac_public_ip
                Connection Network Type: IN
                Connection Address Type: IP4
                Connection Address: uac_public_ip
            Time Description, active time (t): 0 0
                Session Start Time: 0
                Session Stop Time: 0
            Media Description, name and address (m): audio 10760 RTP/AVP
0 8 4 18 101
                Media Type: audio
                Media Port: 10760
                Media Proto: RTP/AVP
                Media Format: ITU-T G.711 PCMU
                Media Format: ITU-T G.711 PCMA
                Media Format: ITU-T G.723
                Media Format: ITU-T G.729
                Media Format: 101
            Media Attribute (a): rtpmap:0 PCMU/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 0
                MIME Type: PCMU
            Media Attribute (a): rtpmap:8 PCMA/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 8
                MIME Type: PCMA
            Media Attribute (a): rtpmap:4 G723/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 4
                MIME Type: G723
            Media Attribute (a): rtpmap:18 G729/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 18
                MIME Type: G729
            Media Attribute (a): rtpmap:101 telephone-event/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 101
                MIME Type: telephone-event
            Media Attribute (a): ptime:20
                Media Attribute Fieldname: ptime
                Media Attribute Value: 20
            Media Attribute (a): fmtp:101 0-16
                Media Attribute Fieldname: fmtp
                Media Format: 101 [telephone-event]
                Media format specific parameters: 0-16
            Media Attribute (a): fmtp:4 ptime=30;bitrate=6.3
                Media Attribute Fieldname: fmtp
                Media Format: 4 [telephone-event]
                Media format specific parameters: ptime=30
                Media format specific parameters: bitrate=6.3

I really don't find anything wrong with it but I'm no SIP expert.  Can
some one help me with some pointers.
Thanks for you help.

Regards,

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: no audio from caller when using nathelper

Bogdan-Andrei Iancu
Hi Gabriel,

So you are not using rtpproxy, but rely on the fact that * is all the
time public. In this case, audio from caller to * should work all the
time as the destination is public (of course, if the caller does send
RTP). For the other way around, you can be sure * sends RTP to the
public IP of the NAT (of the client) by doing fix_nated_sdp("1") for the
invite - this will force the COMEDIA support in *.

Anyhow, for RTP nat traversal to work, it is mandatory for the party
behind the nat to start sending RTP (to open the NAT). If the natted
party will send no RTP, there will be no audio at all.

Regard,
Bogdan

Gabriel Bermudez wrote:

> Hi everyone,
>
> I'm using the nathelper and dispatcher module to send calls to an
> Asterisk server.  I'm using the Asterisk as a SIP to H.323 converter
> because our PSTN gateway only speaks H.323
> For some reason *sometimes* the caller does not send RTP traffic to the
> opensips (one way audio).  The caller's UA is behind a NAT, but it
> doesn't gets detected as a nated UA, so the RTP flow is between the
> client's public IP and the Asterisk public IP (rtpproxy is not used).  
> I'm not sure if this problems happens also with UAs that get NAT
> detected (not seen it happen).  I used tshark to capture the invite from
> an undetected NAT UA (changed the UA ip with *uac_public_ip* and
> opensip's ip with *opensips_public_ip*)
>
> Session Initiation Protocol
>     Request-Line: INVITE sip:0059389954277@opensips_public_ip SIP/2.0
>         Method: INVITE
>         [Resent Packet: False]
>     Message Header
>         To: <sip:0059389954277@opensips_public_ip>
>             SIP to address: sip:0059389954277@opensips_public_ip
>         Accept:
> application/dtmf-relay,application/sdp,text/plain,message/sipfrag,application/sip
>         User-Agent: YV1/1.2.0
>         Via: SIP/2.0/UDP uac_public_ip:10759;rport;branch=z9hG4bK474bfa15
>             Transport: UDP
>             Sent-by Address: uac_public_ip
>             Sent-by port: 10759
>             RPort: rport
>             Branch: z9hG4bK474bfa15
>         From: "710406702"<sip:710406702@opensips_public_ip>;tag=41a8c40d
>             SIP Display info: "710406702"
>             SIP from address: sip:710406702@opensips_public_ip
>             SIP tag: 41a8c40d
>         Allow: UPDATE,INFO,PRACK,REFER,NOTIFY,INVITE,ACK,OPTIONS,BYE,CANCEL
>         Allow-Events: refer
>         Call-ID: 27f2a0fb-390a1f2a-5e9e57cd-1ee3a7b0@uac_public_ip
>         Max-Forwards: 70
>         Contact: <sip:710406702@uac_public_ip:10759>
>             Contact Binding: <sip:710406702@uac_public_ip:10759>
>                 URI: <sip:710406702@uac_public_ip:10759>
>                     SIP contact address: sip:710406702@uac_public_ip:10759
>         Session-Expires: 1800
>         Content-Length: 313
>         Content-Type: application/sdp
>         Supported: timer,100rel,join,tdialog,replaces,norefersub,histinfo
>         CSeq: 57741 INVITE
>             Sequence Number: 57741
>             Method: INVITE
>     Message Body
>         Session Description Protocol
>             Session Description Protocol Version (v): 0
>             Owner/Creator, Session Id (o): ipr1B24E8AED4 4453550 4453550
> IN IP4 uac_public_ip
>                 Owner Username: ipr1B24E8AED4
>                 Session ID: 4453550
>                 Session Version: 4453550
>                 Owner Network Type: IN
>                 Owner Address Type: IP4
>                 Owner Address: uac_public_ip
>             Session Name (s): -
>             Connection Information (c): IN IP4 uac_public_ip
>                 Connection Network Type: IN
>                 Connection Address Type: IP4
>                 Connection Address: uac_public_ip
>             Time Description, active time (t): 0 0
>                 Session Start Time: 0
>                 Session Stop Time: 0
>             Media Description, name and address (m): audio 10760 RTP/AVP
> 0 8 4 18 101
>                 Media Type: audio
>                 Media Port: 10760
>                 Media Proto: RTP/AVP
>                 Media Format: ITU-T G.711 PCMU
>                 Media Format: ITU-T G.711 PCMA
>                 Media Format: ITU-T G.723
>                 Media Format: ITU-T G.729
>                 Media Format: 101
>             Media Attribute (a): rtpmap:0 PCMU/8000
>                 Media Attribute Fieldname: rtpmap
>                 Media Format: 0
>                 MIME Type: PCMU
>             Media Attribute (a): rtpmap:8 PCMA/8000
>                 Media Attribute Fieldname: rtpmap
>                 Media Format: 8
>                 MIME Type: PCMA
>             Media Attribute (a): rtpmap:4 G723/8000
>                 Media Attribute Fieldname: rtpmap
>                 Media Format: 4
>                 MIME Type: G723
>             Media Attribute (a): rtpmap:18 G729/8000
>                 Media Attribute Fieldname: rtpmap
>                 Media Format: 18
>                 MIME Type: G729
>             Media Attribute (a): rtpmap:101 telephone-event/8000
>                 Media Attribute Fieldname: rtpmap
>                 Media Format: 101
>                 MIME Type: telephone-event
>             Media Attribute (a): ptime:20
>                 Media Attribute Fieldname: ptime
>                 Media Attribute Value: 20
>             Media Attribute (a): fmtp:101 0-16
>                 Media Attribute Fieldname: fmtp
>                 Media Format: 101 [telephone-event]
>                 Media format specific parameters: 0-16
>             Media Attribute (a): fmtp:4 ptime=30;bitrate=6.3
>                 Media Attribute Fieldname: fmtp
>                 Media Format: 4 [telephone-event]
>                 Media format specific parameters: ptime=30
>                 Media format specific parameters: bitrate=6.3
>
> I really don't find anything wrong with it but I'm no SIP expert.  Can
> some one help me with some pointers.
> Thanks for you help.
>
> Regards,
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: no audio from caller when using nathelper

Gabriel Bermudez
Thanks for your answer Bogdan

Bogdan-Andrei Iancu escribió:
> Hi Gabriel,
>
> So you are not using rtpproxy, but rely on the fact that * is all the
> time public. In this case, audio from caller to * should work all the
> time as the destination is public (of course, if the caller does send
> RTP). For the other way around, you can be sure * sends RTP to the
> public IP of the NAT (of the client) by doing fix_nated_sdp("1") for
> the invite - this will force the COMEDIA support in *.
Yes, some phones set their contact header with the correct public IP
address, that's when rptproxy is not used.  In this case they use *
directly (but using opensips as a proxy).  I do use fix_nated_sdp("1"),
but only when the nat_uac_test("3") gets passed.

        if (nat_uac_test("3")) {
                # Allow RR-ed requests, as these may indicate that
                # a NAT-enabled proxy takes care of it; unless it is
                # a REGISTER

                if (method == "REGISTER" || ! search("^Record-Route:")) {
                    log("LOG: Someone trying to register from private
IP, rewriting\n");

                    # This will work only for user agents that support
symmetric
                    # communication. We tested quite many of them and
majority is
                    # smart enough to be symmetric. In some phones it
takes a configuration
                    # option. With Cisco 7960, it is called
NAT_Enable=Yes, with kphone it is
                    # called "symmetric media" and "symmetric signalling".

                    fix_nated_contact(); # Rewrite contact with source
IP of signalling
                    force_rport(); # Add rport parameter to topmost Via
                    setflag(6);    # Mark as NATed
                };

                if (method == "INVITE") {
                    fix_nated_sdp("1"); # Add direction=active to SDP
                };
        };

>
> Anyhow, for RTP nat traversal to work, it is mandatory for the party
> behind the nat to start sending RTP (to open the NAT). If the natted
> party will send no RTP, there will be no audio at all.
And that's exactly what wasn't happening, *sometimes* (the sometimes was
the one bugging me really).  It seemed not a opensips nat issue but a
asterisk nat issue.  So I setted up asterisk's realtime with the
following view

CREATE OR REPLACE VIEW sipfriends AS
 SELECT subscriber.username AS name, 'friend'::character varying AS
"type", subscriber.username, subscriber."password" AS secret,
'dynamic'::character varying AS host, 'rfc2833'::character varying AS
dtmfmode, 'all'::character varying AS disallow, 'g729'::character
varying AS allow, 'no'::character varying AS canreinvite,
'yes'::character varying AS nat, 'from-ser'::character varying AS
context, ''::character varying AS regserver, 0 AS regseconds
   FROM subscriber;

As you can see, nat=yes always.  Seems that this solved the problem,
I'll do some more testing tomorrow ;)
Thanks for your help.

Regards,

>
> Regard,
> Bogdan
>
> Gabriel Bermudez wrote:
>> Hi everyone,
>>
>> I'm using the nathelper and dispatcher module to send calls to an
>> Asterisk server.  I'm using the Asterisk as a SIP to H.323 converter
>> because our PSTN gateway only speaks H.323
>> For some reason *sometimes* the caller does not send RTP traffic to
>> the opensips (one way audio).  The caller's UA is behind a NAT, but
>> it doesn't gets detected as a nated UA, so the RTP flow is between
>> the client's public IP and the Asterisk public IP (rtpproxy is not
>> used).  I'm not sure if this problems happens also with UAs that get
>> NAT detected (not seen it happen).  I used tshark to capture the
>> invite from an undetected NAT UA (changed the UA ip with
>> *uac_public_ip* and opensip's ip with *opensips_public_ip*)
>>
>> Session Initiation Protocol
>>     Request-Line: INVITE sip:0059389954277@opensips_public_ip SIP/2.0
>>         Method: INVITE
>>         [Resent Packet: False]
>>     Message Header
>>         To: <sip:0059389954277@opensips_public_ip>
>>             SIP to address: sip:0059389954277@opensips_public_ip
>>         Accept:
>> application/dtmf-relay,application/sdp,text/plain,message/sipfrag,application/sip
>>
>>         User-Agent: YV1/1.2.0
>>         Via: SIP/2.0/UDP
>> uac_public_ip:10759;rport;branch=z9hG4bK474bfa15
>>             Transport: UDP
>>             Sent-by Address: uac_public_ip
>>             Sent-by port: 10759
>>             RPort: rport
>>             Branch: z9hG4bK474bfa15
>>         From: "710406702"<sip:710406702@opensips_public_ip>;tag=41a8c40d
>>             SIP Display info: "710406702"
>>             SIP from address: sip:710406702@opensips_public_ip
>>             SIP tag: 41a8c40d
>>         Allow:
>> UPDATE,INFO,PRACK,REFER,NOTIFY,INVITE,ACK,OPTIONS,BYE,CANCEL
>>         Allow-Events: refer
>>         Call-ID: 27f2a0fb-390a1f2a-5e9e57cd-1ee3a7b0@uac_public_ip
>>         Max-Forwards: 70
>>         Contact: <sip:710406702@uac_public_ip:10759>
>>             Contact Binding: <sip:710406702@uac_public_ip:10759>
>>                 URI: <sip:710406702@uac_public_ip:10759>
>>                     SIP contact address:
>> sip:710406702@uac_public_ip:10759
>>         Session-Expires: 1800
>>         Content-Length: 313
>>         Content-Type: application/sdp
>>         Supported:
>> timer,100rel,join,tdialog,replaces,norefersub,histinfo
>>         CSeq: 57741 INVITE
>>             Sequence Number: 57741
>>             Method: INVITE
>>     Message Body
>>         Session Description Protocol
>>             Session Description Protocol Version (v): 0
>>             Owner/Creator, Session Id (o): ipr1B24E8AED4 4453550
>> 4453550 IN IP4 uac_public_ip
>>                 Owner Username: ipr1B24E8AED4
>>                 Session ID: 4453550
>>                 Session Version: 4453550
>>                 Owner Network Type: IN
>>                 Owner Address Type: IP4
>>                 Owner Address: uac_public_ip
>>             Session Name (s): -
>>             Connection Information (c): IN IP4 uac_public_ip
>>                 Connection Network Type: IN
>>                 Connection Address Type: IP4
>>                 Connection Address: uac_public_ip
>>             Time Description, active time (t): 0 0
>>                 Session Start Time: 0
>>                 Session Stop Time: 0
>>             Media Description, name and address (m): audio 10760
>> RTP/AVP 0 8 4 18 101
>>                 Media Type: audio
>>                 Media Port: 10760
>>                 Media Proto: RTP/AVP
>>                 Media Format: ITU-T G.711 PCMU
>>                 Media Format: ITU-T G.711 PCMA
>>                 Media Format: ITU-T G.723
>>                 Media Format: ITU-T G.729
>>                 Media Format: 101
>>             Media Attribute (a): rtpmap:0 PCMU/8000
>>                 Media Attribute Fieldname: rtpmap
>>                 Media Format: 0
>>                 MIME Type: PCMU
>>             Media Attribute (a): rtpmap:8 PCMA/8000
>>                 Media Attribute Fieldname: rtpmap
>>                 Media Format: 8
>>                 MIME Type: PCMA
>>             Media Attribute (a): rtpmap:4 G723/8000
>>                 Media Attribute Fieldname: rtpmap
>>                 Media Format: 4
>>                 MIME Type: G723
>>             Media Attribute (a): rtpmap:18 G729/8000
>>                 Media Attribute Fieldname: rtpmap
>>                 Media Format: 18
>>                 MIME Type: G729
>>             Media Attribute (a): rtpmap:101 telephone-event/8000
>>                 Media Attribute Fieldname: rtpmap
>>                 Media Format: 101
>>                 MIME Type: telephone-event
>>             Media Attribute (a): ptime:20
>>                 Media Attribute Fieldname: ptime
>>                 Media Attribute Value: 20
>>             Media Attribute (a): fmtp:101 0-16
>>                 Media Attribute Fieldname: fmtp
>>                 Media Format: 101 [telephone-event]
>>                 Media format specific parameters: 0-16
>>             Media Attribute (a): fmtp:4 ptime=30;bitrate=6.3
>>                 Media Attribute Fieldname: fmtp
>>                 Media Format: 4 [telephone-event]
>>                 Media format specific parameters: ptime=30
>>                 Media format specific parameters: bitrate=6.3
>>
>> I really don't find anything wrong with it but I'm no SIP expert.  
>> Can some one help me with some pointers.
>> Thanks for you help.
>>
>> Regards,
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>  
>
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: no audio from caller when using nathelper

Bogdan-Andrei Iancu
Hi Gabriel,

Gabriel Bermudez wrote:

> Thanks for your answer Bogdan
>
> Bogdan-Andrei Iancu escribió:
>> Hi Gabriel,
>>
>> So you are not using rtpproxy, but rely on the fact that * is all the
>> time public. In this case, audio from caller to * should work all the
>> time as the destination is public (of course, if the caller does send
>> RTP). For the other way around, you can be sure * sends RTP to the
>> public IP of the NAT (of the client) by doing fix_nated_sdp("1") for
>> the invite - this will force the COMEDIA support in *.
> Yes, some phones set their contact header with the correct public IP
> address, that's when rptproxy is not used.  In this case they use *
> directly (but using opensips as a proxy).  I do use
> fix_nated_sdp("1"), but only when the nat_uac_test("3") gets passed.
maybe the test "3" is not enough to detect all the NAT cases....try to
use more tests to see if makes a difference.

>
>>
>> Anyhow, for RTP nat traversal to work, it is mandatory for the party
>> behind the nat to start sending RTP (to open the NAT). If the natted
>> party will send no RTP, there will be no audio at all.
> And that's exactly what wasn't happening, *sometimes* (the sometimes
> was the one bugging me really).  It seemed not a opensips nat issue
> but a asterisk nat issue.  So I setted up asterisk's realtime with the
> following view
>
> CREATE OR REPLACE VIEW sipfriends AS
> SELECT subscriber.username AS name, 'friend'::character varying AS
> "type", subscriber.username, subscriber."password" AS secret,
> 'dynamic'::character varying AS host, 'rfc2833'::character varying AS
> dtmfmode, 'all'::character varying AS disallow, 'g729'::character
> varying AS allow, 'no'::character varying AS canreinvite,
> 'yes'::character varying AS nat, 'from-ser'::character varying AS
> context, ''::character varying AS regserver, 0 AS regseconds
>   FROM subscriber;
>
> As you can see, nat=yes always.  Seems that this solved the problem,
> I'll do some more testing tomorrow ;)

Cool :)

Regards,
Bogdan

> Thanks for your help.
>
> Regards,
>
>>
>> Regard,
>> Bogdan
>>
>> Gabriel Bermudez wrote:
>>> Hi everyone,
>>>
>>> I'm using the nathelper and dispatcher module to send calls to an
>>> Asterisk server.  I'm using the Asterisk as a SIP to H.323 converter
>>> because our PSTN gateway only speaks H.323
>>> For some reason *sometimes* the caller does not send RTP traffic to
>>> the opensips (one way audio).  The caller's UA is behind a NAT, but
>>> it doesn't gets detected as a nated UA, so the RTP flow is between
>>> the client's public IP and the Asterisk public IP (rtpproxy is not
>>> used).  I'm not sure if this problems happens also with UAs that get
>>> NAT detected (not seen it happen).  I used tshark to capture the
>>> invite from an undetected NAT UA (changed the UA ip with
>>> *uac_public_ip* and opensip's ip with *opensips_public_ip*)


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users