[ previous ] [ next ] [ threads ]
 To :  Paul Chitescu <paulc@v...>
 From :  Marc Dirix <marc@e...>
 Subject :  Re: [yate] routing with database
 Date :  Thu, 3 Jan 2008 22:18:21 +0100
Hi Paul,

Thanks for your info. I already read the article, I was actually under  
the impression
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  
doesn't it?


Best regards,

Marc



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:
>> Hi,
>>
>> Yate-1.3
>>
>> I'm still having the same problem.
>>
>> I don't use STUN, because I understood it is not necessary for NAT- 
>> Traversal.
>>
>> 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,
>>
>> Marc
>>
>> 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  
>>> functions.
>>> - 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.
>>> Paul
>>> On Mon, 10 Dec 2007, Marc Dirix wrote:
>>>> Hi,
>>>> If rtp_forward='possible' is set, should I always set this to
>>>> rtp_forward='yes'? If not, why, when not?
>>>> Marc