[OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT

Julian Yap julianokyap at gmail.com
Mon Feb 16 00:15:24 CET 2009


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