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

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