Re: Poll for preferred API alternative

First of all I would like to say thanks for raising real issues rather than the normal SDP FUD … inline

On Sep 4, 2012, at 2:10 AM, Neil Stratford <nstratford@voxeo.com> wrote:

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

If you want to make an OFFER that will work with a device that does only AVP and a device that only does SAVPF, the things that works is to include but AVP and SAVPF profile in your offer - lots of stuff does that. We should probably put some examples in the JSEP doc showing that with non normative text that helps implementors know what they might want to do.

> Should WebRTC accept RTP/SAVPF and look for crypto lines like many devices that try to work around this?

I suspect you meant should WebRTC implementations look for a=fingerprint lines in  RTP/AVP  . The academic answer to that is that a large food fight will eventually happen at IETF on that topic. The pragmatic answer to that is yes.  

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

The offer should have maxptime set to 30 and ptime set to 20. 

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

So far the only webrtc extension being proposed is bundle and, I agree, it is going to take some effort to make sure it is defined in a way where things that don't understand bundle are not broken by it but I think that is very doable. 

> 
> Neil

Overall, I agree that work is needed to define what the MTI and suggested ways of using SDP are for WebRTC. 

> 
> 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 Thursday, 6 September 2012 21:15:42 UTC