Hi Linda!
Have you tried to use the SER "mediaproxy" module instead of "nathelper"?
This is an alternative implementaion for SER to overcome NAT problems, and it can handle more than one media line in an SDP. I use it mostly for audio/video sessions and it works just fine.
cheers, Bernie
On Fri, 24 Sep 2004, Linda Xiao wrote:
Yes. This is the root cause.
It seems that it is the limitation for nathelper. But nowadays, it is easy to get multi-line media descriptions in SDP, even for a single media type transmission. An example is for those UAs that support RFC3264. The line can be divided by different ptime.
Regards/Linda
-----Original Message----- From: Andrei Pelinescu-Onciul [mailto:[EMAIL PROTECTED] Sent: Thursday, September 23, 2004 12:15 AM To: Linda Xiao Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: [Serdev] NAT traversal for RTP stream
On Sep 21, 2004 at 11:58, Linda Xiao <[EMAIL PROTECTED]> wrote:
Hi all,
I have 2 Uas setup behind a NAT. After a call is initiated, "te2sp1" can build 2-way rtp traffic while "ak2sp1" cannot. Attached please find the ethereal dump. By comparing of these 2 dumps, I cannot find out the reason. Can anyone identify why server side stopped RTP transmission to "ak2sp1"?
I think that's because you have multiple m=audio lines in the ak2sp1 INVITE sdp. The proxy (ser) uses nathelper to fix the sdp of the natted clients and force their rtp streams through rtpproxy. The current nathelper version doesn't support multiple m= lines. It will change only the first one, leaving the others unchanged. The UA from the other side probably picks the port from the second or third m= line, and so it tries to send the rtp to proxy:5004 instead of proxy: dynamically_allocated_rtpproxy_port.
Andrei
_______________________________________________ Serdev mailing list [EMAIL PROTECTED] http://mail.iptel.org/mailman/listinfo/serdev
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
