[OpenSIPS-Users] no audio from caller when using nathelper

Gabriel Bermudez elgabo81 at gmail.com
Wed Apr 8 01:19:26 CEST 2009


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 at opensips_public_ip SIP/2.0
>>         Method: INVITE
>>         [Resent Packet: False]
>>     Message Header
>>         To: <sip:0059389954277 at opensips_public_ip>
>>             SIP to address: sip:0059389954277 at 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 at opensips_public_ip>;tag=41a8c40d
>>             SIP Display info: "710406702"
>>             SIP from address: sip:710406702 at 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 at uac_public_ip
>>         Max-Forwards: 70
>>         Contact: <sip:710406702 at uac_public_ip:10759>
>>             Contact Binding: <sip:710406702 at uac_public_ip:10759>
>>                 URI: <sip:710406702 at uac_public_ip:10759>
>>                     SIP contact address: 
>> sip:710406702 at 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
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>   
>
>



More information about the Users mailing list