Re: [rtcweb] SDP testing

On Oct 21, 2012, at 9:10 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

> Harald said: 
> 
> "When we started out, I expected a host of issues of the type you envision - where people who are reading the SDP specs have serious differences of opinion about what should be the right outcome - but so far, I haven't seen that happening."
> 
> [BA] Defining what SDP specs are relevant is not difficult.  draft-nandakumar-rtcweb-sdp enumerates the relevant specifications to a good degree of accuracy (I agree with 90+ percent of what is in the draft).   If all we had to do was quibble about which SDP references are MUST/SHOULD/MAY within that document, then with sufficient WG attention, the probability of convergence would be high.  However, this would not cover:
> 
> * Expectations for SDP parser resilience.  Experience indicates that this was not sufficiently well described in RFC 3264 and 4566.  For example, my understanding is that Chrome stops parsing in some cases when it hits SDP it does not understand.  While this approach is quite common in SDP implementations (and may not violate 3264/4566 so as to be classifiable as a "bug"), expectations for resilience could be better defined.  

We could put some implementer notes in one of the drafts to try and help cover some of the common things developers need to deal with. That would be helpful for many things that use SDP. Having some example SDP that included "bogus future extensions" that a parse should successfully ignore might help people test their SDP implementations. Note that unlike the IETF, the W3C tends to have have a conformance test suite to deal with things like this so in some weird way, the W3C might end up improving the interoperability of the SDP. 

> * Error handling.  What happens when the parser detects an error and how do we know what it objected to?  Is an exception or error callback fired?  Does this provide an indication of what SDP lines caused the error? Is there a way to retrieve the SDP that the browser decided to act upon (which may be different from what was input)? 

I think the combination of the JSEP and WebRTC spec need to get very clear on all the issues you raised. I'd like to see error handling a major part of the discussion at the W3C meeting as we have not really tacked that yet in the spec. Last time I looked, no one had replied to Anant's proposal. 

> * Guidance with respect to API usage, both general and specific, such as the questions Mathew mentioned. 

The issue of what can be changed that Mathew raised has been discussed as an open issue and we know that we need to nail that down in the specification. It seemed like one of the things that could be left till a bit later in the process when we had more information about what the use cases were and what to put. The one use case that has been raised very clearly is people want to be able to remove a particular codec for various reasons. I suspect that lots of people will argue to make sure that type of change of SDP is supported. I'm not sure what use case drive the rest but 100% agree this is a topic we need to put some time into.  Right now, it does not seem to be holding up implications which are still trying to nail down all the basic stuff along with ICE, DTLS, etc. 

> 
> Overall, these questions relate more to the API than to existing or in-progress SDP specifications within IETF, which raises the question of where they would be best addressed. 

I suspect most of them are in the WebRTC spec and some of them in ietf drafts but either way, I agree all the points you raised need to be specified. 

> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb