Re: [rtcweb] SDP testing

[Harald Alvestrand <[e-mail]>]

On 10/21/2012 01:20 AM, Bernard Aboba wrote:
> Harald said:
>
> "Thanks for the info - can you point to the bugs you filed on these 
> issues with our implementation? I'll try to see that they're followed up."
>
> [BA] To determine whether something is a "bug" or a "feature" it helps 
> to have a specification that states what is expected.  Since we're 
> primarily talking about SDP usage within the API rather than what 
> travels over the wire (after all, signaling is out of scope in 
> WebRTC), http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp is 
> only a baby step toward determining whether the SDP output by 
> createOffer is conformant or whether input to setLocalDescription or 
> setRemoteDescription should be acceptable or not, and if not, what 
> should happen.
>
> For example,  posting the SDP that is emitted by various createOffer() 
> implementations might enhance the appreciation of the importance of 
> the issue, I am not sure how to evaluate the results without 
> understanding whether that output is expected to be valid SDP or not. 
>  For example, if trickle ICE is used, then perhaps one should not 
> expect createOffer to provide SDP with valid addresses and ports 
> filled in; instead that information is expected to be filled in later.
Actually all of the issues I've seen in real testing so far have fallen 
into two broad cateories:

- Issues where the endpoints are known to be noninteroperable - for 
instance by requiring ICE, requiring SRTP, or using different video 
codecs. No amount of SDP munging will fix those.
- Issues where the Google implementors have failed to understand some 
subtlety of SDP syntax, encountered an SDP extension that we didn't 
expect to see, or didn't get around to handling that part of the syntax 
yet - for instance when we were sending "s=" instead of "s= ".

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.

Perhaps we haven't gotten to the hard parts yet, or perhaps the SDP 
specification, when used for the basic stuff that we're so far doing, is 
less troublesome than we thought?

That's why I keep on pushing for bugs to be filed - I believe we can 
identify problem areas more easily by saying "when X tries to negotiate 
a connection with Y, A happens, but B should happen instead".
Also, I learn much more from those discussions than a discussion phrased 
in general terms!

                 Harald