On 4 Sep 2012, at 23:49, Justin Uberti wrote: > > - What should I put in an OFFER for optional SRTP (so it works with both SRTP and RTP)? RTP/AVP is likely going to be rejected by WebRTC, while RTP/SAVPF is likely going to be rejected by legacy endpoints. Should WebRTC accept RTP/SAVPF and look for crypto lines like many devices that try to work around this? > > Out of curiosity, how many devices will reject RTP/SAVPF but will meet the other criteria for WebRTC (i.e. SRTP + ICE)? The problem is really in the reverse direction. Say I'm creating a fancy new PBX that wants to be able to generate calls to both WebRTC endpoints, and legacy SIP desk phones. The WebRTC endpoints are going to want RTP/SAVPF while the desk phones will want RTP/AVP. What should I as the PBX be putting in my SDP offer such that it will be acceptable to both classes of devices? (assuming here that the fancy new PBX is quite happy with ICE and SRTP and anything else, but sees them as optional for legacy desk phones.) My concern is that we end up requiring external endpoints to generate special (non legacy compatible) SDP for WebRTC and know in advance what type of endpoint the call is addressed to. If that's the case, then SDP re-writing is likely to be common and we may as well adopt a more expressive API. Neil
Received on Wednesday, 5 September 2012 06:19:54 UTC