One way audio with AudioCodes Mediant 2000 and NAT

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

One way audio with AudioCodes Mediant 2000 and NAT

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

Private info changed in Pastebin's :).

Any help appreciated!

- Julian

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

Iñaki Baz Castillo
2009/2/10 Julian Yap <[hidden email]>:

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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

Julian Yap
On Feb 9, 2009 10:54pm, Iñaki Baz Castillo <[hidden email]> 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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

Iñaki Baz Castillo
2009/2/10  <[hidden email]>:
>> 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
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

Olle E. Johansson

10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo:

> 2009/2/10  <[hidden email]>:
>>> 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
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

Iñaki Baz Castillo
2009/2/10 Johansson Olle E <[hidden email]>:

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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

Olle E. Johansson

10 feb 2009 kl. 13.10 skrev Iñaki Baz Castillo:

> 2009/2/10 Johansson Olle E <[hidden email]>:
>
>> 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
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

Iñaki Baz Castillo
2009/2/10 Johansson Olle E <[hidden email]>:

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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

Olle E. Johansson

10 feb 2009 kl. 13.44 skrev Iñaki Baz Castillo:

> 2009/2/10 Johansson Olle E <[hidden email]>:
>
>>> 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



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

Iñaki Baz Castillo
2009/2/10 Johansson Olle E <[hidden email]>:
>> 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
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

Bogdan-Andrei Iancu
In reply to this post by Olle E. Johansson
Hi Olle,

Johansson Olle E wrote:

>
> 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo:
>
>> 2009/2/10  <[hidden email]>:
>>>> 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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

Julian Yap
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 <[hidden email]> wrote:

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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

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


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

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


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

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


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: One way audio with AudioCodes Mediant 2000 and NAT

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


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users