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