Subject: [rtcweb] Current state of signaling discussion

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Oct 2011 14:55:22 +0200

WG,

This is an attempt of me as WG chair to try to summarize the state of
the discussion as it was when I wrote this. As usual please speak up
against any miss-characterization of the state from my side.

The Chairs request for identifying who like to provide input for a
signaling discussion two weeks and to follow up this with a Internet
draft has resulted in that we now have two drafts.

a) RTCWeb Offer/Answer Protocol (ROAP)
https://datatracker.ietf.org/doc/draft-jennings-rtcweb-signaling/

b) RTCWeb standard signaling protocol
https://datatracker.ietf.org/doc/draft-partha-rtcweb-signaling/

We also have a third proposal that want to be included in the
considerations:
c) RTCWEB does not define any signaling behavior at all, instead W3C is
tasked to develop an API that allows the application to establish the
media session between peers.

I have as WG chair requested that the proponents for C to produce a
Internet draft that provides requirements on the API and its capability.
This is to ensure that this proposal can be properly evaluated. So far
no such contribution has occurred. Without a willingness from the
proponents of this style of solution to contribute and evolve their
thinking in such way that the other WG members can gain a better
understanding of the implications of this solution I find it difficult
for us include it in the up coming consensus call.

We intended to have a phone conference on Friday to enable some direct
discussion on the topic of signaling between the WG members. Details to
follow. This is not an interim, only a possibility for the WG members to
further their understanding in preparation for the decision.

In addition to signaling proposals the WG have received two other I-Ds.

1) Real-Time Web Communication Simplified Interconnection
https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/

Which I interpret as a discussion piece around the federation and
interconnect usages.

2) WebSocket Transport for Session Initiation Protocol (SIP)
https://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/

This is a demonstration that SIP could be implemented in Java script and
be transported over web-socket to enable the cases where SIP want to be
used between a browser instance and a SIP system and its user agents.
This has some requirements on the API to either provide SDP in O/A style
or something that enables the SIP stack to create SIP messages with SDP
O/A messages.

There has been lively discussion around these documents which I hope
continues but it does need to come to some conclusions.

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: Tue, 18 Oct 2011 15:27:43 +0200

> continues but it does need to come to some conclusions.

Hi Magnus. My concerns:

- I don't like option B (defining a default signaling protocol) as it
stops innovation (we will be limited and constrained to the
limitations of such protocol, and will depend on how good each browser
implements it). Upgrading the signaling stack would require a new
version of every browsers in the world. Unfeasible IMHO.

- Initially I advocated for option C, but such option is so flexible
that I cannot imagine how a draft can describe it. But a real example
of such a custom signaling protocol is present in
https://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/.

- I don't think that options C and A (ROAP) are mutually exclusive,
not at all. IMHO ROAP defines a communication between the JS code and
the browser RTCweb stack, just it. It does not define a signaling
protocol on-the-wire (but just gives some guidelines which are present
in any existing VoIP protocol). For example a JS code could use SIP
over WebSocket for the wire communication and generate ROAP "objects"
upon receipt of a INVITE/200 with SDP prior to talk with the browser
RTCweb stack.

- ROAP defines itself as a "protocol" because indeed it contains
states, so it's not an API (or it's more than just an API), but it
just covers the communication between the JS code and the browser
RTCweb stack, leaving the door open to any custom signaling protocol
on the wire. So IMHO this is the way to go.

About SDP or media info management there is an open debate about the
responsability (or not) of the JS code in doing such task. My opinion
is that, given that RTCweb is based on SDP:

- RTCweb should define a specific (JSON) format that includes SDP
information in some structured way. It does not need to be a SDP 1:1
mapping. Let's call it RTCweb.MediaInfo JSON object.

- Since interoperability with SIP and XMPP/Jingle is desired (is
not?), RTCweb JS API should include some helper functions:

  - RTCweb.parsePlainSDP(string)
      Receives as argument a string containing a plain SDP body and returns a
      RTCweb.MediaInfo object.

  - RTCweb.parseXmlSDP(string)
      Receives as argument a string containing a XML SDP body (Jingle)
and returns a
      RTCweb.MediaInfo object.

  - RTCweb.generatePlainSDP(mediaInfo)
      Receives as argument a RTCweb.MediaInfo object and generates a
plain SDP string.

  - RTCweb.generateXmlSDP(mediaInfo)
      Receives as argument a RTCweb.MediaInfo object and generates a
XML SDP string.

- Custom signaling protocols not using SIP or XMPP would not need such
helpers and could directly work with the MediaInfo JSON structure (by
also passing it verbatim on-the-wire).

So my proposal is using ROAP but, instead of inserting a plain SDP
string within the ROAP Offer and Answer structures, inserting a
RTCweb.MediaInfo JSON object. In this way, there is no need for the
JavaScript code for dealing with plain SDP's.

Regards.

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Oct 2011 13:34:48 +0000

> for us include it in the up coming consensus call.

That was not my understanding of what you (the WG Chairs) were asking for.  The email from Ted asking for drafts was this:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01761.html

My reading of that is it was asking for a concrete solution in the signaling solutions discussion.  For those of us who feel there needs to be *no* standard-defined signaling, it was asking us for the empty set.  We delivered.  :)

Now it sounds like you're asking for something different: requirements for the (W3C-defined) API.  I had assumed that's what draft-ietf-rtcweb-use-cases-and-requirements was supposed to cover. No?

-hadriel

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Oct 2011 15:57:04 +0200

On 2011-10-18 15:34, Hadriel Kaplan wrote:
>> considerations: c) RTCWEB does not define any signaling behavior at
>> all, instead W3C is tasked to develop an API that allows the
>> application to establish the media session between peers.
>> 
>> I have as WG chair requested that the proponents for C to produce
>> a Internet draft that provides requirements on the API and its
>> capability. This is to ensure that this proposal can be properly
>> evaluated. So far no such contribution has occurred. Without a
>> willingness from the proponents of this style of solution to
>> contribute and evolve their thinking in such way that the other WG
>> members can gain a better understanding of the implications of this
>> solution I find it difficult for us include it in the up coming
>> consensus call.
> 
> That was not my understanding of what you (the WG Chairs) were asking
> for.  The email from Ted asking for drafts was this: 
> My reading of that is it was asking for a concrete solution in the
> signaling solutions discussion.  For those of us who feel there needs
> to be *no* standard-defined signaling, it was asking us for the empty
> set.  We delivered.  :)
> 

In the following message I included my clarified request on that there
is still need to have an I-D on the "no signalling" proposal:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg01794.html

> Now it sounds like you're asking for something different:
> requirements for the (W3C-defined) API.  I had assumed that's what
> draft-ietf-rtcweb-use-cases-and-requirements was supposed to cover.
> No?

No, that is the general use cases for the complete solution. What I am
asking is for something that makes it clear what the API need to contain
to initiate and configure ICE negotiation, media transport etc.

Saying we don't need no protocol is not sufficient. It doesn't make it
clear what it actually means to have no standardized protocol and the
implications this have on what the API needs to expose.

What we are trying to accomplish is that we go from general hand waving
on the different approaches to something that is reasonably well
explained. Thus enabling everyone to better understand the proposals.

Cheers

Magnus Westerlund

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Oct 2011 14:12:37 +0000

> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01794.html

Ahhh.  Sorry I did not see that email. (I don't know how I could have missed an email in such a low-volume mailing list ;)

OK, I'll try and submit one before Friday if no one else is going to.

-hadriel

---

From: <[email-masked]>
Date: Tue, 18 Oct 2011 17:47:46 +0200

is such a draft. I missed the 7. October dead-line to announce it, but submitted it the 14th.
It proposes an interconnection model that does not require standardized signalling.

Wolfgang Beck

Deutsche Telekom Netzproduktion GmbH
Fixed Mobile Engineering Deutschland
Wolfgang Beck
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 628 2832 (Tel.)
http://www.telekom.de

Erleben, was verbindet.

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft Bonn
USt-IdNr. DE 814645262

Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Hadriel Kaplan
Gesendet: Dienstag, 18. Oktober 2011 16:13
An: Magnus Westerlund
Cc: [email-masked]
Betreff: Re: [rtcweb] Current state of signaling discussion

-hadriel

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Oct 2011 20:30:08 +0000

Dear Chairs,
I have a question of clarification on your request for "signaling" proposals/drafts.
Which *type* of "signaling" do you mean?  What purpose/problem-solution are these candidate drafts meant to address?

In the email below, you indicate draft-jennings-rtcweb-signaling is one of the drafts that provides a solution, but as far as I can tell it is not a session signaling protocol; it is just a protocol for SDP offer/answer.  It is not a sufficient solution for sessions, and it admits that within its own text.  It would not, for example, let one write a RTCWeb-based communication application in "20 lines of code".

So are you only talking about how to handle media-plane setup between two Browsers? (ie codec negotiation, ICE, etc.)  OR do you mean the whole shebang?

There have been a lot emails floating around the past few days so if I've missed the relevant clarification please excuse the question. (but direct me to the answer :)

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Oct 2011 13:50:01 -0700

> In the email below, you indicate draft-jennings-rtcweb-signaling is one of the drafts that provides a solution, but as far as I can tell it is not a session signaling protocol; it is just a protoco…

Is this actually correct? The introduction of that draft suggests otherwise:

"The protocol is designed to operate between two entities (browsers
for example), which exchange messages "directly" - meaning that a
message output by one entity is meant to be directly processed by the
other entity without further modification. In practice, this means
that a web server can treat ROAP messages as opaque and just shuffle
them between browser instances. This allows for simple
implementations."

If we take the PeerConnection API as our point of reference, isn't the
idea here that
you would instantiate callbacks that take messages coming out of the
PeerConnection
API and push them to the Web server and messages coming from the Web server
and push them to the PeerConnection instance. I don't know if this is 20 lines
of code (though with JS minimization it might be one line of code :)),
but it does
seem comparatively trivial...

-Ekr

-Ekr

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Oct 2011 21:05:03 +0000

In the abstract it states:
"The protocol focuses solely on media negotiation and does not handle call control, call processing, or other functions."

Ignoring esoteric stuff like session transfer, forwarding, etc. (ie, ignoring "phone" stuff) is fine.

BUT, for an actual session protocol to work for even a gaming app, you need to do the following:
1) determine a target for the ROAP message (ie, who's this OFFER going to in the end?)
2) define how that target identity is conveyed (ie, how does the web server know which browser to give this ROAP OFFER to?)
3) define a source identity model, possibly with authentication (ie, who are you?)
4) define how the source identity is conveyed (ie, how does the server/far-end-browser know who's calling?)
5) define a end-of-session indication
6) define a keep-alive mechanism, for when the far end goes away silently and (5) doesn't apply

And I've probably missed some other things.

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Oct 2011 14:18:47 -0700

> 4) define how the source identity is conveyed (ie, how does the server/far-end-browser know who's calling?)

One might already have much of this stuff in your application to support
whatever person-to-person communications (E.g., IM) you already
have. When I heard "20 lines of code" I always assumed that it excluded that
sort of routing-type stuff.

> 6) define a keep-alive mechanism, for when the far end goes away silently and (5) doesn't apply

Do these involve a lot of code?

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Oct 2011 23:41:12 +0200

> And I've probably missed some other things.

Hi Hadriel, if ROAP draft specifies all the points above it becomes an
entire signaling protocol, and AFAIK we don't want that. If I use SIP
over WebSocket I just want (and need) to use SIP for signaling. So the
JS client constructs an INVITE which tells the proxy/server who he
claims to be. The proxy (speaking SIP over WebSocket) acts as a normal
SIP proxy for routing requests and responses, requiring
authentication, performing authorization, registration (or routing the
REGISTER to a pure registrar server behind it...).

So I don't see the need for ROAP to become a on-the-wire signaling
protocol. In fact, I don't support that idea.

I'm happy if ROAP just covers the communication between the JS and the
browser RTCweb stack. How the signaling messages (including the SDP or
"like-SDP") are carried on the wire should be out of the scope of ROAP
(the draft already is defined for being singaling protocol agnostic).

Regards.

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Oct 2011 21:52:59 +0000

> sort of routing-type stuff.

But that's the point exactly - OF COURSE that type of stuff might already be in your application, and could be conveyed in a URL or all be implicit or whatever.  Or it might not at all be in your app and need to added for this in some way.  

And that's the point many of us have been making: don't define a standard signaling protocol, because it's all application-specific to the web-app, which only the web-app developer would possibly know.

Thus, I'm asking the chairs what they mean when they use the word "signaling".  If they mean session signaling, then ROAP doesn't do it either.  If they only mean media-setup+negotiation signaling, that's a different problem scope. (I think that too is unnecessary, but if you put full SDP offer/answer state in the browser, then it's probably a fait accompli)

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Oct 2011 14:55:50 -0700

> And that's the point many of us have been making: don't define a standard signaling protocol, because it's all application-specific to the web-app, which only the web-app developer would possibly k…

I'm not sure why you're arguing with me. Did I say something different?

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Oct 2011 23:58:47 +0200

2011/10/18 Iñaki Baz Castillo <[email-masked]>:
> entire signaling protocol, and AFAIK we don't want that.

I've understood the motivation of your mail after re-reading it. Of
course you don't want a default signaling protocol :)

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

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 19 Oct 2011 04:42:20 +0530

Hi Hadriel,

As you know in most of the IP real-time signaling protocol (SIP+SDP,
H.323(H.225, H.245), MGCP+SDP), there are two aspects

1) Signaling (SIP, H.225)
2) Media description (SDP offer/answer, H.245)

In case of Websocket or long poll HTTP, these protocol act as signaling
whereas media description is missing. ROAP will fill this signaling
protocol gap for websocket/HTTP.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Hadriel Kaplan
>Sent: Wednesday, October 19, 2011 2:35 AM
>To: Eric Rescorla
>Cc: [email-masked]; [email-masked]
>Subject: Re: [rtcweb] Current state of signaling discussion
>
>
>"The protocol focuses solely on media negotiation and does not handle
>call control, call processing, or other functions."
>
>2) define how that target identity is conveyed (ie, how does the web
>server know which browser to give this ROAP OFFER to?)
>3) define a source identity model, possibly with authentication (ie,
who
>are you?)
>4) define how the source identity is conveyed (ie, how does the
>server/far-end-browser know who's calling?)

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 Oct 2011 16:35:39 -0700

> 6) define a keep-alive mechanism, for when the far end goes away silently and (5) doesn't apply

I've thought a bunch about this - In addition to those, I think we need a way to cache state, sort of like cookie or something. That gets passed back at the right time. That type of thing makes it much easier for the web-service to keep track of things.