Hi Laurent, I noticed this issue as well. I have started trying to fix the issue by adding some code in rtpproxy (right after the to_tag is matched in handle_command). Looking at your mail I think your solution, by changing nathelper, seems more feasible. Can you send us a patch, so I can test it out on my end as well. If it works I think it should be appended in the development head as well.
Regards, Danish On Wed, 2006-05-10 at 23:32 +0200, Laurent Schweizer wrote: > The bug is in the nathelper, the nathelper add a ";" with an increment id > after the from tag (exemple 12344;1 for the audio stream and 12345;2 for the > video stream) before sending the request to the rtpproxy. The bug is that he > is not doing this with the To tag. So I see that when the reinvite is > emitted by the receiver of the call the rtpproxy can't locate correctly > audio or video stream and send a 0 port as reply. > > I have attached a log where you can see that. > > The solutions is to made a little change in the nathelper to also add the > ";1" ... for the To tag. It's working for me, I use it with openwengo. > > > Laurent > > > > all logs > > received command "U 3420006225 at 192.168.1.33 83.76.253.30 10600 > 3835457540;1" > new session 3420006225 at 192.168.1.33, tag 3835457540;1 requested, type > strong > new session on a port 35006 created, tag 3835457540;1 > pre-filling caller's address with 83.76.253.30:10600 > sending reply "35006 62.2.xxxxxxxx > " > > received command "U 3420006225 at 192.168.1.33 83.76.253.30 10700 > 3835457540;2" > new session 3420006225 at 192.168.1.33, tag 3835457540;2 requested, type > strong > new session on a port 35008 created, tag 3835457540;2 > pre-filling caller's address with 83.76.253.30:10700 > sending reply "35008 62.2.xxxxxxx > " > > received command "L 3420006225 at 192.168.1.33 62.2.yyyyyy 13908 > 3835457540;1 as6e4b6526" > lookup on ports 35006/35010, session timer restarted > pre-filling callee's address with 62.2.195.189:13908 > sending reply "35010 62.2.xxxxxxxx > " > > > caller's address filled in: 83.76.253.30:55351 (RTP) > callee's address filled in: 193.zzzzzzzzz:19320 (RTP) > guessing RTCP port for callee to be 19321 > received command "U 3420006225 at 192.168.1.33 193.zzzzzzzz 19320 > as6e4b6526;1 3835457540" > adding strong flag to existing session, new=1/0/0 > lookup on ports 35008/0, session timer restarted > pre-filling callee's address with 193.zzzzzzzzz:19320 > ---------- >>>>>>>>>> >>>> sending reply "0 62.2.xxxxxx > " > > received command "L 3420006225 at 192.168.1.33 192.168.1.33 10600 > as6e4b6526;1 3835457540" > lookup on ports 35012/0, session timer restarted > pre-filling caller's address with 192.168.1.33:10600 > sending reply "35012 62.2.xxxxxxx > " > > received command "D 3420006225 at 192.168.1.33 3835457540 as6e4b6526" > forcefully deleting session 2 on ports 35012/0 > RTP stats: 308 in from callee, 0 in from caller, 308 relayed, 0 dropped > RTCP stats: 3 in from callee, 0 in from caller, 3 relayed, 0 dropped > session on ports 35012/0 is cleaned up > forcefully deleting session 1 on ports 35006/35010 > RTP stats: 267 in from callee, 687 in from caller, 954 relayed, 0 dropped > > RTCP stats: 1 in from callee, 0 in from caller, 1 relayed, 0 dropped > > session on ports 35006/35010 is cleaned up > > sending reply "0 > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Walter Schober > Sent: mercredi, 10. mai 2006 17:52 > To: 'Bogdan-Andrei Iancu'; [EMAIL PROTECTED] > Cc: [email protected] > Subject: RE: [Users] rtpproxy + video issues > > I did that with a > If (loose_route()) > if method==INVITE > #this is an reinvite > unforce_rtpproxy() > ... > re-aquire rtpproxy ressources. > > Then you will get new ports from rtpproxy and everything is working fine :-) > At least it did for me. > > I guess it's a bug in the rtpproxy, if a ressource is again requested with > additional ressources as video. > > Br > Walter > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Bogdan-Andrei Iancu > Sent: Wednesday, May 10, 2006 1:22 PM > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [Users] rtpproxy + video issues > > Hi, > > most probably the reason is your are not performing properly from script > the NAT traversal for sequential request (especially for INVITE). > > to be sure that;s the case you may try using rtpproxy for all cases > (nated or not) to see if this solves your problem. > > regards, > bogdan > > [EMAIL PROTECTED] wrote: > > >Hi, > > > > I am trying to deploy a openser solution supporting NAT traversal. So far > >I have dome some testing with rtpproxy and have yet to look into the > >media proxy solution. I have IP Phones that support both audio and video > >calls and as a requirement the setup should be able to do NAT traversal > >for both audio and video streams. > > > > Initially two phones connect with only audio streams active. Any side can > >activate a video request in which case a reinvite is sent to the other > >side indicating video codecs in the SDP. In case, any one or both sides > >are nated the server should rewrite SDP port to route traffic through > >itself. I tried to use a config with nathelper and rtpproxy, Initially > >audio ports and IP in the SDP are rewritten correctly but when one phone > >sends a reinvite for video the video port in the 200OK reply message is > >not rewritten and is sent as received. This results in the video being > >sent to an incorrect port on the server (running rtpporxy) and therefore > >no video is relayed. > > > > > > > > > _______________________________________________ > Users mailing list > [email protected] > http://openser.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [email protected] > http://openser.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ Users mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/users
