Re: [rtcweb] SDP testing

[Bernard Aboba <[e-mail]>]

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.  
* 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)? 
* Guidance with respect to API usage, both general and specific, such as the questions Mathew mentioned. 

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.