Hi,
I have a couple questions for rtpproxy/nathelper:
(1) Can rtpproxy/nathelper support calls with multiple media sessions (e.g. video conversation between WMs)? (2) Is there any plan for adding the support for non-symmetric RTP UAs like Siemens SCS client in the near future?
Thanks, Kevin
--------------------------------------------------------------- Date: Wed, 07 Jan 2004 19:19:32 +0200 From: Maxim Sobolev sobomax@portaone.com Subject: [Serusers] New versions of RTP proxy/nathelper commited To: serusers@lists.iptel.org Message-ID: 3FFC3FA4.6040800@portaone.com Content-Type: text/plain; charset=us-ascii; format=flowed
Hi,
I've just committed major update for rtpproxy/nathelper, which adds support for proxying RTCP and also make RTP proxy behave much better for non-NATed clients by pre-loading remote addresses[1] of each party from the SIP request/reply. Please note that proxy's command protocol has been extended to support new functionality, so that you need both new rtp proxy and new nathelper (old nathelper will not work with new rtp proxy and vice versa). Both of them can be obtained from the ser's cvs repository:
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/ http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/nathelper/
Please let me know if there are any problems with the new version.
-Maxim [1] currently only IPv4 addresses can be pre-loaded, though it should be trivial to extend proxy, nathelper and command protocol to accomodate IPv6 as well. Proxy's core supports IPv4<->IPv4, IPv4<->IPv6 and IPv6<->IPv6 relaying already both for RTP and RTCP.
Kevin Chu wrote:
Hi,
I have a couple questions for rtpproxy/nathelper:
(1) Can rtpproxy/nathelper support calls with multiple media sessions (e.g. video conversation between WMs)?
Theoretically yes, but volunteer needed to code this functionality in and test it.
(2) Is there any plan for adding the support for non-symmetric RTP UAs like Siemens SCS client in the near future?
Yes, I already have this support in my local development tree and plan to merge it into public version of RTP proxy/nathelper in the next few days. Please note, however, that RTP proxy will not do any NAT traversal for such UAs, they should be either located on public IP or use some other technology to overcome NAT (e.g. STUN, UPnP, manual configuration of ports forwarding on NAT box etc). Nevertheless this support is useful when at least one of two parties is RTP symmetric (e.g. call from RTP-symmetric UA from behind a NAT to non-RTP-symmetric UA on public address). Please also note that there is no other way to detect non-RTP-symmetric UA than to compare User-Agent/Server header field against list of known non-RTP-symmetric UAs.
-Maxim
Thanks, Kevin
Date: Wed, 07 Jan 2004 19:19:32 +0200 From: Maxim Sobolev sobomax@portaone.com Subject: [Serusers] New versions of RTP proxy/nathelper commited To: serusers@lists.iptel.org Message-ID: 3FFC3FA4.6040800@portaone.com Content-Type: text/plain; charset=us-ascii; format=flowed
Hi,
I've just committed major update for rtpproxy/nathelper, which adds support for proxying RTCP and also make RTP proxy behave much better for non-NATed clients by pre-loading remote addresses[1] of each party from the SIP request/reply. Please note that proxy's command protocol has been extended to support new functionality, so that you need both new rtp proxy and new nathelper (old nathelper will not work with new rtp proxy and vice versa). Both of them can be obtained from the ser's cvs repository:
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/ http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/nathelper/
Please let me know if there are any problems with the new version.
-Maxim [1] currently only IPv4 addresses can be pre-loaded, though it should be trivial to extend proxy, nathelper and command protocol to accomodate IPv6 as well. Proxy's core supports IPv4<->IPv4, IPv4<->IPv6 and IPv6<->IPv6 relaying already both for RTP and RTCP.
Maxim Sobolev wrote:
address). Please also note that there is no other way to detect non-RTP-symmetric UA than to compare User-Agent/Server header field against list of known non-RTP-symmetric UAs.
Do we have access to such a list? /O
Olle E. Johansson wrote:
Maxim Sobolev wrote:
address). Please also note that there is no other way to detect non-RTP-symmetric UA than to compare User-Agent/Server header field against list of known non-RTP-symmetric UAs.
Do we have access to such a list?
No. The only popular non-RTP-symmetric UA I know about is cisco IOS.
-Maxim