Re: Poll for preferred API alternative

I am concerned that this is a much larger task than has been anticipated and is going to highlight a lot of issues with SDP as an API.

The interop problem includes being able to recommend what SDP should look like for non-WebRTC endpoints that wish to communicate with both WebRTC and non-WebRTC peers. For example:

- 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?

- How do I signal a ptime per codec? Say I have a codec that requires a 30ms ptime, but prefer 20ms for other codecs? Can this be done in an interop way?

I'm sure these have good answers, but I'm not sure it's easy to ensure legacy endpoints do the right thing with WebRTC extensions present.

Neil

On 4 Sep 2012, at 07:34, Justin Uberti wrote:

> Right - we've been working on getting all the basics in place, but we expect to start interop testing in the near future, which will bring all these issues to the surface.
> 
> While using something other than SDP would make it easier to massage the session description, I'm not sure it would remove the interoperability issue you refer to.
> 
> 
> On Mon, Sep 3, 2012 at 9:37 AM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
> 
> On Aug 31, 2012, at 3:15 PM, Tim Panton <thp@westhawk.co.uk> wrote:
> 
> > My experience in phono is that we _always_ have to parse-fillet-rewrite the SDP in both directions to get chrome to interop with anything.
> >
> 
> It's true that the current Chrome SDP is not really workable SDP but I think that is simply an issue with they have not got around to that part of yet - the WebRTC/RTCWeb WGs have not even started serious WG discussion about what SDP extensions are going to be MTI. I think the chrome guys intent is to implement SDP that is widely compatible once we get around to figuring out what that is.
> 
> 
> 

Received on Tuesday, 4 September 2012 08:10:45 UTC