[OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
Hi All, I was looking to get some assistance with debugging an issue with an AudioCodes Mediant 2000 and OpenSIPS 1.4.4. I think it's a simple config issue. Basically, I'm getting one way audio :( Not sure if I need to be running RTPProxy to make this all work for me. The basic flow is: UA --> OpenSIPS --> AudioCodes G/W --> PSTN Here's a Pastebin of my OpenSIPS config: http://pastebin.com/m41d16a22 Here's a Pastebin of an Ngrep trace on the OpenSIPS server: http://pastebin.com/m7944a8d8 Private info changed in Pastebin's :). Any help appreciated! - Julian ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
2009/2/10 Julian Yap : > Hi All, > > I was looking to get some assistance with debugging an issue with an > AudioCodes Mediant 2000 and OpenSIPS 1.4.4. I think it's a simple > config issue. > > Basically, I'm getting one way audio :( > > Not sure if I need to be running RTPProxy to make this all work for me. > > The basic flow is: > UA --> OpenSIPS --> AudioCodes G/W --> PSTN > > Here's a Pastebin of my OpenSIPS config: > http://pastebin.com/m41d16a22 > > Here's a Pastebin of an Ngrep trace on the OpenSIPS server: > http://pastebin.com/m7944a8d8 Hi, I'm sorry but I expect nobody will inspect your config and traces in order to discover your network topology (you have told us nothing about NAT and so...). 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. > Basically, I'm getting one way audio :( Inspect, by yourself, the SDP arriving to the UAS in INVITE and the SDP arrives to the UAC in the 200 OK. Do they contain a media address reachable from each UA? -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
On Feb 9, 2009 10:54pm, Iñaki Baz Castillo wrote: Hi, I'm sorry but I expect nobody will inspect your config and traces in order to discover your network topology (you have told us nothing about NAT and so...). 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. > Basically, I'm getting one way audio :( Inspect, by yourself, the SDP arriving to the UAS in INVITE and the SDP arrives to the UAC in the 200 OK. Do they contain a media address reachable from each UA? I'll check this out. Thanks, Julian ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
2009/2/10 : >> 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. >> > Basically, I'm getting one way audio :( >> >> >> Inspect, by yourself, the SDP arriving to the UAS in INVITE and the >> SDP arrives to the UAC in the 200 OK. Do they contain a media address >> reachable from each UA? > > I'll check this out. It's really easy: a) In the caller check the media address in the 200 OK SDP. Can you ping that IP from the caller? b) In the callee check the media address in the INVITE SDP. Can you ping that IP from the callee? If a) or b) are "no", then you get one-way-audio. If both are "no", then you get no audio at all. -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo: 2009/2/10 : 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 /O smime.p7s Description: S/MIME cryptographic signature ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
2009/2/10 Johansson Olle E : > 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. Hi, I don't fully agree on it: alice --- (NAT A) --- ProxyA & RtpProxyA --- ProxyB & RtpProxyB --- (NAT B) --- bob In this case, when alice calls bob, ProxyA will apply RtpProxyA so the SDP will contain a public IP. Since ProxyB knows that bob is registered behind NAT, it will try to apply RtpProxyB but this will "fail" because the incoming SDP contains a line: a=nortpproxy:yes This line was added by ProxyA when applying RtpProxyA. When ProxyB executes "force_rtpproxy()" this function will not modify the SDP since that line is present. If not, there will be no audio because RtpProxyA would be waiting for audio from RtpProxyB and vice versa (lock condition). ProxyB must be well configured, this means that since "force_rtpproxy()" didn't success on the incoming INVITE, it must no execute "force_rtpproxy()" on the 18X/2XX response from bob. For this, I use a bflag(RTPPROXY_SET) which only set to 1 if "force_rtpproxy()" succeded in the incoming INVITE, and only run "force_rtpproxy()" for responses from bob if that bflag is on. "force_rtpproxy()" returns TRUE (1) just in case the SDP was modified. Best regards. -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
10 feb 2009 kl. 13.10 skrev Iñaki Baz Castillo: 2009/2/10 Johansson Olle E : 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. Hi, I don't fully agree on it: alice --- (NAT A) --- ProxyA & RtpProxyA --- ProxyB & RtpProxyB --- (NAT B) --- bob In this case, when alice calls bob, ProxyA will apply RtpProxyA so the SDP will contain a public IP. Since ProxyB knows that bob is registered behind NAT, it will try to apply RtpProxyB but this will "fail" because the incoming SDP contains a line: a=nortpproxy:yes This line was added by ProxyA when applying RtpProxyA. When ProxyB executes "force_rtpproxy()" this function will not modify the SDP since that line is present. If not, there will be no audio because RtpProxyA would be waiting for audio from RtpProxyB and vice versa (lock condition). On the INVITE there's no need for ProxyB to allocate an rtpproxy, since the SDP already has public IP - fixed by Proxy A. ProxyB must be well configured, this means that since "force_rtpproxy()" didn't success on the incoming INVITE, it must no execute "force_rtpproxy()" on the 18X/2XX response from bob. For this, I use a bflag(RTPPROXY_SET) which only set to 1 if "force_rtpproxy()" succeded in the incoming INVITE, and only run "force_rtpproxy()" for responses from bob if that bflag is on. It should force RTPproxy on teh response from Bob, since Bob is a local user and the SDP includes a private IP. "force_rtpproxy()" returns TRUE (1) just in case the SDP was modified. Yes. /O smime.p7s Description: S/MIME cryptographic signature ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
2009/2/10 Johansson Olle E : >> alice --- (NAT A) --- ProxyA & RtpProxyA --- ProxyB & RtpProxyB --- >> (NAT B) --- bob >> >> In this case, when alice calls bob, ProxyA will apply RtpProxyA so the >> SDP will contain a public IP. >> Since ProxyB knows that bob is registered behind NAT, it will try to >> apply RtpProxyB but this will "fail" because the incoming SDP contains >> a line: >> a=nortpproxy:yes >> This line was added by ProxyA when applying RtpProxyA. >> When ProxyB executes "force_rtpproxy()" this function will not modify >> the SDP since that line is present. If not, there will be no audio >> because RtpProxyA would be waiting for audio from RtpProxyB and vice >> versa (lock condition). > > On the INVITE there's no need for ProxyB to allocate an rtpproxy, since > the SDP already has public IP - fixed by Proxy A. No, that's not an excuse. RtpProxy must be applied in both the request and response. If a PSTN gateway calls a SIP user behind NAT, you must apply RtpProxy even if the incoming SDP has public address. >> >> >> ProxyB must be well configured, this means that since >> "force_rtpproxy()" didn't success on the incoming INVITE, it must no >> execute "force_rtpproxy()" on the 18X/2XX response from bob. For this, >> I use a bflag(RTPPROXY_SET) which only set to 1 if "force_rtpproxy()" >> succeded in the incoming INVITE, and only run "force_rtpproxy()" for >> responses from bob if that bflag is on. > > It should force RTPproxy on teh response from Bob, since Bob is > a local user and the SDP includes a private IP. Not again, please re-read my explanation above :) In the example of a PSTN gateway calling a natted SIP user, if the proxy only applies RtpProxy in the user response then you will get asymmetric audio: user (NAT)RtpProxy Gateway --(RTP)---> <-(RTP)-- <-(RTP)-- So the RTP from the gateway will not arrive to the user since the NAT router will not allow it (there is not an existing UDP mapping to allow UDP traffic from the RtpProxy, but just from the Gateway address). So RtpProxy must be present in the request and response, then the NAT router mapping will work and allow incoming data from RtpProxy after the user sends RTP data to the RtpProxy. Am I wrong? -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
10 feb 2009 kl. 13.44 skrev Iñaki Baz Castillo: 2009/2/10 Johansson Olle E : alice --- (NAT A) --- ProxyA & RtpProxyA --- ProxyB & RtpProxyB --- (NAT B) --- bob In this case, when alice calls bob, ProxyA will apply RtpProxyA so the SDP will contain a public IP. Since ProxyB knows that bob is registered behind NAT, it will try to apply RtpProxyB but this will "fail" because the incoming SDP contains a line: a=nortpproxy:yes This line was added by ProxyA when applying RtpProxyA. When ProxyB executes "force_rtpproxy()" this function will not modify the SDP since that line is present. If not, there will be no audio because RtpProxyA would be waiting for audio from RtpProxyB and vice versa (lock condition). On the INVITE there's no need for ProxyB to allocate an rtpproxy, since the SDP already has public IP - fixed by Proxy A. No, that's not an excuse. RtpProxy must be applied in both the request and response. If a PSTN gateway calls a SIP user behind NAT, you must apply RtpProxy even if the incoming SDP has public address. Not in the INVITE sdp - the device behind the NAT can always send to a public IP address, right? ProxyB must be well configured, this means that since "force_rtpproxy()" didn't success on the incoming INVITE, it must no execute "force_rtpproxy()" on the 18X/2XX response from bob. For this, I use a bflag(RTPPROXY_SET) which only set to 1 if "force_rtpproxy()" succeded in the incoming INVITE, and only run "force_rtpproxy()" for responses from bob if that bflag is on. It should force RTPproxy on teh response from Bob, since Bob is a local user and the SDP includes a private IP. Not again, please re-read my explanation above :) In the example of a PSTN gateway calling a natted SIP user, if the proxy only applies RtpProxy in the user response then you will get asymmetric audio: user (NAT)RtpProxy Gateway --(RTP)---> <-(RTP)-- <-(RTP)-- So the RTP from the gateway will not arrive to the user since the NAT router will not allow it (there is not an existing UDP mapping to allow UDP traffic from the RtpProxy, but just from the Gateway address). The gateway will (in teh case of Asterisk) listen to the audio coming from the user and change to the port and IP we're receiving audio from. That way, we'll have symmetric audio and will bypass the NAT. So RtpProxy must be present in the request and response, then the NAT router mapping will work and allow incoming data from RtpProxy after the user sends RTP data to the RtpProxy. Am I wrong? We are mixing cases here. One case is a gateway scenario, where the RTP proxy isn't really needed, since the gateway may take care of it by itself, provided that the gateway is on a public IP. If you have two users both behind NAT, each user applies an RTP proxy to the incoming audio stream, not the outbound stream. /O smime.p7s Description: S/MIME cryptographic signature ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
2009/2/10 Johansson Olle E : >> No, that's not an excuse. RtpProxy must be applied in both the request >> and response. >> If a PSTN gateway calls a SIP user behind NAT, you must apply RtpProxy >> even if the incoming SDP has public address. > > Not in the INVITE sdp - the device behind the NAT can always send > to a public IP address, right? Yes, but it will not receive it if the incoming RTP comes from a different address (the RtpProxy). The NAT router will not allow that incoming traffic since there hasn't been a NAT mapping before (the client doesn't send its RTP to RtpProxy but to the gateway). >> user (NAT)RtpProxy Gateway >> >> --(RTP)---> >> >> <-(RTP)-- >> <-(RTP)-- >> >> So the RTP from the gateway will not arrive to the user since the NAT >> router will not allow it (there is not an existing UDP mapping to >> allow UDP traffic from the RtpProxy, but just from the Gateway >> address). > > The gateway will (in teh case of Asterisk) listen to the audio > coming from the user and change to the port and > IP we're receiving audio from. That way, we'll have symmetric > audio and will bypass the NAT. Ahhh, but that's Comedia mode (available in Asterisk, SEMS, some Cisco gateways...) I already mention decives supporting Comedia mode in my first mail to this thread :) >> So RtpProxy must be present in the request and response, then the NAT >> router mapping will work and allow incoming data from RtpProxy after >> the user sends RTP data to the RtpProxy. >> >> >> Am I wrong? > > We are mixing cases here. One case is a gateway scenario, where > the RTP proxy isn't really needed, since the gateway may take > care of it by itself, provided that the gateway is on a public IP. > > If you have two users both behind NAT, each user applies > an RTP proxy to the incoming audio stream, not the outbound > stream. In this point I don't agree again. What you suggest it: alice --- (NAT A) --- ProxyA & RtpProxyA --- ProxyB & RtpProxyB --- (NAT B) --- bob So: - alice calls bob. ProxyA applies RtpProxyA to the INVITE. - ProxyB receives the INVITE and doesn't apply RtpProxyB since address in SDP is public (set by ProxyA). - bob replies 200 OK. - ProxyB applies RtpProxyB to the response. - The reply arrives to ProxyA which doesn't apply RtpProxyA since the SDP address is public (set by ProxyB). So we get the following RTP flow (please use fixed size fonts): alice (NAT A) RtpProxyA RtpProxyB(NAT B) bob > ---> <-- <- - RTP from alice will not arrive to bob since it will be rejected by NAT B router (no existing mapping). - RTP from bob will not arrive to alice since it will be rejected by NAT A router (no existing mapping). - No audio at all. -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
Hi Olle, Johansson Olle E wrote: > > 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo: > >> 2009/2/10 : 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 efficientTheoretically, 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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
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 wrote: > Hi Olle, > > Johansson Olle E wrote: >> >> 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo: >> >>> 2009/2/10 : > 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 efficientTheoretically, 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@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
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 wrote:
>
>> Hi Olle,
>>
>> Johansson Olle E wrote:
>>
>>> 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo:
>>>
>>>
2009/2/10 :
>> 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 efficientTheoretically, 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@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
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 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 wrote:
>>
>>> Hi Olle,
>>>
>>> Johansson Olle E wrote:
>>>
10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo:
> 2009/2/10 :
>
>>> 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 efficientTheoretically, 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@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
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 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 wrote:
>>>
>>>
Hi Olle,
Johansson Olle E wrote:
> 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo:
>
>
>
>> 2009/2/10 :
>>
>>
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 efficientTheoretically, 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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
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
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 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 wrote:
>
> Hi Olle,
>
> Johansson Olle E wrote:
>
>
>>
>> 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo:
>>
>>
>>
>>>
>>> 2009/2/10 :
>>>
>>>
>
> 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 efficientTheoretically, 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@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>>>
>>>
>>
>>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
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
> 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 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 wrote:
>
>
>
>> Hi Olle,
>>
>> Johansson Olle E wrote:
>>
>>
>>
>>> 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo:
>>>
>>>
>>>
>>>
2009/2/10 :
>> 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 efficientTheoretically, 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@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>
>>>
>>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
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
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
>> 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 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 wrote:
>>
>>
>>
>>>
>>> Hi Olle,
>>>
>>> Johansson Olle E wrote:
>>>
>>>
>>>
10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo:
>
> 2009/2/10 :
>
>
>
>>>
>>> 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 I
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
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
> 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
>>> 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 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 wrote:
>>>
>>>
>>>
>>>
Hi Olle,
Johansson Olle E wrote:
> 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo:
>
>
>
>
>
>> 2009/2/10 :
>>
>>
>>
>>
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.
>>
>>
>>
>>
