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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>> >>>> >>>>> >>>>> Hi Olle, >>>>> >>>>> Johansson Olle E wrote: >>>>> >>>>> >>>>>> >>>>>> 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo: >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> 2009/2/10 <[email protected]>: >>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> 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 >>>>> [email protected] >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
