Subject: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

From: <[email-masked]>
Date: Fri, 14 Oct 2011 17:24:38 +0200

The interconnection trapezoid we inherited from SIP has become a sort of Gordian knot. If we could avoid RTCWEB server from having to speak to each other at all, we could avoid re-inventing SDP syntax and/or semantics, at least to some degree.

https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/ investigates how we could get rid of server-to-server communication and the associated problems by using 3rd party authentication/authorization. The VWRAP WG discussed something similar with regard virtual world systems interconnection.

I know I missed the dead-line to announce this draft last week.

Wolfgang

--
Deutsche Telekom Netzproduktion GmbH
Fixed Mobile Engineering Deutschland
Wolfgang Beck
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 628 2832 (Tel.)
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.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 14 Oct 2011 17:43:58 +0200

> The interconnection trapezoid we inherited from SIP has become a sort of Gordian knot. If we could avoid RTCWEB server from having to speak to each other at all, we could avoid re-inventing SDP syn…

Hi, maybe I miss something, but this is WWW world and here there is no
server-to-external-server interoperability, never.

The SIP trapezoid exists and works, but IMHO there will never be a
"RTCweb trapezoid". Or do we expect that a user visiting facebook.com
should be able to establish a media session with other user visiting
linkedin.com? I don't think that will occur. There are not "federated
chats" in the web, why should we specify "federated media sessions"?

IMHO this is out of the scope of RTCweb, and in case of introducing it
in the specifications, it would become an overkill (standarizing
signaling between different WWW domains? that's not feasible in this
world).

So I agree with your draft. Instead of "federating" (a concept that
does not exist in WWW jungle) using OAuth or something similar is the
key (so a linkedin.com visitor would establish a HTTP/WebSocket
connection with Facebook.com servers in order to establish a media
session with other user visiting Facebook).

Regards.

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

---

From: Randell Jesup <[email-masked]>
Date: Fri, 14 Oct 2011 12:29:36 -0400

On 10/14/2011 11:43 AM, Iñaki Baz Castillo wrote:
> 2011/10/14<[email-masked]>:

Well, out of that 'jungle' as you refer to it the result is client apps 
that have to talk N protocols -- look at Pidgeon/libpurple, for example. 
  How many IM protocols have to be encoded within it?  Effectively it's 
N clients with a single UI front end - and it has to reverse-engineer 
each of those other-site protocols, generally, and track when they 
change.  Similar things go on with other "let me post something to N 
places" tools, etc.

Federation sounds like a major win over that.

> signaling between different WWW domains? that's not feasible in this

rtcweb is explicitly NOT standardizing the method of federation.  SIP is 
an option, but just an option.  If there is complexity, it will exist 
solely at the federation gateway.  (And if everyone has a way to convert 
to (say) SDP offer-answer, it may work fairly easily.)

> session with other user visiting Facebook).

For that to work, you have to assume that the apps on linkedin and 
facebook each use the same signalling/etc protocol over the websocket, 
OR they know the details of the protocol the other uses, OR they all 
have a single default "fallback" signalling method, which I thought you 
wanted to avoid.

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Oct 2011 17:59:53 +0000

> server-to-external-server interoperability, never.

That's odd - I could have sworn the emails I type into my gmail account reach servers outside of Google, using a standard protocol: SMTP.  Is gmail not in the "WWW world"?
;)

> chats" in the web, why should we specify "federated media sessions"?

Ummm, but there *are* federated chats.  When I join the jabber room for IETF meetings, I don't have a personal account on the IETF's jabber site to do so.

I don't debate that chat is mostly done in closed communities (AIM, YIM, etc.), but SMS is a type of chat and widely popular in a federated model.  And it's usage grew tremendously once different providers federated, which I assume wasn't a coincidence of timing.

> session with other user visiting Facebook).

One problem with that of course is that the user interface would change dramatically every call, and depending on which direction the call was.  My guess is people generally get used to and like their particular UI - where the icons are, what they look like, menu options, settings, etc.

And I would expect some sites to offer JS which lets me do things like turn video off forever, or use a static picture/video of my choosing, which would somehow have to be communicated to the called domain's JS. (And that's just the tip of the proverbial iceberg)

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 14 Oct 2011 20:33:47 +0200

2011/10/14 Randell Jesup <[email-masked]>:
> Well, out of that 'jungle' as you refer to it the result is client apps that
> have to talk N protocols -- look at Pidgeon/libpurple, for example.  How
> many IM protocols have to be encoded within it?  Effectively it's N clients
> with a single UI front end - and it has to reverse-engineer each of those
> other-site protocols, generally, and track when they change.  Similar things
> go on with other "let me post something to N places" tools, etc.

WWW is different. The "software" is provided by each web site. This is
at least how WW works today.

> rtcweb is explicitly NOT standardizing the method of federation.  SIP is an
> option, but just an option.  If there is complexity, it will exist solely at
> the federation gateway.  (And if everyone has a way to convert to (say) SDP
> offer-answer, it may work fairly easily.)

Then, if rtcweb is explicitly NOT standardizing the method of
federation, what is this discussion about? :)

> For that to work, you have to assume that the apps on linkedin and facebook
> each use the same signalling/etc protocol over the websocket,

No, I meant that web sites A.com and B.com allow to each other
displaying the visitors in each page, so a visitor in A.com can see in
the web the visitors connected to B.com. But if a visitor in A.com
wants to talk with a visitor in B.com, A.com retrieves the JS
signaling from *B.com* (B.com allows that due to some kind of
authorization, i.e. OAuth) and both visitors in A.com and B.com speak
the signaling protocol of B.com.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 14 Oct 2011 20:48:20 +0200

> That's odd - I could have sworn the emails I type into my gmail account reach servers outside of Google, using a standard protocol: SMTP.  Is gmail not in the "WWW world"?

Good example, but I expect that SMTP is much simpler than a realtime
communication protocol :)

> Ummm, but there *are* federated chats.  When I join the jabber room for IETF meetings, I don't have a personal account on the IETF's jabber site to do so.

I'm not opposed to RTCweb federation, how could I say that? :)
I just meant that trying to "standarize" that is unfeasible IMHO.
First of all, because standarizing that means that we assume that
every kind of communications made on top of RTCweb specs are the same,
with same properties and capabilities. But I strongly assume that some
web site could offer audio calls between users while other site just
offers video calls. Some web site offers like-SIP full telephony
capabilities (forking, earlymedia, transference) while another web
site is just interested in very simple audio calls. How to make a
standard for federating all those different scenarios? IMHO it's a
no-go.

> One problem with that of course is that the user interface would change dramatically every call, and depending on which direction the call was.  My guess is people generally get used to and like th…

You are right. But see my comment above. What are we trying to achieve
in this thread?

I expect all of this stuff will work as today's WWW world: A very big
web site decides its *own* API/signaling and others (other websites!)
must implement it if they want to offer their users RTC communications
with users in the big web site. Or do we want to standarize the
API/signaling each web site MUST offer to others? this is WWW world,
such things are not welcome here. WWW people don't like protocols or
standards (others than their custom protocols in JSON).

Look the example of authentication in WWW: HTTP defines HTTP
Digest/Basic authentication but, how many web sites use it? no one
today. All of them prefer to use an HTML form with some kind of
JavaScript stuff and some custom message format (of course in JSON
because JSON is the only  message format in the world).

> And I would expect some sites to offer JS which lets me do things like turn video off forever, or use a static picture/video of my choosing, which would somehow have to be communicated to the calle…

Ok, then what is this thread about? :)

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Oct 2011 20:56:56 +0000

> standard for federating all those different scenarios? IMHO it's a

Oh yeah I don't mean to imply we should mandate what the inter-domain protocol must be.  Domains can use whatever they like: SIP, H.323, XMPP, BICC, IAX, some-apple-protocol, some-google-protocol, ...
Who are we to tell a web admin what protocol to use to another web admin?  And even if we did, why would they listen to us?

*BUT* we do have to make sure that SIP can actually be used for such an inter-domain protocol; both because it's an active IETF-defined protocol for real-time communications between peers and we'd look pretty silly if RTCWEB couldn't use it between RTCWEB domains, but also because SIP arguably is the most popular one out there and we should do everything in our power to make it usable to/from RTCWEB domains with as least cost/complexity as possible.

And I don't mean that only in the aspect of federation or PSTN-access.  I don't know if RTCWeb will be popular for those.  But I can guess one application where it will be popular: corporate websites, such as support/help pages or sales pages.  Lots of companies already use plugins/flash on their support/sales websites to enable audio and chat from customers to their internal support/sales people.  Obviously those sales/support employees could be using a browser to communicate with customers using the same website, but it's also as likely that they use their existing SIP infrastructure internally - if for no other reason than they already have it and it works with their IVR, ACD and recording systems, and they can reach employees on mobile phones or the PSTN back out their SIP trunks.

Another obvious application for RTCWEB-to-SIP is Webex, where a company could deploy their own web server for webex-style conferencing without paying Cisco/Webex.  Although most if not all the users on a webex have browser access, it's still the case you need SIP-PSTN access because you need to let conference-type phones access the meeting.  As for example happened this week at the IETF CLUE WG interim meeting: a webex session was available but the physical meeting room used a Polycom conference-phone for the moderator "participant".

-hadriel
p.s. I mean this all in the aspect of a trapezoid where SIP is the high-path between servers, not SIP between the browser and its server.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 14 Oct 2011 23:18:50 +0200

2011/10/14 Hadriel Kaplan <[email-masked]>:
> *BUT* we do have to make sure that SIP can actually be used for such an inter-domain protocol; both because it's an active IETF-defined protocol for real-time communications between peers and we'd look pretty silly if RTCWEB couldn't use it between RTCWEB domains, but also because SIP arguably is the most popular one out there

RTCweb is mostly focused on pure Internet world. Is SIP more extended
in pure Internet than XMPP? I don't think so (I mean pure Internet,
not telcos' private IP networks). So you like SIP (and me), but I
would like to hear the opinion of Google folks about it :)

More comments below.

> And I don't mean that only in the aspect of federation or PSTN-access.  I don't know if RTCWeb will be popular for those.  But I can guess one application where it will be popular: corporate websit…

If you want your RTCweb deploment to interact with SIP... why don't
you use just SIP? :)

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

Why are you assuming that there must be some kind of protocol gateway
RTCweb<->SIP ?  Personally I hate gateways! even more when they are
unnecessary.

Ok, so let's assume that you want some custom singaling protocol for
your RTCweb deployment (instead of using SIP over WebSocket) but want
also to interact with a SIP network out there. What is the problem
with current RTCweb specs?

You say "we do have to make sure that SIP can actually be used for
such an inter-domain protocol" but what do you mean with that? Of
course I want that a RTCweb client can establish a media session with
a pure SIP client (assuming ICE+RTP supported in the SIP device),
don't the current RTCweb specs allow that? I assume such specs and the
resulting JS API will be done with that in mind (but not just SIP but
also XMPP-Jingle and other VoIP protocols based on SDP
exchange/negotiation).

So honestly, I don't understand what you mean in your mail. Of course
we all want RTCweb to be interoperable with a SIP network but, how is
that related to "RTCweb federation"? The success of a interoperation
between RTCweb and a SIP network just depends on how good you are
designing your signaling mapping between your custom RTCweb signaling
and SIP, no more.

Regards.

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

---

From: Ted Hardie <[email-masked]>
Date: Fri, 14 Oct 2011 14:27:03 -0700

On Fri, Oct 14, 2011 at 2:18 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> > *BUT* we do have to make sure that SIP can actually be used for such an
> inter-domain protocol; both because it's an active IETF-defined protocol for
> real-time communications between peers and we'd look pretty silly if RTCWEB
> couldn't use it between RTCWEB domains, but also because SIP arguably is the
> most popular one out there
>
Not speaking for Google, but I have no idea what you mean by "pure Internet
world" here.  I'm also not really clear what your aim is.  Hadriel has said
that the overall system must be designed such that it is possible to use SIP
as a federation protocol, but that it should not be restricted so that only
SIP can be used as a federation protocol.  Perhaps if you responded to his
point on this issue, the rest of your comments might seem more clear.

regards,

Ted Hardie

> More comments below.
>
>
> > And I don't mean that only in the aspect of federation or PSTN-access.  I
> don't know if RTCWeb will be popular for those.  But I can guess one
> application where it will be popular: corporate websites, such as
> support/help pages or sales pages.  Lots of companies already use
> plugins/flash on their support/sales websites to enable audio and chat from
> customers to their internal support/sales people.  Obviously those
> sales/support employees could be using a browser to communicate with
> customers using the same website, but it's also as likely that they use
> their existing SIP infrastructure internally - if for no other reason than
> they already have it and it works with their IVR, ACD and recording systems,
> and they can reach employees on mobile phones or the PSTN back out their SIP
> trunks.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 14 Oct 2011 23:41:42 +0200

2011/10/14 Ted Hardie <[email-masked]>:
> world" here.

"Pure Internet" is just Internet, and that is not a private network or
a telco IP infrastructure. I just meant that.

> I'm also not really clear what your aim is.  Hadriel has said

Ok, let me try again:

IMHO RTCweb (specially the JS API for managing media sessions) must be
designed in a way that it's possible for a developer to implement a
SIP client in JavaScript or another custom signaling protocol having a
gateway that maps it to/from SIP. This means that SIP features as
parallel forking, early media, conference... should be possible using
the RTCweb JavaScript API. I think we agree here :)

So, assuming that there MUST NOT exist a *standard* signaling protocol
for federation in RTCweb, what is the purpose of speaking about
"federation"? Probably we all are speaking about the same concept, but
for me "federation" means a RTCweb server communicating with other
RTCweb server. If Hadriel and you meant "RTCweb server communicating
with a SIP network" then I repeat my first paragraph :)

So in order to accomplish with requirements of Hadriel we need to make
the RTCweb client stack and the RTCweb JavaScript API flexible enough
so all (or most of) the SIP features can be implemented in JavaScript
(I mean "audio/video features" since all the signaling can already be
coded in different ways).

Hope it's more clear now.

Best regards.

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Oct 2011 22:41:24 +0000

> a telco IP infrastructure. I just meant that.

Actually I think you'd be surprised.  I don't know what Google Talk's latest numbers are, but I bet there is in fact more SIP done than XMPP even across the "Public Pure Pristine Internet".  It's not as much SIP as is done within the same network, but it's a still a lot. 
(of course the real king of "public Internet" VoIP would probably be Skype protocol :)

> the RTCweb JavaScript API. I think we agree here :)

Right I think we do agree - I was under the impression you were saying we don't need to work with SIP.

-hadriel

---

From: Ted Hardie <[email-masked]>
Date: Fri, 14 Oct 2011 15:41:57 -0700

On Fri, Oct 14, 2011 at 2:41 PM, Iñaki Baz Castillo

> the RTCweb JavaScript API.
>

Do you think you could support SIP identity with a javascript client?

> "federation"?

I don't think RFC 2119 MUST NOTs belong here.

Understanding federation as a use case does not mandate a "one ring to rule
them all" approach to federation.  We could define one (as XMPP defines how
different XMPP servers pass traffic among themselves).  That would not
mandate that all servers use it.  We could also choose not to define one,
but if we support the use case, we would have to understand what the minimal
set of data that had to be pass over the protocols implementing the
federation would be, what security is required, and so on.

> Probably we all are speaking about the same concept, but
Well, given that you don't believe in the need for a protocol here at all,
but only an incredibly flexible API, it seems a bit unclear why you're not
making these points on the W3C public mailing list for this activity.

A truly well structured API here will imply, at least in my view, at least a
common model for negotiation and a common set of structured data to be
passed via this javascript-implemented protocol.  Doing that without
defining a standard protocol is actually harder than doing it while defining
a protocol.

I've heard the various arguments against defining one, but none of them
seems to stand up against the base fact that you can have a standard
protocol--known to be available--without restricting the ability to create
proprietary protocols using the same API.

regards,

Ted

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 15 Oct 2011 10:37:04 +0200

> Right I think we do agree - I was under the impression you were saying we don't need to work with SIP.

Humm, taking into account that I'm involved in SIP over WebSocket to
make pure SIP (no protocol conversion) available for RTCweb... it
would be annoying that I wouldn't like to interoperate with SIP :)

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 15 Oct 2011 10:43:37 +0200

> Do you think you could support SIP identity with a javascript client?

Yes. The spec (RFC 4474) does NOT mandate that the SIP client MUST to
have a list of CA's and verify the retrieved certificate by itself. A
JavaScript client receiving an incoming INVITE with Identity and
Identity-Info header could make a webservice call (i.e. using AJAX)
and ask its web server to retrieve it and verify it in behalf of the
client. And still that is SIP.

So yes, I could support SIP Indentity with a JavaScript client.

> federation would be, what security is required, and so on.

So just imagine that SIP is used for federation and make the
requirements assuming that.

> Well, given that you don't believe in the need for a protocol here at all,

A protocol is needed, of course. But not a *specific* protocol.

> making these points on the W3C public mailing list for this activity.

I expect such work must come once the requirements for such API are
done in this WG.

> proprietary protocols using the same API.

There have been lot of arguments contrary to defining a "default
signaling protocol". I don't want to repeat them again, but neither
answer as if they don't exist.

Regards.

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

---

From: Neil Stratford <[email-masked]>
Date: Sat, 15 Oct 2011 10:12:34 +0100

On Fri, Oct 14, 2011 at 11:41 PM, Ted Hardie <[email-masked]> wrote:

>
> A truly well structured API here will imply, at least in my view, at least
> a common model for negotiation and a common set of structured data to be

I disagree that there is any requirement for a common model for negotiation.
By all means ensure that the API enables the implementation of SIP and
XMPP/Jingle, but to start with a single protocol and use that to define the
API will undoubtedly lead to unnecessary limitations in the API.

> proprietary protocols using the same API.

Which is true, so long as you don't let your protocol choices leak into the
API definition, which is unfortunately already the case with SDP.

Neil

---

From: Wolfgang <[email-masked]>
Date: Sat, 15 Oct 2011 11:59:46 +0200

First, the draft is not about SIP vs XMPP vs xy. All those protocols
try to be general and necessarily suffer from feature creep and
complexity. SIP once started as a much simpler alternative to H.323
and look where we are now. XMPP has defined more than 300 extensions.
But I think there is not much disagreement about the call signaling
part.

The question is if we can get rid of SDP as well. If both sides
*implicitly* know what codec parameters they are going to use there is
no longer the need to negotiate them. If caller and callee use the
same RTCWEB client this should be doable. The RTCWEB server may need
some hints about the browsers capabilities -- eg does it support a
camera, is the bandwidth limited -- to provide it with an applicable
RTCWEB client. But we don't need a way to convey and negotiate dozens
of codec parameters.

If we insist on interoperability between RTCWEB client A and RTCWEB
client B we will end up re-inventing SDP and/or SIP.  And of course we
will have to keep RTCWEB and SDP standardization in sync.

Wolfgang

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 15 Oct 2011 13:29:04 +0200

> RTCWEB client. But we don't need a way to convey and negotiate dozens
Remember that:
a) codecs are (currently) part of the platform, not of the application.
b) one of our aims for negotiation is that if application X is deployed 
in browsers A and B, and both browser A and B support a "best codec" W 
that was created *after* X was last updated, then the codec W should be 
used.

Given the last point - the app *cannot* "implicitly" what codec will be 
used. And given that it doesn't know the codec, it can't know the 
parameters either.

(that said... I'm all in favour of fewer parameters. The RTP format for 
VP8 that we're in the process of finishing has zero parameters. I hope 
it will remain that way.)
> will have to keep RTCWEB and SDP standardization in sync.
We absolutely insist on interoperability between browser A and browser 
B, if both are runnning applications that want to communicate.

Whether RTCWEB client A wants to communicate with RTCWEB client B should 
be entirely up to them. We're here to make it possible, not here to make 
it mandatory.

---

From: Neil Stratford <[email-masked]>
Date: Sat, 15 Oct 2011 13:08:40 +0100

On Sat, Oct 15, 2011 at 12:29 PM, Harald Alvestrand <[email-masked]>wrote:

> b) one of our aims for negotiation is that if application X is deployed in
> browsers A and B, and both browser A and B support a "best codec" W that was
> created *after* X was last updated, then the codec W should be used.
>
> used. And given that it doesn't know the codec, it can't know the parameters
> either.
>
> (that said... I'm all in favour of fewer parameters. The RTP format for VP8
> that we're in the process of finishing has zero parameters. I hope it will
> remain that way.

Can we work around this issue by delegating parameter negotiation to the
codec itself? Each codec in the codec capability list could present (at a
minimum) it's name, priority and a codec specific parameter negotiation
function. We can then delegate the complicated codec specific details (when
necessary) without needing any advance knowledge in the javascript
application. We would need to standardise the parameter lists such that
different codec implementations can interop, but that is the same with SDP.

Neil

---

From: Wolfgang <[email-masked]>
Date: Sat, 15 Oct 2011 14:58:20 +0200

>> used. And given that it doesn't know the codec, it can't know the parameters
Is this goal worth all the complexity introduced with codec negotiation?

>> VP8 that we're in the process of finishing has zero parameters. I hope it
>> will remain that way.
That's nice if it really stays that way. MPEG2 had this, too. But then
people started using it in ways that haven't been anticipated and it
turned into a horrible mess.

>> We absolutely insist on interoperability between browser A and browser B, if both are runnning applications that want
>> to communicate.
No disagreement here.

>> Whether RTCWEB client A wants to communicate with RTCWEB client B should be entirely up to them. We're here >> to make it possible, not here to make it mandatory.
What does this requirement cost us in terms of complexity? If we have
to replicate SIP's and SDP's functionalities, it might be not worth
it.

> different codec implementations can interop, but that is the same with SDP.
Do you mean moving codec parameter negotiation into the RTP stream? It
would require
transcoding if your media stream leaves RTCWEB. And you are just moving the
complexity to a different part of the system..

Wolfgang

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 15 Oct 2011 15:44:07 +0200

On 10/15/2011 02:08 PM, Neil Stratford wrote:
> On Sat, Oct 15, 2011 at 12:29 PM, Harald Alvestrand 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Remember that:
>     b) one of our aims for negotiation is that if application X is
>     deployed in browsers A and B, and both browser A and B support a
>     "best codec" W that was created *after* X was last updated, then
>     the codec W should be used.
>
>     Given the last point - the app *cannot* "implicitly" what codec
>     will be used. And given that it doesn't know the codec, it can't
>     know the parameters either.
>
>     (that said... I'm all in favour of fewer parameters. The RTP
>     format for VP8 that we're in the process of finishing has zero
>     parameters. I hope it will remain that way.
>
>
> Can we work around this issue by delegating parameter negotiation to 
> the codec itself? Each codec in the codec capability list could 
> present (at a minimum) it's name, priority and a codec specific 
> parameter negotiation function. We can then delegate the complicated 
> codec specific details (when necessary) without needing any advance 
> knowledge in the javascript application. We would need to standardise 
> the parameter lists such that different codec implementations can 
> interop, but that is the same with SDP.
Yes, maybe we could do that. But would it make a difference?

SDP is (among other things) exactly such a parameter list 
standardisation, each and every codec deployed with RTP tends to publish 
a specification on how to encode those parameter lists in SDP, and each 
and every video engine implementing those codecs tends to have code in 
it that parses that SDP and does the negotiation on that basis.

Are we reinventing another encoding format for SDP again?

---

From: Neil Stratford <[email-masked]>
Date: Sat, 15 Oct 2011 15:10:33 +0100

On Sat, Oct 15, 2011 at 2:44 PM, Harald Alvestrand <[email-masked]>wrote:

> **
> SDP is (among other things) exactly such a parameter list standardisation,
> each and every codec deployed with RTP tends to publish a specification on
> how to encode those parameter lists in SDP, and each and every video engine
> implementing those codecs tends to have code in it that parses that SDP and
> does the negotiation on that basis.
>

I guess there are a couple of points here:

1. Yes, we are re-inventing SDP, but at a lower level, so we leave it up to
the developer to use SDP, or something else if they prefer.

2. I fully support that we need to interop with SIP, and that we should make
that a simple thing to do. However, I also think that rtcweb will rapidly
become the dominant RTC platform due to the pervasiveness of browsers. Codec
developers will be targeting rtcweb as a primary platform, especially if we
make it easy to download and deploy new codecs.

Neil

---

From: "Roy, Radhika R USA CIV (US)" <[email-masked]>
Date: Sat, 15 Oct 2011 15:17:54 +0000

Folks:

A given codec type in known, its parameters should also be known per its specifications. So, it the negotiations between codec-types only.

You can see how SDP is used for negotiations between different codec types using SIP. Similar mechanisms can also be used here.

Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Neil Stratford
Sent: Saturday, October 15, 2011 8:09 AM
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

On Sat, Oct 15, 2011 at 12:29 PM, Harald Alvestrand <[email-masked]> wrote:

	Remember that:
	a) codecs are (currently) part of the platform, not of the application.
	b) one of our aims for negotiation is that if application X is deployed in browsers A and B, and both browser A and B support a "best codec" W that was created *after* X was last updated, then the codec W should be used.
	
	Given the last point - the app *cannot* "implicitly" what codec will be used. And given that it doesn't know the codec, it can't know the parameters either.
	
	(that said... I'm all in favour of fewer parameters. The RTP format for VP8 that we're in the process of finishing has zero parameters. I hope it will remain that way.

Can we work around this issue by delegating parameter negotiation to the codec itself? Each codec in the codec capability list could present (at a minimum) it's name, priority and a codec specific parameter negotiation function. We can then delegate the complicated codec specific details (when necessary) without needing any advance knowledge in the javascript application. We would need to standardise the parameter lists such that different codec implementations can interop, but that is the same with SDP.

Neil

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 15 Oct 2011 11:42:39 -0400

Hi Harald,

>it will remain that way.)

I would be surprised if that were the case.  As the very minimum, I would
suspect that you need some form of upper bound for computational decoder
complexity (measured in pixel numbers per second, framerate/picture size
combination, or whatever).  It doest make sense that two systems agree on
VP8, and the receiver cannot rdecode the sender's bitstream because the
receiver is a cheap cellphone and the sender is a desktop PC which likes
to send 1080p.  Let me also note that the VP8 payload spec (at least the
current public version) has a number of "optional" mechanisms, which you
would want to negotiate, no?

Stephan

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 15 Oct 2011 22:15:16 +0200

On 10/15/2011 05:42 PM, Stephan Wenger wrote:
> Hi Harald,
>
> On 10.15.2011 07:29 , "Harald Alvestrand"<[email-masked]>  wrote:
>
(changing the subject again)
This is a discussion more relevant for the payload wg....

As far as I understand the current spec, the features are optional in 
the sense that the sender can choose to use them or not; the recipient 
has to be able to decode the stream, no matter what features are used.

We've got generic features in SDP to negotiate bitrate, resolution and 
some other parameters in a codec-independent fashion, and the RTP/AVPF 
profile has things like TMMBR to tamp down the sending rate even more; 
we'll see if those prove adequate to protect low-powered recipients from 
high-powered senders.

If not, I guess the specs will have to grow.

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 15 Oct 2011 15:46:12 -0700

On Fri, Oct 14, 2011 at 8:24 AM, <[email-masked]> wrote:

> The interconnection trapezoid we inherited from SIP has become a sort of
> Gordian knot. If we could avoid RTCWEB server from having to speak to each
> other at all, we could avoid re-inventing SDP syntax and/or semantics, at
> least to some degree.
>
> https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/ investigates
> how we could get rid of server-to-server communication and the associated
> problems by using 3rd party authentication/authorization. The VWRAP WG
> discussed something similar with regard virtual world systems
> interconnection.
>

There are always "border crossing" issues, which often exploits encryption
as useless even if it works.

Main thing is that assets should not be cached server-to-server unless those
servers tether those assets, yet imagine the
transient optimizations possible.

---

From: Wolfgang <[email-masked]>
Date: Sun, 16 Oct 2011 10:39:27 +0200

> You can see how SDP is used for negotiations between different codec types using SIP. Similar mechanisms can also be used here.
So why do we transport some codec parameters outside the media stream
at all? The called device might need information about the media
stream before establishing it.

The server might need access to codec parameters to forward the call
to the best destination: imagine a user with two RTCWEB clients, one
only supports only low resolution video, the other one full HD. A high
resolution video call comes in. How should the server select the
called client if it doesn't have access to the media stream which
carries the resolution parameters?

In my model the server would know what type of call was set up as it
always controls both ends of the call. If some other application
controls the calling party, you need some standardized protocol like
SDP.

Wolfgang

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 16 Oct 2011 08:19:34 -0700

On Sun, Oct 16, 2011 at 12:36 AM, Wolfgang
<[email-masked]>wrote:

> On Sun, Oct 16, 2011 at 12:46 AM, Dzonatas Sol <[email-masked]> wrote:
>
> I'm not sure what you are trying to explain..
>
> I'm aware that 3d party authentication has its own set of problems,
> but it might be a way to get forward with RTCWEB's signaling problem
> without re-inventing SIP or XMPP.
>
>

In SL, the main tether is simulated gravity. It's harder for the client to
just make-up gravity that would agree with the server. With that known logic
and ray-casts there are many other security options besides encryption.

It's seems hard for devs to justify that level of security without such case
being used for games or only seen as games when it is real-time ubiquity in
mind.

In your case to "avoid RTCWEB server from having to speak to each other at
all" that would mean absolute no tether and no simulated gravity. If that
was the case then, how do we deal with needs at the Olympics? I would not
expect everyone's mobile to work in unison perfectly as one web to meet all
needs. Safety net? Yes.

On a recent news: I like CSS regions suggestion which limits javascript just
to those regions. I think that helps model this WGs overall case with the
trapezoid layout as CSS.

---

From: Randell Jesup <[email-masked]>
Date: Sun, 16 Oct 2011 23:34:13 -0400

> stream before establishing it.

Exactly, and the media stream is unreliable.  This is the purpose of 
sprop-parameter-sets in H.264 SDP.  Also think of gatewaying rtcweb to SDP.

> carries the resolution parameters?

I'm not certain how "the server" would select the client in your 
scenario under any usage; how would the server know before forwarding 
the call which client supported the incoming call's parameters?  Though 
of course you could expose those capabilities to the server explicitly 
when 'registering'.  The problem is that this requires the JS client and 
the server to understand exactly how the codec implementation will 
handle the parameters - you could use a bunch of codec-specific things 
like H.264 does, or generic capabilities.  Generic capabilities won't 
capture all the dimensions of codec negotiation, of course.

> controls the calling party, you need some standardized protocol like

So the server negotiates the parameters?  I'm not sure what "my model" 
means here (and I reviewed earlier messages from you here).

-- 
Randell Jesup
[email-masked]

---

From: Wolfgang <[email-masked]>
Date: Mon, 17 Oct 2011 08:14:25 +0200

On Mon, Oct 17, 2011 at 5:34 AM, Randell Jesup <[email-masked]> wrote:
> I'm not certain how "the server" would select the client in your scenario
> under any usage; how would the server know before forwarding the call which
> client supported the incoming call's parameters?
That's a valid point. So you think Radhika's proposal to only
negotiate codec types
but not codec parameters in the signaling path would cover all
realistic use cases?

> So the server negotiates the parameters?  I'm not sure what "my model" means
> here (and I reviewed earlier messages from you here).
I didn't have company email access during the weekend and I'm the author of
https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/. The idea
is to always use
only one RTCWEB server and authenticate/authorize unknown users by 3rd party
authentication. Like commenting on a blog using OpenID.

Wolfgang Beck

---

From: Randell Jesup <[email-masked]>
Date: Mon, 17 Oct 2011 11:00:26 -0400

On 10/17/2011 2:14 AM, Wolfgang wrote:
> On Mon, Oct 17, 2011 at 5:34 AM, Randell Jesup<[email-masked]>  wrote:

> authentication. Like commenting on a blog using OpenID.

Ok, I looked at draft-beck-rtcweb-alt-ic.

One huge problem with it: it's based on an assumption that for most 
cases of federation and cross-service calls won't hold: that clients 
will use the same client JS app, and the services are just providing 
different realms/methods of authentication and user-lookup.

Also, your draft doesn't explain how A & B came to be talking to the 
same server in the first place.  The draft seems mostly focused on how a 
single provider can use a shared authentication scheme (and I would 
suggest that we try to find a provider-agnostic way to leverage id 
systems such as BrowserID and/or OpenID to provide end-user identification).

You should talk to ekr who's writing the security draft and see if you 
can merge some of these ideas into it.

I don't think it in any way helps our signalling/SDP/etc discussion, my 
apologies.

-- 
Randell Jesup
[email-masked]

---

From: Wolfgang Beck <[email-masked]>
Date: Mon, 17 Oct 2011 19:10:50 +0200

On Mon, Oct 17, 2011 at 5:00 PM, Randell Jesup <[email-masked]> wrote:

> One huge problem with it: it's based on an assumption that for most cases of
> federation and cross-service calls won't hold: that clients will use the
> same client JS app, and the services are just providing different
> realms/methods of authentication and user-lookup.
>
> Also, your draft doesn't explain how A & B came to be talking to the same
> server in the first place.  The draft seems mostly focused on how a single
> provider can use a shared authentication scheme (and I would suggest that we
> try to find a provider-agnostic way to leverage id systems such as BrowserID
> and/or OpenID to provide end-user identification).
>
Ok, here's an example that works today. Let's assume you have a yahoo
account and want to post a comment on stackexchange.com.
You just point your browser to the stackexchange.com url [i.e. user
location]. Now you log in using your yahoo account as OpenID. The
browser loads the stackexchanges's JS client that enables you to post
your text.  There is no comment-posting-protocol required between
yahoo and
stackexchange. They only have to agree on an 3rd party authentication protocol.

If stackexchange extends its functionality, let's say with real-time
chat (which they did), your browser will load the appropriate JS
client
the next time you load the page.  All parties in the chat will use the
same JS client under stackexchange's control, regardless whether
people have
used google, yahoo, or facebook to log in. There is no need to
standardize anything that crosses stackexchange's servers.

Now you want to make a comment on some blog at blogspot.com. You point
your browser at the blog's URL and log in using your Yahoo OpenID.
The browser loads blogspot's JS client. The GUI looks quite different
but you can post your comment as well.

With the current RTCWEB thinking, we would have to specify an intra
server protocol that covered stackexchange's discussion and chat
systems as well as blogspot comments. Such a protocol would soon get
very complex.

> You should talk to ekr who's writing the security draft and see if you can
> merge some of these ideas into it.
>
Thanks for reading and commenting on the draft!

Wolfgang

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 17 Oct 2011 19:25:07 +0200

> but you can post your comment as well.

Exactly. Some people has argued that getting a different GUI is bad,
but this is not about telephony world in which each person has a
phone. This is about communicating with different services each one
providing different features and capabilities so it does not make
sense at all to share the same GUI for RTCweb communication with a
second website.

> systems as well as blogspot comments. Such a protocol would soon get

Agreed.

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 17 Oct 2011 10:50:58 -0700

> So yes, I could support SIP Indentity with a JavaScript client.
I would say you did not do it within the JavaScript client, but built a
JavaScript client that simply trusted the results of the webserver.  This is
significantly worse than even the SSH-style limited identity we've discussed
before, because the Javascript client doesn't even check whether the
identity matches previous uses of that identity.  You also don't describe
how you go about assuring the path over which the media flows, which is a
part of sip identity.

> > making these points on the W3C public mailing list for this activity.
By "a protocol here", I meant "standardized in the IETF" sorry that was not
clear.

> I expect such work must come once the requirements for such API are
The work is ongoing now in both groups and the two are meant to coordinate.
Presuming that all the work will go on there to provide a model-agnostic API
is not effective coordination, at least in my view.

> answer as if they don't exist.
There have been a lot of arguments, but speaking personally, they seem to
boil down to a preference for inferring a model (offer/answer) along with a
slow realization that much of the negotiation here (e.g. codec parameters)
cannot really be punted.  As I said before, if you go down the route of
creating a common model for negotiation and a common set of structured data
for the negotiation and security assurances, you have done the semantic work
of creating a protocol.  Failing to choose a common in syntax in that
situation is, in my experience, both odd and likely to decrease the amount
of deployment and increase the failure rate.

My personal opinion,

Ted Hardie

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 17 Oct 2011 10:52:39 -0700

> systems as well as blogspot comments. Such a protocol would soon get

Such protocol is not possible across domains unless the host is the same.

Only when the host is the same does intra- faces makes sense.

---

From: Randell Jesup <[email-masked]>
Date: Mon, 17 Oct 2011 16:45:41 -0400

On 10/17/2011 1:10 PM, Wolfgang Beck wrote:
> On Mon, Oct 17, 2011 at 5:00 PM, Randell Jesup<[email-masked]>  wrote:
>
>> Also, your draft doesn't explain how A&  B came to be talking to the same

Right; you're talking entirely about open/shared ID systems (ala 
BrowserID, OpenID, Facebook login (ugh), etc).

> standardize anything that crosses stackexchange's servers.

You're making the argument that no federation is needed, because to 
contact someone on stackexchange you'd browse to stackexchange first.

I don't think that handles the use-cases of, from within say gmail, you 
try to call someone on Stackexchange - or even more unavoidable, you try 
to invite someone from stackexchange to join your already-running call. 
  You can't exit out and load the stackexchange JS client.

-- 
Randell Jesup
[email-masked]

---

From: Wolfgang Beck <[email-masked]>
Date: Tue, 18 Oct 2011 07:58:55 +0200

> You're making the argument that no federation is needed, because to contact
> someone on stackexchange you'd browse to stackexchange first.
>
> I don't think that handles the use-cases of, from within say gmail, you try
> to call someone on Stackexchange - or even more unavoidable, you try to
> invite someone from stackexchange to join your already-running call.  You
> can't exit out and load the stackexchange JS client.
>
Good point. Browsers have iframes and tabs in which I can render web
pages of different
sites in parallel. The browser has to deal with the case when more
than one JS client
tries to access the microphone or speaker.

Your first case is easy. I simply open a new tab or window and make the call.
Consultation calling should be easy, too: I have two browser windows,
one with party B, one
with party C. I could talk to them in turns by simply switching between windows.
Conferencing would require that the browser can move media streams
between its JS instances.

I'll go through this old list of IN services and check where my model fails.
http://www.cs.columbia.edu/~library/TR-repository/reports/reports-1999/cucs-002-99.ps.gz

I still refuse to understand RTCWEB as a MEGACO with javascript syntax..

Wolfgang

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Oct 2011 20:26:44 -0600

>> it will remain that way.)

My guess is that VP8 will end up with roughly the same order of magnitude number of parameters as H.264 - they will get added for more or less the same reasons they are there in H.264. Of course less is more and it would be great to have less, but many of therese are needed - particularly if you expect to support codecs with hardware support.