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

[Julian Yap]

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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>