[sr-dev] Media proxy for RTCWeb (was: Testing the Websocket module with sipml5.org)

[Peter Dunkley]

> On Thu, Aug 16, 2012 at 6:09 PM, Carlos Ruiz Díaz
> That doesn't need to happen, only a good gateway needs to exist. Be it
> Kamailio, Asterisk, or whatever.
>

There are two separate protocols here.  (SIP over) WebSockets and RTCWeb.

Kamailio interworks SIP calls between the WebSockets and other transports.
 Media interworking (RTCWeb) is something separate.  Kamailio itself does
not handle media so the interworking for that needs to happen elsewhere.

It's always going to be better (more efficient and fewer interworking
issues) when the UAs support the required media profiles.  However, if a
gateway is required using Asterisk is probably not a generally workable
solution.  Asterisk will B2BUA the signalling rather than proxying it -
which is not ideal.

If the majority of UAs aren't going to support the required (RTP/SAVPF)
profile then the best interworking options would be to enhance a media
proxy (such as RTPproxy or MediaProxy) to convert.  No codec manipulation
is required for this, so it is potentially a very high-performance option.
 What would be needed:
1) media proxy to convert between RTP/SAVPF and RTP/SAVP
   This involves one side (the RTCWeb side) providing (the minimal) RTCP
required and the other not
2) media proxy to convert between RTP/SAVPF and RTP/AVP (for clients that
do not support secure RTP)
   This involves one side (the RTCWeb side) providing the (minimal) RTCP
required, decrypting received packets, encrypting packets for sending,
and the other side receiving/transmitting "plain" RTP

Some small updates would then be needed to the Kamailio rtpproxy or
mediaproxy modules to munge the SDP and call the external media proxy with
the correct options to initiate the profile conversion.

Of course the problem you will then have is choosing which calls need the
media proxy and which don't.
- WebSocket to WebSocket calls won't - but it will not always be the case
that Kamailio can tell that the destination of the call will be connected
over WebSockets (endpoint registered on a different network, and cases
involving parallel forking come to mind).
- Some non-WebSocket endpoint will support the correct media profile (and
this number will grow as time goes on) and using a media proxy for calls
to these is inefficient (additional bandwidth for media handling will be
required in the ITSP network _and_ undesirable latency is added to the
media path by unnecessary media proxies) - but how do you tell whether an
endpoint supports WebSockets or not in advance?

The right thing to do for the media conversion might be to always attempt
to make the call without the media proxy and then do appropriate handling
of 488 responses with message body.  That is, if the call with media
profile RTP/SAVPF is responded to with a 488 containing SDP indicating
support for:
- RTP/SAVP then the media proxy needs to be used and told to do conversion
1 above
- RTP/AVP then the media proxy needs to be used and told to do conversion
2 above

But of course, this requires the endpoint to fill in the 488 correctly -
which may not be the case ;-)


There has been some discussion on this list about updating the RTP proxy
(in particular the protocol used between Kamailio and the RTP proxy).  Is
this something that will happen within the Kamailio 3.4 timescale?

If it is, would the changes to the RTP proxy to support profile conversion
be something that could be considered at the same time?  If not, perhaps
consideration should be given to ensuring the updated protocol is one that
would comfortable support options for the profile conversions in the
future?


Regards,

Peter

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd