Hi, in reply to concers from Adam and Ted:


AFAIK nobody voting for dropping SDP is requesting a "new format to
replace SDP" (if I am wrong, then please correct me). What we all ask
for is:

- A JS API to ask the browser's WebRTC stack for media resources (this
is accomplished with getUserMedia).

- A JS API to provide the local PeerConnection with media data from a
remote peer we want to establish a multimedia session with, but such
an API must not be based on passing a blob SDP, but based on passing
some kind of JS Object with detailed media attributes, including
transport params (ICE fields, remote media types, remote codecs, other
media features, and so on).

- A JS API to request to our local PeerConnection media data that we
can send to the remote peer, in the way we want, in one step or in
multiple steps, and such an API call must not return a blob SDP but a
JS Object with detailed media attributes (same as above).

- Period.


We don't want to be forced to O/A model (although I know of no other,
but I do know there are other models that don't rely on O/A
semantics).

We don't want to deal with blob strings that must be retrieved from
our local PC and sent to the remote PC as they are, untouched. Instead
we want to pass and receive the media information in any custom way
(which can be serialized in JSON, represented as SDP, etc) in a single
step or in multiple steps (so those cared about ICE gathering delay
can optimize their cuscom logic and code).

And that's all (may be I miss something or I am wrong in some aspect).
And once we have that:

- There will appear cool JS libraries coded by SIP experts that will
take the above "JS Object with media information" retrieved from our
local PerrConnection and "export" it into a SDP string that will allow
interoperability with SIP devices (those supporting WebRTC media
requirements). For this, probably the IETF SIP WG may start a new item
for specifying how such a SDP must look. The JS library will be hosted
in some public server and will provide updates frequently ("press
F5").

- Some SIP vendors could also provide their own JS library that offers
more media features to interop with their gateways.

- Some others will code JS libraries defining a new media signaling
protocol in the wire.

- And some others will code their own media signaling library for
their websites in which they don't need interoperability with devices
other than pure WebRTC browsers.

- And some of them will use O/A and some others won't.



So, regardingyour concerns about how hard is replacing SDP with "a new
and better format", IMHO nobody is requesting that.


Best regards.

2013/6/18 Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net>:
> The good news is that I co-authored and Microsoft published a nice starting
> point for discussing a specification that doesn't have SDP O/A.
>
> The bad news is that it was voted down for future consideration at W3C.
>
> The good news is that W3C has apparently abdicated the entire responsibility
> for producing a browser API to IETF, where it has not yet been voted down.
>
> More good news is that if and when the W3C considers the current
> specification that the IETF produces, if it is not complete enough to
> independently replicate without looking at other browser's source code (in
> other words, if the SDP that is produced is not fully specified in an
> interoperable way in either the W3C specification itself or, worst case, in
> the entire stack of normative references), I will also have the pleasure of
> co-authoring a formal objection to publishing that specification.
>
> One might consider that since the current SDP-based path we are on does not
> have anywhere near a complete set of implementable normative references, and
> that producing such might actually be harder than using something that
> doesn't rely on SDP as the API surface, you might be a lot farther from
> something that finishes the entire W3C process than you think.
>
> Matthew Kaufman
>
> ________________________________
> From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Ted
> Hardie [ted.ietf@gmail.com]
> Sent: Tuesday, June 18, 2013 1:15 PM
> To: Iñaki Baz Castillo
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
>
> I've read the messages on this thread up to lunchtime in California on June
> 18th.  I have not consulted with the other chairs, because we are still
> somewhat out of synch, so this is my personal response, rather than a chair
> response.
>
> SDP occurs as an API control surface in this protocol, and it may also be
> used in O/A semantics between endpoints.  The request does not clearly state
> which aspect is asking for reconsideration.  Since one is handled in a
> different group, that is critical.  Secondly, the requirement the group has
> is that the solution *provides support sufficient to allow O/A semantics*,
> not that these must be used between two parties using the same signalling.
> Being clear on what you would like to see by writing a draft proposal,
> rather than simply asking to re-open concluded discussions would be helpful.
>
> Speaking very personally, I would like to see the group close having
> completed its milestones.  While I am very aware that re-using a syntax like
> SDP makes for some unpleasant moments, I'm not sure that any system that
> actual has any level of interoperability with existing SIP deployments as a
> goal will avoid that unpleasantness--at best, you have a mechanism on one
> end that looks different *but must be mapped to SDP* in the interoperability
> case.   Creating something new that accomplishes that and is substantially
> better than SDP seems like a long task to me.
>
> Again, not as a chair decision or statement, but to give some response to
> the points made.
>
> regards,
>
> Ted Hardie



-- 
Iñaki Baz Castillo
<ibc@aliax.net>