[Users] rtpproxy + video issues

Laurent Schweizer laurent.schweizer at gmail.com
Thu May 11 10:39:11 CEST 2006


Hello,


This is the diff of my nathelper.c


Laurent



-----Original Message-----
From: Danish Samad [mailto:danish.samad at vocalseeds.com] 
Sent: jeudi, 11. mai 2006 19:10
To: Laurent Schweizer
Cc: 'Walter Schober'; 'Bogdan-Andrei Iancu'; users at openser.org
Subject: RE: [Users] rtpproxy + video issues


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: users-bounces at openser.org [mailto:users-bounces at openser.org] On
Behalf
> Of Walter Schober
> Sent: mercredi, 10. mai 2006 17:52
> To: 'Bogdan-Andrei Iancu'; danish.samad at vocalseeds.com
> Cc: users at openser.org
> 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: users-bounces at openser.org [mailto:users-bounces at openser.org] On
Behalf
> Of Bogdan-Andrei Iancu
> Sent: Wednesday, May 10, 2006 1:22 PM
> To: danish.samad at vocalseeds.com
> Cc: users at openser.org
> 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
> 
> danish.samad at vocalseeds.com 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
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_natheper.c
Type: application/octet-stream
Size: 2411 bytes
Desc: not available
Url : http://lists.kamailio.org/pipermail/users/attachments/20060511/b89272f1/attachment.obj 


More information about the Users mailing list