Interoperable signaling

I think these are valid concerns, but I think you are hitting on two
slightly different questions here:
1) "How do we generate maximally interoperable SDP?"
2) "What can't we do with SDP, as it is currently defined?"

Regarding 1), if we want to interoperate with legacy devices that speak
SDP, we need to answer this question regardless of the API.
Regarding 2), if we consider your ptime example, we need to either a)
extend SDP to provide the desired functionality (which would be necessary
if this is to work in a legacy interop scenario), or b) make the internal
representation of SessionDescription something other than SDP. The
description could always be converted to SDP, but if ptime was set in such
a way that it couldn't be fully expressed in SDP, it would be lossy.

There are pros and cons to either a) or b), but neither option requires
major API changes.

A few additional comments inline.

On Tue, Sep 4, 2012 at 1: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. Should WebRTC
> accept RTP/SAVPF and look for crypto lines like many devices that try to
> work around this?
>

Out of curiosity, how many devices will reject RTP/SAVPF but will meet the
other criteria for WebRTC (i.e. SRTP + ICE)?

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

Note that Jingle addresses this by making ptime an attribute of a
<payload-type/> (i.e. codec), as shown in
http://xmpp.org/extensions/xep-0167.html#format. This implies that at the
current time, some Jingle->SDP conversions are lossy (although fixing this
particular case is probably straightforward).


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