Thanks for your info. I already read the article, I was actually under
Yate did test for this, and not set rtp_forward='possible' if a call
is between 2 clients having one natted.
This however renders the "rtp_forward='possible'" variable useless or
On 03 Jan 2008, at 18:50, Paul Chitescu wrote:
> Hello, Marc!
> Besides the IP address modification made by Yate if it guesses the
> caller is behind a NAT there should be support for NAT traversal at
> least from the client with the public IP.
> Since Yate does not get the RTP it cannot assist any further. If the
> NAT does port translation the _other_ side has to compensate for it
> and make the RTP symmetrical (SIP doesn't support declaring
> asymmetrical RTP addresses anyway).
> Your (2) is supposed to detect the RTP is coming from the wrong port
> (and eventually address) and change its own transmission to match.
> Otherwise (2) will receive from (1) but will send to the SDP
> declared port which is invalid because of translation.
> Please see: http://freshmeat.net/articles/view/2079/
> When acting as RTP endpoint Yate does this change by default on the
> first good looking packet arriving on the proper port. You'll see in
> logs some:
> Auto changing RTP address from ... to ...
> So that's why we recommend to proxy the RTP through the server - you
> can't rely on the client to do it right. From a database it should
> be possible to allow RTP forwarding on a per-call basis looking at
> the user agent of the caller and the one registered for the called
> party. Explicitely whitelisting known good user agents should be
> pretty safe.
> Paul Chitescu
> On Thu, 3 Jan 2008, Marc Dirix wrote:
>> I'm still having the same problem.
>> I don't use STUN, because I understood it is not necessary for NAT-
>> The main problem is:
>> 1 yate server. 2 SIP clients, of which (1) natted, (2) publicly.
>> Both clients are registerd.
>> Client 1 calls client 2 :
>> The yate server gets: rtp_forward='possible' during routing, which
>> I set to rtp_forward='yes'
>> Client 1 gets NO audio, client 2 does.
>> How is this possible?
>> What further testing can I do?
>> If I set rtp_forward='no' during routing I also get proxy behaviour
>> for 2 clients both having public IP's?
>> Thanks Again,
>> On 10 Dec 2007, at 21:24, Paul Chitescu wrote:
>>> Hi, Marc
>>> There are good reasons to proxy the RTP through Yate sometimes.
>>> - You can control the audio, insert messages, beeps, do recording
>>> and conferencing.
>>> - You get RFC 2833 events and/or inband DTMF, can implement PBX
>>> - Having a public IP for the media stream fixes most NAT issues
>>> (with server's assistance).
>>> - The identities of the parties can be held private to each other.
>>> On the other hand, sending the RTP directly between parties:
>>> - Saves bandwidth to the server and CPU usage.
>>> - Reduces latency a little.
>>> - Allows using codecs that Yate may not handle correctly,
>>> including video.
>>> By far NATed clients are the main reason to retain RTP through the
>>> server. Despite the best effort with ICE and STUN there are cases
>>> when voice just doesn't get through because both parts are behind
>>> crowded symmetrical NATs.
>>> On Mon, 10 Dec 2007, Marc Dirix wrote:
>>>> If rtp_forward='possible' is set, should I always set this to
>>>> rtp_forward='yes'? If not, why, when not?