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 > <[email protected]> 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 >>> <[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
