[OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Tue Feb 17 13:41:43 CET 2009
Julian,
Can you post a trace of the entire call (INVITE + re-INVITe) ?
Regards,
Bogdan
Julian Yap wrote:
> In an example scenario, the re-INVITE is handled by the end device.
>
> So:
> PSTN Fax --> GW --> OpenSIPS --> UA (ATA attached to Fax machine)
>
> UA answers the call and then sends the re-INVITE which is correct as
> that is the terminating side.
>
> I read this RFC
> http://tools.ietf.org/html/draft-mule-sip-t38callflows-02 which was
> quite handy. :P
>
> The re-INVITE get accepted and RTP communication starts... However,
> for some reason, the T.38 part fails. In theory it should work but
> doesn't for me. Perhaps it's something wrong with my config at the
> time and the handling of the re-INVITE and NAT. Or perhaps it was
> some obscure issue with the GW and T.38 communications and timing,
> etc... Eventually I re-implemented it all with RTPProxy and that
> worked for me first time, inbound and outbound.
>
> Perhaps if someone has a clean working config with re-INVITE without
> using RTPProxy or MediaProxy, I can try that. Seems like all the
> example configs out there are used with a RTP proxy.
>
> - Julian
>
> On Mon, Feb 16, 2009 at 1:04 PM, Bogdan-Andrei Iancu
> <bogdan at voice-system.ro> wrote:
>
>> Hi Julian,
>>
>> You can still handle the NAT wih COMEDIA even for T.38, but you have to
>> handle the re-INVITE also . In your scenario, who is generating the
>> re-INVITE?
>>
>> Regards,
>> Bogdan
>>
>> Julian Yap wrote:
>>
>>> The full story is that I was looking to get T.38 working behind NAT.
>>>
>>> Unfortunately, no matter what I tried, it wouldn't work behind NAT. I
>>> had the initial INVITE (G.711) working fine but when there was the
>>> T.38 re-INVITE, the RTP media would connect up fine but just wouldn't
>>> negotiate properly with T.38. Very strange as it worked fine with the
>>> UA behind a public IP.
>>>
>>> In the end, I implemented RTPProxy and T.38 works fine behind NAT.
>>>
>>> - Julian
>>>
>>> On Sun, Feb 15, 2009 at 1:25 AM, Bogdan-Andrei Iancu
>>> <bogdan at voice-system.ro> wrote:
>>>
>>>
>>>> Hi Julian,
>>>>
>>>> That is cool - in this way you save a lot of bandwidth and processing
>>>> power
>>>> with media relaying.
>>>>
>>>> Regards,
>>>> Bogdan
>>>>
>>>> Julian Yap wrote:
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> I eventually played around with the Audiocodes box and enabled some
>>>>> settings so it worked with Comedia support.
>>>>>
>>>>> Thanks,
>>>>> Julian
>>>>>
>>>>>
>>>>> On 2/10/09, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> HI Julian,
>>>>>>
>>>>>> If it has, you can actually force it by adding "direction=active" into
>>>>>> SDP as indication. See "fix_nated_sdp("1") :
>>>>>>
>>>>>>
>>>>>> http://www.opensips.org/html/docs/modules/1.4.x/nathelper.html#id270439
>>>>>>
>>>>>> Regards,
>>>>>> Bogdan
>>>>>>
>>>>>> Julian Yap wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks all. I'll check to see if the AudioCodes gateway does have
>>>>>>> comedia support.
>>>>>>>
>>>>>>> That clarifies some half baked NAT/RTP knowledge in my head.
>>>>>>>
>>>>>>> - Julian
>>>>>>>
>>>>>>>
>>>>>>> On 2/10/09, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Olle,
>>>>>>>>
>>>>>>>> Johansson Olle E wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 2009/2/10 <julianokyap at gmail.com>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> You don't know if RtpProxy should be running, does it mean you
>>>>>>>>>>>> are
>>>>>>>>>>>> trying to use it or not? I don't want to spend time inspecting
>>>>>>>>>>>> what
>>>>>>>>>>>> you want to do by reading your config, sorry.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Yeah, I'm trying not to run RTPProxy. After more testing, I'm
>>>>>>>>>>> thinking I may
>>>>>>>>>>> need to.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> You cannot decide if you need RtpProxy or not based on testing,
>>>>>>>>>> it's
>>>>>>>>>> pure theory:
>>>>>>>>>>
>>>>>>>>>> A RTP proxy is NOT needed when (assuming the proxy has in the
>>>>>>>>>> public
>>>>>>>>>> internet):
>>>>>>>>>>
>>>>>>>>>> - Both caller and callee have public IP or use STUN.
>>>>>>>>>> - Both caller and callee are in the *SAME* private LAN.
>>>>>>>>>> - The caller is in a private LAN and the callee has public IP and
>>>>>>>>>> supports Comedia mode (typical in some media servers and gateways).
>>>>>>>>>> - The callee is in a private LAN and the caller has public IP and
>>>>>>>>>> supports Comedia mode.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> A RTP proxy is needed when:
>>>>>>>>>>
>>>>>>>>>> - Caller is in private LAN (with no STUN) and callee in public
>>>>>>>>>> internet (and not supporting Comedia).
>>>>>>>>>> - Caller and callee are in different private LAN's with no STUN.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I would like to add that it's the device that can't receive audio
>>>>>>>>> that
>>>>>>>>> needs the RTP proxy to get incoming audio.
>>>>>>>>>
>>>>>>>>> If both devices are on private IP's, there's going to be two
>>>>>>>>> RTP proxys involved if they're on different SIP networks.
>>>>>>>>>
>>>>>>>>> Each SIP service needs an RTP proxy for supporting their
>>>>>>>>> local users.
>>>>>>>>>
>>>>>>>>> To simplify:
>>>>>>>>>
>>>>>>>>> - If my user is on a private IP and sends an INVITE, add RTP proxy
>>>>>>>>> handling to the INVITE
>>>>>>>>>
>>>>>>>>> - If my user receives a call and sends a 200 OK, add RTP proxy
>>>>>>>>> handling to the 200 OK
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> This logic is simple but not efficient....Theoretically, if a call
>>>>>>>> has
>>>>>>>> already a leg in public net, there is not need for a media relay for
>>>>>>>> traversing the nat.
>>>>>>>>
>>>>>>>> The only requirement is that all the devices to support symmetric
>>>>>>>> media
>>>>>>>> (comedia support).
>>>>>>>>
>>>>>>>> So, after the caller proxy forced RTPproxy, the callee should not do
>>>>>>>> the
>>>>>>>> same because the SDP already have a public IP, the nat traversal
>>>>>>>> works
>>>>>>>> even if the callee is behind a nat.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Bogdan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list
>>>>>>>> Users at lists.opensips.org
>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
More information about the Users
mailing list