[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