thanks for the clarification. it looks like SER0.9.6 is step ahead or we have to deal with the extra traffic.
thanks, O.
On Mon, 2006-05-08 at 10:45 +0200, Ladislav Andel wrote:
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:
- 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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers