Subject: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)

From: Ted Hardie <[email-masked]>
Date: Tue, 4 Oct 2011 09:01:26 -0700

At today's Chairs call, Cullen, Magnus and I had a discussion of how to make
progress on the signaling discussion.  We feel the mailing list discussion
needs to have more concrete proposals in order to make progress, and so
we're putting forward the following:

1) If you plan to put forward a draft proposing a concrete solution in this
space, please send your name to the mailing list with that intent by October
7th *THIS FRIDAY*.

2) Please have a -00 draft out for discussion by October 14th (the following
Friday).  This is to allow for a discussion and update prior to the -01
deadlines.

3) We will hold a conference call to discuss the drafts on October 21st (the
Friday after that).

Updates based on that discussion then have until the -01 drafts deadline to
be complete.

This is aggressive, but we feel we need to have at least -00s for the
different ideas in place in order to make real progress.

thanks,

Ted, Magnus, Cullen

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 5 Oct 2011 00:32:50 +0200

2011/10/4 Ted Hardie <[email-masked]>:
> 7th *THIS FRIDAY*

Hi Ted, could you please explain what exactly are you looking for? a
concrete signaling mechanism within rtcweb? something native in
browsers? something carried by HTTP/WebSocket?

If so, I think that this should not be covered by rtcweb, which
instead should define a good API for dealing with SDP bodies (plain or
XML), create some kind of JavaScript object for mantaining each
session status and information (negotiated streams, codecs,
local/remote address...).

But for sure I miss something so I would like to know what exactly are
you looking for in your mail.

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 4 Oct 2011 17:06:39 -0700

> browsers? something carried by HTTP/WebSocket?
Hi Iñaki,

The chairs don't currently detect consensus on how signaling will be handled
for RTCWeb sessions.  We don't want to circumscribe the solution space, but
we do feel that there is a need to have concrete proposals, rather than
broad statements like, "it shouldn't be in the component X".  Concrete
proposals for how it will be handled are the best way we see to make sure
folks are coming to consensus on something they understand, rather than on
rhetoric.

> local/remote address...).
If you would like to make a concrete proposal for how that JavaScript object
is constructed, what it contains, and how it is shipped around, that would
be great.   Without a statement of what those details are, however, the
chairs worry that people will argue (for and against) proposals that have
not been made.

We await your electrons with great interest!

Ted

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 04 Oct 2011 19:15:59 -0700

On 10/4/2011 9:01 AM, Ted Hardie wrote:
> At today's Chairs call, Cullen, Magnus and I had a discussion of how 
> to make progress on the signaling discussion.  We feel the mailing 
> list discussion needs to have more concrete proposals in order to make 
> progress, and so we're putting forward the following:
>
> 1) If you plan to put forward a draft proposing a concrete solution in 
> this space, please send your name to the mailing list with that intent 
> by October 7th *THIS FRIDAY*.

I'm going to nominate myself here.

>
> 2) Please have a -00 draft out for discussion by October 14th (the 
> following Friday).  This is to allow for a discussion and update prior 
> to the -01 deadlines.
>

I believe that defining a signaling protocol between web browsers and 
web servers for RTCWEB is out of scope, so I believe there is no draft 
required... unless you really want a -00 draft that says "do nothing".

I believe that defining a signaling protocol between web servers and 
other web servers for RTCWEB federation is out for scope for "version 
1", so I believe it is not appropriate to submit a draft at this time... 
unless you really want a -00 draft that says "do nothing for now, use 
any of the existing protocols until then."

> different ideas in place in order to make real progress.

As I pointed out in my presentation at the interim, standardizing the 
protocol between the web browser and the web server != the protocol 
between the web browser and the javascript running in it. And so even if 
you want SDP on the wire, you don't necessarily need SDP in the API... 
and vice versa.

So in this case, I believe standardizing the protocol on the wire for 
signaling is out of scope. And we're already making good progress on the 
wire protocol for media (and media consent).

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 04 Oct 2011 19:41:11 -0700

On 10/4/2011 5:06 PM, Ted Hardie wrote:
> On Tue, Oct 4, 2011 at 3:32 PM, Iñaki Baz Castillo <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     2011/10/4 Ted Hardie <[email-masked] <mailto:[email-masked]>>:
> The chairs don't currently detect consensus on how signaling will be 
> handled for RTCWeb sessions.  We don't want to circumscribe the 
> solution space, but we do feel that there is a need to have concrete 
> proposals, rather than broad statements like, "it shouldn't be in the 
> component X".  Concrete proposals for how it will be handled are the 
> best way we see to make sure folks are coming to consensus on 
> something they understand, rather than on rhetoric.

See my earlier email. Concrete proposal is: This Working Group does not 
produce *any* standard for what travels on the wire (as signaling) 
between an RTC Web Browser and its associated Web Server. This Working 
Group also does not at this time produce *any* standard for what travels 
on the wire (as signaling) between two web servers that wish to have 
interoperating communities of RTC Web Browsers, though the working group 
*may* address this at a future time, noting that several existing 
protocols are usable in the interim.

> If you would like to make a concrete proposal for how that JavaScript 
> object is constructed, what it contains, and how it is shipped around, 
> that would be great.   Without a statement of what those details are, 
> however, the chairs worry that people will argue (for and against) 
> proposals that have not been made.
>

I believe that a concrete proposal for the JavaScript API and the 
associated objects is out of scope for the IETF WG. Thus the details, 
for the purpose of this working group, would be "this is out of scope".

Matthew Kaufman

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 5 Oct 2011 04:35:42 +0000

The draft already exists, available here:
http://www.ecma-international.org/publications/standards/Ecma-262.htm

There are also lots of free tutorials about writing it, available here:
http://www.google.com/search?q=javascript

There are even lots of books about it, available here:
http://www.amazon.com/s/field-keywords=javascript

-hadriel

On Oct 4, 2011, at 12:01 PM, Ted Hardie wrote:

> At today's Chairs call, Cullen, Magnus and I had a discussion of how to make progress on the signaling discussion.  We feel the mailing list discussion needs to have more concrete proposals in order to make progress, and so we're putting forward the following:
> 
> 1) If you plan to put forward a draft proposing a concrete solution in this space, please send your name to the mailing list with that intent by October 7th *THIS FRIDAY*.
> 
> 2) Please have a -00 draft out for discussion by October 14th (the following Friday).  This is to allow for a discussion and update prior to the -01 deadlines.
> 
> 3) We will hold a conference call to discuss the drafts on October 21st (the Friday after that).
> 
> Updates based on that discussion then have until the -01 drafts deadline to be complete.
> 
> This is aggressive, but we feel we need to have at least -00s for the different ideas in place in order to make real progress.
> 
> thanks,
> 
> Ted, Magnus, Cullen
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 5 Oct 2011 12:33:04 +0530

Ted, Magnus, Cullen,

Could you please consider RTCWeb standard signaling protocol
(http://tools.ietf.org/id/draft-partha-rtcweb-signaling-00.txt) draft as
one of the proposal for this signaling discussion.
 
Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ted Hardie
Sent: Tuesday, October 04, 2011 9:31 PM
To: [email-masked]
Subject: [rtcweb] Making progress on the signaling discussion (NB:
Actionitems enclosed!)

At today's Chairs call, Cullen, Magnus and I had a discussion of how to
make progress on the signaling discussion.  We feel the mailing list
discussion needs to have more concrete proposals in order to make
progress, and so we're putting forward the following:

3) We will hold a conference call to discuss the drafts on October 21st
(the Friday after that).

Updates based on that discussion then have until the -01 drafts deadline
to be complete.

thanks,

Ted, Magnus, Cullen

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 5 Oct 2011 09:59:12 +0200

> any of the existing protocols until then."

I think also this proposal do require an Internet draft which discusses
the requirements put on the API. What of the underlying protocols that
are this WG task needs to be exposed in different forms?

My understanding of your idea is that you have both capabilities and
knobs that can be set. I also believe it requires some state
transitioning events. For example to kick of ICE negotiation between the
peers when the right things has been set.

Thus, I personally do see a need for draft from you that explains the
details of how things are expected to work. I don't see you needing to
define how the API should really look, but what the requirements on that
API are based on your solutions. But without that your proposal is still
not clear and open for a lot of interpretation.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 5 Oct 2011 11:19:53 +0200

> We await your electrons with great interest!

Hi Ted, I'll very busy next days but next week I'll try to give
something more useful.

Anyhow, I think we must be careful here. Maybe somebody proposes a
signaling mechanism that "works for him" but avoids others to build
their own signaling (if just those requirements are included in rtcweb
specs).

For example, I've seen recently a proposal for SDP managing in which
the client (the JS code in the browser) is a "stupid" element (sorry
for the word) and asks the server (via HTTP) for all the stuf related
to SDP. Maybe this could work for its specific use case, but IMHO we
should not rely on SDP processing/validating/whatever in server side.
We have now all the tools to make a web browser + JS code an
intelligent element. The web page is not just a visual interface
anymore. Realtime signaling (via WebSocket) and media (rtcweb) is
already possible (or will be), and JavaScript allows building a real
application in client side.

In my case (SIP over WebSocket) the client, a JavaScript SIP stack, is
a pure SIP client (which can also parse SDP bodies), and the "server"
is in fact a *pure* SIP proxy implementing the WebSocket transport
(along with UDP, TCP and so). The WS server (so the SIP proxy) does
*nothing* special for clients on a web browser (it does not change the
SDP, it does not behave as a SIP B2BUA, it just routes SIP messages).
WebSocket is just a new SIP transport, nothing else. I will show it
next week.

So I strongly need that the rtcweb client (the web browser) is able to
deal with SDP bodies (or JS objects mapping the information in a plain
or XML SDP) and can make WebRTC calls via a standarized JS API to deal
with SDP's and sessions.

For example, let's suppose I'm the JavaScript custom code running in a
browser and implementing SIP over WebSocket. Me (the JavaScript code)
is speaking to the WebRTC JS API:

- I receive a SIP INVITE from a peer and render it to my human user
("Bob is calling you, answer? reject?"). The human user accepts the
call.

- I've received an SDP body from the peer (in the incoming INVITE via
WebSocket). WebRTC stack, please parse it and give me a JS object
representing it:

  var remote_sdp = new WebRTC.SDP(string, "plain");

- I examine the SDP object and realize that the peer is offering audio
and video.

- Now please generate my SDP as a reply for the received SDP:

  var my_sdp = WebRTC.SDP.answerFor(remote_sdp);

- ...but discard the video offered by the peer.

  my_sdp.removeStream("video");

- Now I need the plain representation of my SDP (to be included within
the SIP 200 OK response):

  var my_plain_sdp = my_sdp.toPlain();

- I send the SIP 200 OK response via WebSocket.

- Now start the real media session!:

  var session = new WebRTC.Session(my_sdp, remote_sdp);
  session.start();

- After a while I want to invite the peer to a video session (over the
existing audio session). So first I add the video offer in my SDP
object (it would also increment the sessid field in the SDP):

  my_sdp.addStream("video");

- Then regenerate my plain SDP to be included in a re-INVITE to be
sent to the peer:

  var my_plain_sdp = my_sdp.toPlain();

- I get a 200 OK response with a new remote SDP, so parse it into a JS object:

  var remote_sdp = new WebRTC.SDP(string, "plain");

- I examine the remote SDP to tell my human user wheter the video
session has been accepted by the peer or not.

  if (remote_sdp.hasStream("video"))
    alert("yeah! the peer accepted video!");

- And now tell the rtcweb stack to update the existing media session:

  session.update(my_sdp, remote_sdp);

- Now I want to put on hold the call, so:

  my_sdp.putOnHold();

- Then regenerate my plain SDP to be included in a re-INVITE to be
sent to the peer:

  var my_plain_sdp = my_sdp.toPlain()

- ...and so on...

NOTE: The above is just pseudo-code and of course must be terribly improved.

Said that, I think that stating the requirements for *any* signaling
mechanism should be the key right now, rather than proposing specific
signaling mechanism that "works for me and covers my specific needs
(and I don't care about others)". IMHO defining the needs in the
WebRTC API is the only important now (IMHO).

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 5 Oct 2011 11:26:53 +0200

2011/10/5 Ravindran Parthasarathi <[email-masked]>:
> (http://tools.ietf.org/id/draft-partha-rtcweb-signaling-00.txt) draft as one
> of the proposal for this signaling discussion.

Partha, instead of re-suggesting your draft in different threads,
please take the time to reply to the given rationale against your
insistent proposal.

Said that, your draft does NOT propose a signaling protocol, it just
wants to *mandate* that SOME specific protocol MUST be implemented in
all the rtcweb clients and servers. Please, forget that idea. There is
an extended reply and rationale for any of your arguments. A web
browser will not implement a native SIP or MEGACO stack, never (I
hope). The WWW world cannot be converted into a telco business.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Tim Panton <[email-masked]>
Date: Wed, 5 Oct 2011 11:03:54 +0100

>  my_sdp.removeStream("video");

It seems to me that by calling WebRTC.SDP.answerFor() - getting the native code
to do the 'compatibility matching' you've lost quite a lot of influence over the selection process.
Lets say this is a conference app on an android phone - and lets say that the phone supports
h 261, h263 and h264 but only has hardware accel for h264 - the app's screen layout is such that
we only want a postage stamp of the remote user and a still image would be preferable to a
poorly rendered moving one (less distracting) . (so I'd like h264 or nothing)

How does the app express that set of preferences in your scenario?

If the app gets all the capabilities data as JSON objects, it can make decisions itself,
eliminating the ones that don't fit the usecase even though they do actually 'match'.

That's why I'd like to see the matching and elimination done in javascript, with the data
presented in a JS friendly manner. It can then be converted to SDP for sending over the 
(web-socket) wire if needed.

Tim.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 5 Oct 2011 12:09:57 +0200

> (web-socket) wire if needed.

Hi Tim, honestly I didn't expect to define the full WebRTC JS API in 5
minutes while I was writting the mail :)

Your points are perfectly valid and should indeed be covered. But I
didn't want to be so explicit in my immature API suggestion. It was
just an overview.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Tim Panton <[email-masked]>
Date: Wed, 5 Oct 2011 11:13:04 +0100

> minutes while I was writting the mail :)

;-)

> didn't want to be so explicit in my immature API suggestion. It was

I guess what I was getting at was the fact that the SDP seemed 
central to the API - I'd like something more generic and javascript 
friendly as the central concept.

---

From: Tim Panton <[email-masked]>
Date: Wed, 5 Oct 2011 11:29:12 +0100

;-)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 5 Oct 2011 12:40:15 +0200

> friendly as the central concept.

Hi Tim. At the end you web application will receive (via the custom
signaling) something "like" and SDP containing the media information
offered/answered by the peer (when receiving or initiating a media
session).

This is: your web browser needs to know the remote IP:port, the media
streams, supported codecs by the peer... At the end that looks like a
SDP. And such "SDP" should be retrieved by your web application via
some signaling protocol (on top of HTTP or WebSocket), and you will
receive it as a JSON object, or XML, or whatever format.

Then you will always need to parse such "like-SDP", obtain something
like a WebRTC.SDP object, and use it for starting/answering a session.

You can propose a different name, something like...
"WebRTC.SessionDescription"? :)
but the underlying concept is the same (IMHO).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 5 Oct 2011 12:40:51 +0200

2011/10/5 Iñaki Baz Castillo <[email-masked]>:
> signaling) something "like" and SDP

I meant "something like a SDP"

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Tim Panton <[email-masked]>
Date: Wed, 5 Oct 2011 12:05:18 +0100

> receive it as a JSON object, or XML, or whatever format.

Agreed. We are now getting down to the format, I'd like to see the
codec capabilities separated from the network ports , as to my mind they
are orthogonal. SDP gets into all sorts of complexity with IPv6 (e.g. happy eyeballs)
partly because it intermixes the 2 things. 

> like a WebRTC.SDP object, and use it for starting/answering a session.

Yes, we will need that information to set up the session. 
I'd like the format of that information to be one that I can easily
manipulate it - selecting the relevant ports and codecs in javascript
without actually needing to parse or use SDP or being limited to offer-answer 
semantics.

> but the underlying concept is the same (IMHO).

Yes, we are now discussing detail, but as they say, the devil is in the detail ;-)

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 05 Oct 2011 14:35:52 +0200

On 10/05/2011 01:05 PM, Tim Panton wrote:
>> 2011/10/5 Tim Panton<[email-masked]>:
Unfortunately the two things are tied together in nontrivial ways by our 
choice of RTP.

The media engine has to generate RTP packets, which have to be marked 
with a specific payload type (negotiated between the endpoints to 
represent the codec), and have to have an SSRC and IP destination 
address put onto them that will cause the remote end to identify the RTP 
session (from IP address) and media stream (from SSRC) correctly; since 
PT values are only valid within a single RTP session, it follows that 
one cannot deduce the codec from the incoming packet without being party 
to the negotiation of IP addresses.

I'm certain this can be represented in a cleaner way than SDP currently 
does it. But "orthogonal", if taken at face value, seems to hope for a 
more well structured world than is currently achievable.

                    Harald

---

From: Tim Panton <[email-masked]>
Date: Wed, 5 Oct 2011 13:46:11 +0100

On 5 Oct 2011, at 13:35, Harald Alvestrand wrote:

> Unfortunately the two things are tied together in nontrivial ways by our choice of RTP.
> 
> The media engine has to generate RTP packets, which have to be marked with a specific payload type (negotiated between the endpoints to represent the codec), and have to have an SSRC and IP destination address put onto them that will cause the remote end to identify the RTP session (from IP address) and media stream (from SSRC) correctly; since PT values are only valid within a single RTP session, it follows that one cannot deduce the codec from the incoming packet without being party to the negotiation of IP addresses.
> 
> I'm certain this can be represented in a cleaner way than SDP currently does it. But "orthogonal", if taken at face value, seems to hope for a more well structured world than is currently achievable.

- ah, now you have dashed my hopeful optimism and made me sad ;-)

Seriously - I think that they remain orthogonal during the _selection_ process. It isn't until we actually _commit_ to a set of codecs/ports etc
that they become intertwined. I guess I'm hoping that we can hide that from the Javascript coder without limiting the flexibility of
the API we present them by delaying the inevitable complexity as long as possible.

Tim

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 5 Oct 2011 14:51:31 +0200

On 2011-10-05 12:03, Tim Panton wrote:
> h 261, h263 and h264 but only has hardware accel for h264....

To me it seems that the browser (at least the one integrated by the 
device manufacturer) has a much greater chance of knowing what codecs 
are HW accelerated than the application - or do you expect a large 
database where device, version, OS-version, browser, browser version 
etc. is stored?

My preference would rather be that the app hints (as Tim proposed in 
<http://lists.w3.org/Archives/Public/public-webrtc/2011Oct/0004.html>), 
the browser proposes (by some kind of offer where the codecs are listed 
in preference order). If the offers are available to the application 
(for transport to the other end) it can override it there are objections.

Stefan

---

From: Tim Panton <[email-masked]>
Date: Wed, 5 Oct 2011 14:25:17 +0100

On 5 Oct 2011, at 13:51, Stefan Håkansson LK wrote:

> To me it seems that the browser (at least the one integrated by the device manufacturer) has a much greater chance of knowing what codecs are HW accelerated than the application - or do you expect a large database where device, version, OS-version, browser, browser version etc. is stored?

I'd expect the app to be able to query the browser - possibly a 'cpu cost' field returned in the list of supported codecs ...

> 
> My preference would rather be that the app hints (as Tim proposed in <http://lists.w3.org/Archives/Public/public-webrtc/2011Oct/0004.html>), the browser proposes (by some kind of offer where the codecs are listed in preference order). If the offers are available to the application (for transport to the other end) it can override it there are objections.

Which to my mind is putting the cart before the horse. The app (as the representative of the user) should take the lead here, not be reduced to
vetoing offers from the all-knowing browser. I know it is largely a philosophical difference, but I think we risk being stuck in a mindset derived from
a world where the core had no access to the user and there was only a single application, so the switch had to do the best it could without any
other input.

Tim.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 5 Oct 2011 15:35:11 +0200

On 2011-10-05 15:25, Tim Panton wrote:
> Which to my mind is putting the cart before the horse. The app (as the representative of the user)...
I guess I see the User Agent representing the user, and the app 
representing the service provider...philosophical discussion :)

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Oct 2011 09:42:33 -0700

> are this WG task needs to be exposed in different forms?
I strongly agree with Magnus here.  It's very easy for a statement saying
that a standardized signaling protocol is out of scope to create
presumptions about where data the proprietary signaling protocols use comes
from, what its form is, the level of granularity it has, and how it is
packaged.  We need concrete proposals in order to evaluate whether the
implications of that general statement are acceptable to the working group.

regards,

Ted

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Oct 2011 09:44:33 -0700

Hi Partha,

We'd be happy to consider a signaling protocol proposal from you.
Unfortunately, the current iteration of your draft does not contain a
concrete proposal so much as a discussion of the advantages of a
standardized signaling protocol.   To make further progress, the chairs
believe we need concrete proposals at this time.  Please let us know if you
would like to provide an update with a concrete proposal.

thanks,

Ted

On Wed, Oct 5, 2011 at 12:03 AM, Ravindran Parthasarathi <
[email-masked]> wrote:

>  Ted, Magnus, Cullen,****
>
> ** **
>
> Could you please consider RTCWeb standard signaling protocol (http://tools.ietf.org/id/draft-partha-rtcweb-signaling-00.txt) draft as one of the proposal for this signaling discussion.****
>
> ** **
>
> Thanks****
>
> Partha****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Ted Hardie
> *Sent:* Tuesday, October 04, 2011 9:31 PM
> *To:* [email-masked]
> *Subject:* [rtcweb] Making progress on the signaling discussion (NB:
> Actionitems enclosed!)****
>
> ** **
>
> discussion needs to have more concrete proposals in order to make progress,
> and so we're putting forward the following:
>
> following Friday).  This is to allow for a discussion and update prior to
> the -01 deadlines.
>
> Ted, Magnus, Cullen****

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 05 Oct 2011 09:40:57 -0700

> representing the service provider...philosophical discussion :)

Yes, I rather consider the "agent" the remote end-point of the user such 
that presence of "user" and "agent" is not the same. The assumption they 
are the same is not practical, yet we've worked around it.

The "User-Agent:" field is that cart, yet where/when did that ever 
really explain the horse (be at...)?

(...I'm "avoiding" multi-headed discussion here in hopes to find clarity 
with SDP and spoken-for JS API).

-- 

---
<i>The wheel.</i metro-link=t dzonatasolyndra>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Oct 2011 09:46:04 -0700

On Wed, Oct 5, 2011 at 2:19 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> handled
> object
Sorry, but do you intend to provide a draft?  It was hard for me to parse
whether the statement above is a commitment or a statement that you don't
have time.

regards,

Ted

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 5 Oct 2011 19:03:09 +0200

> whether the statement above is a commitment or a statement that you don't

Maybe not a draft, but a complete explanation and presentation of what
we have working (SIP over WebSocket + JavaScript code implementing a
SIP stack + SIP proxy implementing the WebSocket transport). And it
just works.

The draft is already done:

  http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00

In fact it defines a concrete signaling protocol (well, not exactly as
it uses pure SIP, but on top of WebSocket). Of course it aim is to be
used with rtcweb for media sessions.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 6 Oct 2011 00:06:30 +0530

Hi Ted,

Thanks for providing the opportunity to present my draft.

The main advantage of having standard signaling protocol are

1)      Easy RTCWeb app development by non-real-time Web developer.

2)      Better performance compare to JS based signaling

Sec 3 (Issues without RTCWeb standard signaling protocol) and Sec 4
(Standard RTCWeb signaling protocol advantages) are added to explain the
need for standard signaling protocol. My intention of sec 3 & sec 4 to
indicate that the weakness of "nothing" as a protocol and also to
indicate standard signaling protocol does not stop custom made signaling
protocol.  I understand from the review comments that the text in these
section has to be revised for clarity . Also few points which I received
as part of the draft review comment has to be added. Please let me know
in case you wish to see any specific point in these sections. 

I completely understand the "time to market" need for the RTCWeb
specification and also "n" of difference of opinion starting from
"nothing" to n number of variant of "standard signaling protocol". I
have mentioned the list of existing signaling protocol  in sec 6 to
select by which the time to develop the signaling protocol will be
avoided and also most of the existing protocol would have matured by
now. Also, I have added sec 5 of the draft to provide the strong
technical requirement of RTCWeb signaling which helps to select the
protocol in sec 6. Please let me know in case more concrete way to solve
this issue.

Thanks

Partha

From: Ted Hardie [mailto:[email-masked]] 
Sent: Wednesday, October 05, 2011 10:15 PM
To: Ravindran Parthasarathi
Cc: [email-masked]
Subject: Re: [rtcweb] Making progress on the signaling discussion (NB:
Actionitems enclosed!)

Hi Partha,

We'd be happy to consider a signaling protocol proposal from you.
Unfortunately, the current iteration of your draft does not contain a
concrete proposal so much as a discussion of the advantages of a
standardized signaling protocol.   To make further progress, the chairs
believe we need concrete proposals at this time.  Please let us know if
you would like to provide an update with a concrete proposal.

thanks,

Ted

On Wed, Oct 5, 2011 at 12:03 AM, Ravindran Parthasarathi
<[email-masked]> wrote:

Ted, Magnus, Cullen,

Thanks
Partha

thanks,

Ted, Magnus, Cullen

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 6 Oct 2011 10:21:27 +0200

> used with rtcweb for media sessions.

Iñaki,

could you please clarify your intention of your proposal?

My interpretation of your draft is that it is a description of how you
can deploy SIP implemented in JS over websocket. Thus enabling SIP
interworking when needed by having the JS SIP stack convert regular SIP
with SDP into interactions with the WEBRTC API. Thus your proposal
really is primarily an argument that you don't need SIP implemented in
the browser, as long as the API allows the JS to create SIP with SDP
messages. Thus I would interpret this as something that could work both
over something similar to the current PeerConnection API proposals and a
more low level API. Where PeerConnection likely is less work as it does
provide the SDP that in most cases don't need modifications.

Is this a correct interpretation and thus your draft is an extension
that simplifies life for the people who like SIP interworking by getting
the SIP functionality into the end-point rather than a gateway?

Or is it something else?

If it is the first I don't see your proposal as complete proposal for
how signaling for RTCWEB, as you still need APIs to something in some
form and with possibly certain semantics that interact with the SIP in
JS implementation.

To clarify, what I see the question for the WG is how the signalling
model for RTCWEB session establishment is intended to work. Thus the
drafts intended for answering this needs to be focused on describing a
signalling model.

Cheers

Magnus Westerlund

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 7 Oct 2011 03:57:30 +0200

2011/10/6 Magnus Westerlund <[email-masked]>:
> can deploy SIP implemented in JS over websocket.

Yes.

> Thus enabling SIP
> with SDP into interactions with the WEBRTC API.

Yes.

> Thus your proposal
> the browser,

Of course, I don't want a SIP native stack in the browser, never.

> as long as the API allows the JS to create SIP with SDP
> messages.

Not exactly. We generate the SIP messages in JS (without using a
RTCweb API at all). We just need a RTCweb API to create a SDP object
(maybe a JS object) so then I can generate the plain SDP using
JavaScript (and XMPP/Jingle folks would generate a XML SDP).
And we just need some way to tell the RTCweb stack from JS: "hey, I've
received this SDP and I need you to tell me what do you think about
it, parse it please, or ask me to previously convert it into a
specific JS object and then I pass it to you".

> Thus I would interpret this as something that could work both

Right. But this could occur regardless the signaling protocol chosen
by each web application. At the end, Alice will receive (via
HTTP/WebSocket) something like a SDP from Bob, and Alice must deal
with that with the help of a JS RTCweb API.

> the SIP functionality into the end-point rather than a gateway?

Sure :)

> Or is it something else?

No, it's exactly that.

> form and with possibly certain semantics that interact with the SIP in

You are right. It's just a signaling proposal (not to make a standard
signaling, not at all, but just a signaling example, in this case pure
SIP).

> drafts intended for answering this needs to be focused on describing a

Yes, agreed.

Regards.

PS: SIP over WebSocket just works fine. A demonstration next week.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 7 Oct 2011 16:14:16 -0600

Hi Ted, 

I do plan to submit a signaling draft before next friday. The draft will based on figuring out what the minimal thing is we need to have wrapped around SDP to be able to implement offer/answer in a way that meets our uses cases. 

Cullen

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 11 Oct 2011 10:37:20 +0200

> PS: SIP over WebSocket just works fine. A demonstration next week.

Hi, as told in other thread, the demonstration and video of SIP over
WebSocket is already available:

  http://sip-on-the-web.aliax.net/

So this becomes a signaling protocol example for RTCweb, a *known*
signaling protocol in fact (so we can figure what we need from the
future RTCweb JS API in order to deal with SDP's and media sessions).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 12 Oct 2011 11:01:41 +0200

On 10/11/11 10:37, Iñaki Baz Castillo wrote:
> 2011/10/7 Iñaki Baz Castillo<[email-masked]>:
the video has a caveat of course:

we don't know that the signalling can be successfully connected to the 
browser's API, because there's no API to connect to yet.

One of the worries I have with doing a "low level spec" unconstrained by 
our present competence (ignorance?) in  is that I'm reasonably sure we 
have the knowledge to generate and parse SDP, because the codebases we 
are building on already generate and parse SDP, and the information 
present there is enough to set up calls, because we're already setting 
up calls using that information.

I'm less sure of our "getting things right" if we start off by 
describing the capabilities and control knobs to be exposed in an 
unconstrained API.

                    Harald

---

From: Neil Stratford <[email-masked]>
Date: Wed, 12 Oct 2011 10:46:22 +0100

On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand <[email-masked]>wrote

> our present competence (ignorance?) in  is that I'm reasonably sure we have
> the knowledge to generate and parse SDP, because the codebases we are
> building on already generate and parse SDP, and the information present
> there is enough to set up calls, because we're already setting up calls
> using that information.
>
> I'm less sure of our "getting things right" if we start off by describing
> the capabilities and control knobs to be exposed in an unconstrained API.

As a counter argument, those very same codebases that generate and parse SDP
also contain internal APIs that look a lot like a low level spec API, and
the information they present is enough to generate and parse SDP and set up
calls.

Maybe we don't like those APIs and perhaps they expose too much as they were
never intended to be made public, but they do exist already.

Neil

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 12 Oct 2011 12:00:06 +0200

On 10/12/11 11:46, Neil Stratford wrote:
> On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand 
> <[email-masked] <mailto:[email-masked]>> wrote
>
>     One of the worries I have with doing a "low level spec"
>     unconstrained by our present competence (ignorance?) in  is that
>     I'm reasonably sure we have the knowledge to generate and parse
>     SDP, because the codebases we are building on already generate and
>     parse SDP, and the information present there is enough to set up
>     calls, because we're already setting up calls using that information.
>
> As a counter argument, those very same codebases that generate and 
> parse SDP also contain internal APIs that look a lot like a low level 
> spec API, and the information they present is enough to generate and 
> parse SDP and set up calls.
>
> Maybe we don't like those APIs and perhaps they expose too much as 
> they were never intended to be made public, but they do exist already.
Yup. And I suspect they're all subtly different.

---

From: Tim Panton <[email-masked]>
Date: Wed, 12 Oct 2011 11:31:14 +0100

On 12 Oct 2011, at 11:00, Harald Alvestrand wrote:

>> On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand <[email-masked]> wrote
>> One of the worries I have with doing a "low level spec" unconstrained by our present competence (ignorance?) in  is that I'm reasonably sure we have the knowledge to generate and parse SDP, because the codebases we are building on already generate and parse SDP, and the information present there is enough to set up calls, because we're already setting up calls using that information.
>> 
>> I'm less sure of our "getting things right" if we start off by describing the capabilities and control knobs to be exposed in an unconstrained API.
>> 
>> As a counter argument, those very same codebases that generate and parse SDP also contain internal APIs that look a lot like a low level spec API, and the information they present is enough to generate and parse SDP and set up calls.
>> 
>> Maybe we don't like those APIs and perhaps they expose too much as they were never intended to be made public, but they do exist already.

You could look at that in a positive light - 
as evidence that there are multiple ways to solve this problem and deduce:
	a) it isn't impossibly hard
	b) there isn't one 'correct' way of doing it.

Which would lead me back to specifying as _little_ as possible and letting innovation take place.

Tim

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 12 Oct 2011 13:39:01 +0200

On 10/12/11 12:31, Tim Panton wrote:
>>>     SDP, because the codebases we are building on already generate
>>>     and parse SDP, and the information present there is enough to
>>>     set up calls, because we're already setting up calls using that
>>>     information.
>>>
>>>     describing the capabilities and control knobs to be exposed in
>>>     an unconstrained API.
>>>
>>>
>>> parse SDP also contain internal APIs that look a lot like a low 
>>> level spec API, and the information they present is enough to 
>>> generate and parse SDP and set up calls.
>>>
We have to specify enough for interoperation in at least the use cases 
of the scenarios document.
In enough detail for interoperation to happen.

That could turn out to be a lot, especially if we can't point to 
existing specs and say "use that".

               Harald

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 12 Oct 2011 08:00:23 -0400

On 10/12/11 5:01 AM, Harald Alvestrand wrote:
> ...
> One of the worries I have with doing a "low level spec" unconstrained 
> by our present competence (ignorance?) in  is that I'm reasonably sure 
> we have the knowledge to generate and parse SDP, because the codebases 
> we are building on already generate and parse SDP, and the information 

And yet those aforementioned codebases generate and parse SDP, and set 
up calls, using an API underneath them which is obviously capable 
(existence proof), even though it wasn't designed this way.

Just like you can build a SIP/SDP softphone using the Win32 APIs, even 
though Win32's API design didn't take SIP or SDP into account when it 
was being specified.

> describing the capabilities and control knobs to be exposed in an 

I am absolutely certain we can build whatever we want, including SIP or 
SDP compatibility, if we make the API low enough level that *anything* 
can be built.

And I believe that once we get to this level, we've made the browser the 
new operating system and a platform for future innovation... instead of 
locking developers in to a single way of solving things by putting an 
entire softphone in there.

Matthew Kaufman

---

From: Tim Panton <[email-masked]>
Date: Wed, 12 Oct 2011 13:13:31 +0100

On 12 Oct 2011, at 12:39, Harald Alvestrand wrote:

> We have to specify enough for interoperation in at least the use cases of the scenarios document.
> That could turn out to be a lot, especially if we can't point to existing specs and say "use that".

So, to paraphrase (and make sure I understand) - your argument is that if we don't use SDP,
we will have to specify all the fields and associated meanings for every codec we expect to support.

If we do use SDP, then we just point at existing usage and say - 'there, use that' .

If we use a subset or variant on SDP we can say - 'use that, except for this bit to do with port allocation'.

Is that a fair (if informal) summary?

Tim.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 12 Oct 2011 14:17:58 +0200

> entire softphone in there.

I think that the current API proposal (dealing with MediaStreams and 
tracks thereof) leaves quite much room for innovation and is far from 
"an entire softphone" approach.

---

From: Tim Panton <[email-masked]>
Date: Wed, 12 Oct 2011 13:36:42 +0100

On 12 Oct 2011, at 13:25, Harald Alvestrand wrote:

> On 10/12/11 14:13, Tim Panton wrote:
>> 
>> 
> Yes, exactly.
> We've been around this bush a few times under the guise of "why don't we redefine SDP in JSON" or "why don't we redefine SDP in XML"; this time, it somewhat resembles "why don't we reencode SDP as API calls". I believe a lot of the same arguments apply.
> 

Lets assume we use a subset/variant of SDP as a codec capability description 'language' - (i.e. we won't be using the parts that relate to network properties).

The question then becomes: 'Is current SDP usage so idiosyncratic that it is difficult/impossible to describe a mapping to/from (say) a set of javascript objects which would work for all existing and future codecs that play by the current rules?' 

Tim.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 12 Oct 2011 14:25:03 +0200

On 10/12/11 14:13, Tim Panton wrote:
>>>>>     unconstrained by our present competence (ignorance?) in  is
>>>>>     that I'm reasonably sure we have the knowledge to generate and
>>>>>     parse SDP, because the codebases we are building on already
>>>>>     generate and parse SDP, and the information present there is
>>>>>     enough to set up calls, because we're already setting up calls
>>>>>     using that information.
>>>>>
> If we use a subset or variant on SDP we can say - 'use that, except 
> for this bit to do with port allocation'.
>
Yes, exactly.

We've been around this bush a few times under the guise of "why don't we 
redefine SDP in JSON" or "why don't we redefine SDP in XML"; this time, 
it somewhat resembles "why don't we reencode SDP as API calls". I 
believe a lot of the same arguments apply.

---

From: Neil Stratford <[email-masked]>
Date: Wed, 12 Oct 2011 13:22:52 +0100

> Is that a fair (if informal) summary?

It's interesting to look at how XMPP/Jingle addressed this concern in
XEP-0167:
http://xmpp.org/extensions/xep-0167.html#sdp

The SDP definitions are mapped to name/value pairs where possible according
to defined rules.

Neil

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 12 Oct 2011 14:42:17 +0200

On 10/12/11 14:36, Tim Panton wrote:
>
>
>>
>
> Lets assume we use a subset/variant of SDP as a codec capability 
> description 'language' - (i.e. we won't be using the parts that relate 
> to network properties).
(note - I'm not making that assumption)
>
> The question then becomes: 'Is current SDP usage so idiosyncratic that 
> it is difficult/impossible to describe a mapping to/from (say) a set 
> of javascript objects which would work for all existing and future 
> codecs that play by the current rules?'
>
The problem I see there is "future codecs".

Anyone who specifies anything that they know has to be handled in SIP 
for some reason tend to specify their mapping to SIP in great detail, 
but not necessarily with a great deal of formality.

I couldn't say offhand what the "current rules" are. That makes it hard 
to make a parser/generator that is guaranteed to handle all valid examples.

             Harald

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 12 Oct 2011 06:59:36 -0700

> description 'language' - (i.e. we won't be using the parts that relate

I've seen this proposed a couple of times now, and I would like to point 
out that this is a terrible assumption. There are many things that one 
might want to control about a codec that will never show up in SDP, 
because they don't require explicit negotiation between sender and 
receiver (e.g., the sender gets to make a unilateral decision and the 
receiver simply deals with it... like, say, the amount of time a video 
encoder is willing to spend doing a motion search, etc.).

Limiting yourself to the parameters that do happen to show up in SDP is 
a pretty poor half-solution, if you really do think you need a low-level 
API of this kind, and may not have obvious extension points to get to a 
full solution.

---

From: Tim Panton <[email-masked]>
Date: Wed, 12 Oct 2011 15:58:11 +0100

On 12 Oct 2011, at 14:59, Timothy B. Terriberry wrote:

> I've seen this proposed a couple of times now, and I would like to point out that this is a terrible assumption. There are many things that one might want to control about a codec that will never show up in SDP, because they don't require explicit negotiation between sender and receiver (e.g., the sender gets to make a unilateral decision and the receiver simply deals with it... like, say, the amount of time a video encoder is willing to spend doing a motion search, etc.).
> 
> Limiting yourself to the parameters that do happen to show up in SDP is a pretty poor half-solution, if you really do think you need a low-level API of this kind, and may not have obvious extension points to get to a full solution.

Which leaves us with the choice of:
	a) having 2 different APIs - one for SDP params and one for everything else
	b) extending SDP to include things that will only be used locally 
	c) describing a mapping from SDP to javascript objects for a 'full' codec description object
	d) ?

Tim (P).

---

From: Roman Shpount <[email-masked]>
Date: Wed, 12 Oct 2011 12:49:00 -0400

As far as I can see from this discussion there are several different items
for consensus:

1. The API level: I think most of the people on the list agree that API
should deal with media streams and media stream descriptions, i.e. should be
as low level as possible without implementing actual RTP. There are few
people here who argue for a higher level API that would allow to setup
connection using some sort of higher level signalling protocol which will
deal with individual stream setup in a manner transparent to a developer,
but from what a lot of people on the list (including me) believe this can be
implemented in JavaScript and does not need to be standardized.

2. API Semantics: I would say that API should be complete enough to
implement everything that is currently supported by Offer/Answer and SIP
signalling. It does not have to be offer/answer and can allow for new
negotiation scenarios, but all the current scenarios, including forking,
remote target SDP updates should be supported. I think RTC should provide a
framework that would allow to implement all the current VoIP offer/answer
negotiation flows. I don't think that we can ignore some of those flows even
though some of the people on the list argue against it saying that this
flows are specific for PSTN, or caused by SIP design flaw, or some other
corner case of exiting offer/answer model.

3. Signaling Offer and Answer Format: Some people argue for direct use of
SDP. Others argue for using JavaScript object or set of API methods to
define the same. The main argument for using JavaScipt object/API methods
would be that it will make it easier to manipulate session description from
JavaScript. The main argument for using SDP is simpler interoperability with
existing VoIP solutions. I would strongly argue for JavaScipt object/API
primarily based on the fact that SDP is not enough to fully define the media
parameters. Typically all the non-negotiated media stream parameters in VoIP
solutions are defined from device configuration. We will need an API convey
those preferences to RTC implementation which means a set of custom APIs on
top of SDP. If we are doing custom APIs for media, we might as well make one
that covers all the features.

This being said, I would also argue that we need to have an API that can be
used with new codecs implemented by the browser without explicitly extending
the JavaScript signaling code. The current proposed API assumes that
JavaScript code understands the meaning of all the codec parameters to
negotiate them on behalf of the user. If new codec is added, JavaScript
would need to be updated to correctly select the parameters for new codec.
We should provide a programming model where it is possible to delegate the
codec selection and codec parameter negotiation to the RTC API while still
allowing to do this negotiation from JavaScript.

P.S. I do find the current API proposal a bit deficient due to its inability
to support forking, asymmetric codec selection, and delegating codec
negotiation to the RTC implementation.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 12 Oct 2011 18:56:13 +0200

> negotiation to the RTC implementation.

Perhaps I miss something but... which "current API" do you mean?

Thanks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 12 Oct 2011 13:03:46 -0400

> Perhaps I miss something but... which "current API" do you mean?
I've meant "Architecture and API for RTCWeb" from Neil Stratford:
https://docs.google.com/document/pub?id=1MfrFHKx6O6yWtIv_jqwyH-RAbm8AgRtXQ7dJTZz5J2g&pli=1and
draft-jennings-rtcweb-api-00. There might be something that I've
missed
while reading those documents but I could not figure out how to implement
any of the features that I've listed.

_____________
Roman Shpount

---

From: Randell Jesup <[email-masked]>
Date: Wed, 12 Oct 2011 18:12:44 -0400

> API of this kind, and may not have obvious extension points to get to a

Typically the SDP O-A specifies what you want to receive, and indirectly 
(mostly) what you want to send.  This leaves lots of choices about how 
to achieve that (especially for encoding) up to the application logic at 
either end, once the negotiation is complete.  (As Tim points out.)  The 
"simple" solution would be to embed that application logic in the 
browser code, and feed it the SDP (or equivalent).

We have a more complex case here, where we have the app which may have 
something to say about those choices, or want to vary things during a 
call, etc.  We also have a wider problem space than "video calling"; so 
there may be valid reasons for the app to want different behavior from 
the codecs.

With SDP completely generated by and processed the browser, new video 
codec support is straightforward, which is a good thing.  However, this 
means that the app has more complexity in modifying or controlling the 
negotiation and the way the codecs operate (the "application logic" above).

The problem with providing the app full access to the codec controls and 
negotiation is that it's a severely open-ended problem, and each codec 
is different, with different knobs.  Effectively the app would likely 
support only one or only the original "standard" codecs; existing apps 
wouldn't use (or might break) "new" codecs.

One end of the spectrum effectively gives JS full control of every knob 
in the codec API, which is totally different from one codec to the next. 
  The other end is where you abstract out "common" codec parameters into 
generic values/sliders (image quality vs motion representation, quality 
versus efficiency/frame-rate, etc), which may or may not be handled for 
a given codec (or you punt and give the app no control of these things). 
  Note that the knobs for the same codec (H.264, VP8, Opus, etc) might 
be different in different browsers, because the underlying 
implementation is different.

The downside of the generic approach is that many codec-specific things 
won't be possible to modify, or doing so will be very indirect and might 
have side-effects.

Once again the basic tension between ease-of-use and 
give-me-control-damn-it is a primary factor here.  An added factor here 
is that in the complex model, if a codec is added by the browser, the 
app may not be able to use it (or able to use it above a basic, 
automatic level) without being updated.  You could write an 
codec-interface abstraction JS that isolated the main app from the codec 
complexity (taking the place of the aforementioned sliders, etc), but 
then that has to be updated, which is largely the same problem 
(especially given security concerns).

However, in my mind the more critical issue is ease-of-use (and also 
inter-browser compatibility - two encoders for the same codec may have 
very different knobs at a low level).  Most users of WebRTC won't be 
interested in tweaking the IDR quantization levels; they are more likely 
to be interested in the overall quality/speed/efficiency/frame-rate sort 
of tradeoffs.  Some users may want to tweak each and every parameter and 
buy into updating that code for new codecs (and for new parameters in 
existing codecs).

I'm more than half-tempted to not provide any interface to the codec 
parameters initially, or a very general one (but extensible for future 
use) just covering the most basic tradeoffs only.  Much more than 
half-tempted.

I would in general allow for these parameters to be tweaked during a 
call by the app, though this opens the question about if tweaking them 
can require a re-negotiation of the call.

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Wed, 12 Oct 2011 18:21:07 -0400

[not responding to the other items mentioned in this post; perhaps later]

On 10/12/2011 12:49 PM, Roman Shpount wrote:
> This being said, I would also argue that we need to have an API that can
> be used with new codecs implemented by the browser without explicitly
> extending the JavaScript signaling code. The current proposed API
> assumes that JavaScript code understands the meaning of all the codec
> parameters to negotiate them on behalf of the user. If new codec is
> added, JavaScript would need to be updated to correctly select the
> parameters for new codec. We should provide a programming model where it
> is possible to delegate the codec selection and codec parameter
> negotiation to the RTC API while still allowing to do this negotiation
> from JavaScript.

Agreed, I think.

> P.S. I do find the current API proposal a bit deficient due to its
> inability to support forking, asymmetric codec selection, and delegating
> codec negotiation to the RTC implementation.

See my much earlier discussion of Forking support by modifying Harald's 
OFFER/ANSWER messages to include ACCEPT, which also helps solve the 
answer-time clipping issues.

(I'll try to dig it out of the archives and repost a link.)

-- 
Randell Jesup
[email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Wed, 12 Oct 2011 18:49:04 -0400

> (I'll try to dig it out of the archives and repost a link.)

I do remember your proposal, and it does address the situation where
JavaScript would need to update the remote target. I am not sure it covers
the case where multiple streams need to be created based on several answers
to the same offer (flow that corresponds to multiple 200 OK responses to a
single INVITE). I don't think it would be very difficult to implement
disambiguation of multiple remote media sources based on remote IP and allow
JavaScript to manage each stream separately. I would suggest some sort of
CLONE API, taking the remote description and creating a new stream, for this
purpose.
_____________
Roman Shpount

---

From: Randell Jesup <[email-masked]>
Date: Thu, 13 Oct 2011 00:29:28 -0400

On 10/12/2011 6:49 PM, Roman Shpount wrote:
>
>
> On Wed, Oct 12, 2011 at 6:21 PM, Randell Jesup <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     See my much earlier discussion of Forking support by modifying
>     Harald's OFFER/ANSWER messages to include ACCEPT, which also helps
>     solve the answer-time clipping issues.
>
> JavaScript would need to update the remote target. I am not sure it
> covers the case where multiple streams need to be created based on
> several answers to the same offer (flow that corresponds to multiple 200
> OK responses to a single INVITE).

It did cover that case - it was up to the app what to do when the first 
ACCEPT was processed.  I didn't go into the JS-level mechanisms used.

> I don't think it would be very
> difficult to implement disambiguation of multiple remote media sources
> based on remote IP and allow JavaScript to manage each stream
> separately.

Do not assume that remote IP == source - this is easily provably false, 
though if you used remote IP+port AND local IP+port I think it would be 
ok.  However, for each remote connection we should have a DTLS 
connection instance, so that's probably simplest.

> I would suggest some sort of CLONE API, taking the remote
> description and creating a new stream, for this purpose.

Quite possibly this is really a W3C area...  though they're all 
interrelated.

-- 
Randell Jesup
[email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Thu, 13 Oct 2011 00:48:22 -0400

> ACCEPT was processed.  I didn't go into the JS-level mechanisms used.

I guess I might be missing something, but how, using ACCEPT, RTC can
generate a single offer, get two answers back, and create two media streams?
Creating a second media stream does not mean that this is a last answer for
this stream (corresponds to new SIP dialog created by provisional response)
and accepting a stream does not mean it cannot be cloned (corresponds to new
SIP dialog created by new final response). So essentially we need four
operations: create offer, create media stream based on an answer, update
existing stream based on a new answer for the same dialog, and finalize the
media stream. Or alternatively we can achieve the same with create offer and
stream together, process answer, accept (finalize the stream) and clone the
stream. Either way we need four methods and we achieve the same
functionality.

> though if you used remote IP+port AND local IP+port I think it would be ok.
>  However, for each remote connection we should have a DTLS connection
> instance, so that's probably simplest.
>

Yes, I do agree we should disambiguate on local/remote IP+port pair. I did
not realize we are requiring DTLS/SRTP in RTC. I don't think I've seen a
single implementation of this in the wild, and I do not see any harm in
supporting SRTP and (with user confirmation) of plain RTP.
_____________
Roman Shpount

---

From: Randell Jesup <[email-masked]>
Date: Thu, 13 Oct 2011 01:03:40 -0400

On 10/13/2011 12:48 AM, Roman Shpount wrote:
>
> On Thu, Oct 13, 2011 at 12:29 AM, Randell Jesup <[email-masked]
>     It did cover that case - it was up to the app what to do when the
>     first ACCEPT was processed.  I didn't go into the JS-level
>     mechanisms used.
>
>
> generate a single offer, get two answers back, and create two media
> streams? Creating a second media stream does not mean that this is a
> last answer for this stream (corresponds to new SIP dialog created by
> provisional response) and accepting a stream does not mean it cannot be
> cloned (corresponds to new SIP dialog created by new final response). So
> essentially we need four operations: create offer, create media stream
> based on an answer, update existing stream based on a new answer for the
> same dialog, and finalize the media stream. Or alternatively we can
> achieve the same with create offer and stream together, process answer,
> accept (finalize the stream) and clone the stream. Either way we need
> four methods and we achieve the same functionality.

I'm not sure we're actually disagreeing here - I'll dig out my original 
message.

>     Do not assume that remote IP == source - this is easily provably
>     false, though if you used remote IP+port AND local IP+port I think
>     it would be ok.  However, for each remote connection we should have
>     a DTLS connection instance, so that's probably simplest.
>
>
> Yes, I do agree we should disambiguate on local/remote IP+port pair. I
> did not realize we are requiring DTLS/SRTP in RTC. I don't think I've
> seen a single implementation of this in the wild, and I do not see any
> harm in supporting SRTP and (with user confirmation) of plain RTP.

Yes, allowing any non-encrypted connection is controversial currently. 
DTLS for the PeerConnection and any data channels, and DTLS-SRTP for the 
media channels.  See ekr's security spec.  As for implementations, that 
should not be a problem.  Plain SRTP with SDES I consider more 
problematic, since it inherently exposes the keys to the un-trusted app 
and server.

-- 
Randell Jesup
[email-masked]