[Serusers] rtpproxy address filling

Martin Hoffmann hn at nvnc.de
Wed Apr 2 05:37:06 CEST 2008


Stefan Sayer wrote:
> 
> >> so would the more secure fix maybe be to always allow a switch back to 
> >> the original address?
> ... to the original address only?
> 
> so that a switch to an address away from the original address would be 
> possible exactly once, but switching back to original address always.

But there is still forking. The way things work now is this: I detect
the caller and at least one of the recipients of the INVITE to be NATed
and activate RTP proxy. What happens is that RTP proxy returns an
address and a port which nathelper puts into SDP for all branches.

Now consider the case where three devices are registered. They all start
ringing. Two of them decide to not just say "180 Ringing" but to create
early media. Which one does RTP proxy allow media from? In the current
implementation, the UA that sends its media second wins. In the
suggested implementation, the UA that sends its media first wins long
term.

But: The third phone, which so far didn't do any media at all, is picked
up. The two other branches are CANCELed, the early dialog is terminated,
and the media streams end. The third phone wants to set up a media
stream for the actual real call -- and is ignored by RTP proxy because
it is considered an evil imposter.

Normally, you will not have this problem, because most UAs don't do
early media. But the moment you do something fancy, like forking the
call off to a PSTN number (eg., the user's cell phone) or playing a
custom ringback tone, you are skrewed.

The only solution I can think of is to make RTP proxy branch aware. You
could assign a separate port for each branch, but that is quite
wasteful and will most likely exaust the ports rather quickly.
I can't think of a way to correlate branches and media streams without
knowing IP address and port, though. Anyone have a clever idea?

Maybe TURN isn't such a bad idea after all.

> this would also work with your D-Link modems.

Ah, D-Link. What joy.

Regards,
Martin



More information about the sr-users mailing list