[ previous ] [ next ] [ threads ]
 To :  Paul Chitescu <paulc@v...>
 From :  Marc Dirix <marc@e...>
 Subject :  Re: [yate] routing with database
 Date :  Thu, 3 Jan 2008 16:05:45 +0100
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