Unfortunately, up to version 0.9.6 SER
doesn't know if the public client
supports symmetric RTP and active/passive direction attribute. So SER
will make sure that both clients can hear each other (both way RTP
stream between clients) and involves RTP proxy. On the other hand,
clients behind NAT has to support symmetric RTP because they would
not work behind NAT.
So you have two options:
1) Not use rtpproxy at all in your ser.cfg and then you have to now that
your clients support symmetric RTP
But if you have two clients behind then it would not work.
2) Use RTPproxy even if one client is behind NAT.. This will work with
all scenarios.
Ladislav
O. wrote:
thanks, so we have to keep the proxy.
In this case when one of the client will be behind nat does the proxy
will transfer the RTP? or still the the RTP will be route without proxy
involved?
Thanks,
O.
On Sat, 2006-05-06 at 23:57 +0200, Ladislav Andel wrote:
Hi O.,
This will work only with one NAT involved in SIP dialog. If you have
both clients behind NAT then RTPproxy or Mediaproxy is necessary. Also,
your clients has to support active/passive direction attribute and be
able to read source IP:port address from the first RTP packet received.
Regards,
Ladislav
O. wrote:
> Hi Kostas and samuel,
>
> In the case you are describing, using nathelper will replace the
> rtpproxy or medianproxy? It looks to me that in this case the rtp will
> be route in between the sip client, without any proxy. In the
> configuration you mentioned the ser is on public IP?
> if this is the case it looks much better the proxy from the load
> prospective.
>
> thanks,
> O.
>
>
>
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org