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