Subject: [rtcweb] Friday Call details for signaling discussion

From: Ted Hardie <[email-masked]>
Date: Tue, 18 Oct 2011 16:22:50 -0700

Below are the call-in details for Friday's call.  This is meant to give any
interested working group participants some extra time in high-bandwidth
discussions while we hash out the signaling proposals that have circulated
on the list.  I expect discussion will include ROAP as well as either a
proposal from Hadriel and/or Wolfgang Beck's alt-ic draft.

This is not an interim meeting, and no decisions will be taken on this call;
it has no special status over any other discussions.

Thanks to Cullen for arranging the Webex bridge.

regards,

Ted

Topic: RTCWeb
Date: Friday, October 21, 2011
Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
Meeting Number: 201 918 267
Meeting Password: ietf
Host Key: 107934

-------------------------------------------------------
To start the online meeting
-------------------------------------------------------
1. Go to
https://cisco.webex.com/ciscosales/j.php?ED=177179667&UID=482186897&PW=NN2U5ZTQxYmE5&RT=MiM0

2. Log in to your account.
3. Click "Start Now".
4. Follow the instructions that appear on your screen.

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas
area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access
Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".
To update this meeting to your calendar program (for example Microsoft
Outlook), click this link:
https://cisco.webex.com/ciscosales/j.php?ED=177179667&UID=482186897&ICS=MIU1&LD=1&RD=2&ST=1&SHA2=VSvxj0KwVStvk6aYb0aofqlHI06wOxeTdOeWJrkBJdY=

To check whether you have the appropriate players installed for UCF
(Universal Communications Format) rich media files, go to
https://cisco.webex.com/ciscosales/systemdiagnosis.php

http://www.webex.com

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Oct 2011 11:25:40 +0200

On 10/19/11 01:22, Ted Hardie wrote:
> Below are the call-in details for Friday's call.  This is meant to 
> give any interested working group participants some extra time in 
> high-bandwidth discussions while we hash out the signaling proposals 
> that have circulated on the list.  I expect discussion will include 
> ROAP as well as either a proposal from Hadriel and/or Wolfgang Beck's 
> alt-ic draft.
Will you be sending out an official reading list before the call?

My current list of maybe-relevant material includes:

- draft-jennings-rtcweb-signaling-00 (ROAP)
- draft-beck-rtcweb-alt-ic-00 (always using a single Web server)
- draft-partha-rtcweb-signaling-00 (advocates picking a standard 
signaling protocol, lists candidates)
- draft-ibc-rtcweb-sip-websocket-00 (on use of WebSocket as a SIP 
subprotocol)
- Neil Stratford's "low level JS API" proposal:
   
https://docs.google.com/document/pub?id=1MfrFHKx6O6yWtIv_jqwyH-RAbm8AgRtXQ7dJTZz5J2g

I can't find any other docs at the moment.

Of these, I would see ROAP and Neil Stratford's document as the ones 
that come closest to being "concrete solutions" as I understood the 
intent of that word in the call sent out on October 4.

But I may have missed some, or the chairs might want to rule the "low 
level JS API" out of scope, since it's not an I-D (or referred to by an 
I-D) at this time.

                     Harald

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Oct 2011 09:43:53 +0200

WG,

The proposed agenda for Firday is as follows:

10 min introduction from each signaling proposal:
- draft-jennings-rtcweb-signaling-00 (ROAP) Cullen
- draft-partha-rtcweb-signaling-00 (Standard signaling protocol) Partha
- ? (No Protocol) ?

In the above only clarifying questions may occur.

20 min discussion of each proposal

30 min concluding discussion

>From my perspective both draft-beck-rtcweb-alt-ic-00 and
draft-ibc-rtcweb-sip-websocket-00 are relevant documents to the
discussion as they provides useful proposals on how interconnect and SIP
interop respectively can be done. But as they aren't proposals for how
the actual signaling solution should work. Thus these are homework but
don't get presentation time.

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: Thu, 20 Oct 2011 12:45:31 +0200

> don't get presentation time.

Hi Magnus. Honestly I don't consider that discussing about
draft-ibc-rtcweb-sip-websocket-00 should take place. It's just a
suggestion about a signaling protocol in RTCweb (in this case pure SIP
over WebSocket). It's not my aim that the WG considers such spec as a
standard signaling for RTCweb. Well, this is basically the same you
have said :)

In the other said, I'd really would like that, before the meeting, all
the folks could take some time to read:

  http://public.aliax.net/RTCweb_Signaling_Components.html
and
  http://www.ietf.org/mail-archive/web/rtcweb/current/msg02158.html

This means not wasting time if somebody proposes ROAP as a "default
signaling protocol" because ROAP is not that and cannot do that (more
info in the given links). Also, given the general confusion when the
term "signaling" appears in this WG, I've tryied to clarify its
meaning(s) in RTCweb context (first link).

For those who advocate for a "default signaling protocol", I hope
second link should make them to re-think about what such erroneous
decision would entail in current and *existing* WWW world.

Best regards.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2011 13:13:34 +0200

On 10/20/11 12:45, Iñaki Baz Castillo wrote:
> 2011/10/20 Magnus Westerlund<[email-masked]>:
While I may quibble with Inaki about the terminology he proposes, I 
think I support what he's driving at in the "components" Web page.

In the -overview-02 draft section 7, the term "media negotiations" is 
used for what he calls "media signalling"; it is trying to get at the 
same distinction.

In his category of "info signalling", I would quibble a bit in that I 
see "channel-related signalling" (a term I just invented, describing 
which media is sent on which SSRC on which port) as distinct from 
"identity-related signalling", where the whole question of "who am I 
talking to" is relevant.

I believe "channel-related signalling" needs to be treated together with 
"media signalling".

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Oct 2011 13:45:27 +0200

2011/10/20 Harald Alvestrand <[email-masked]>:
> While I may quibble with Inaki about the terminology he proposes, I think I
> support what he's driving at in the "components" Web page.
>
> In the -overview-02 draft section 7, the term "media negotiations" is used
> for what he calls "media signalling"; it is trying to get at the same
> distinction.
>
> In his category of "info signalling", I would quibble a bit in that I see
> "channel-related signalling" (a term I just invented, describing which media
> is sent on which SSRC on which port) as distinct from "identity-related
> signalling", where the whole question of "who am I talking to" is relevant.

Hi Harald, the terms I propose are just suggestions. I just wanted to
identify the different "signaling" components, how to name them is
just a matter of taste and I agree that your suggested names could be
just better. :)

As a suggestion, I think that the overview draft could include and
explain those terms so all the WG can refer to the standard names and
avoid confusion.

> I believe "channel-related signalling" needs to be treated together with

That's indeed the usual approach: the "channel-related signalling"
acts as a transport layer for the "media signalling". This is true in
SIP, XMPP and any other VoIP protocol.

The point here is:

If we assume that "channel-related signalling" carries "media
signalling" (as everybody agree I hope), what would entail mandating a
RTCweb default signaling protocol? It would mean that we
define/mandate both signalings (the format of the in-the-wire
messages), and that means that a website developer is not free anymore
to design his own message format and message exchange
mechanism/protocol. This is not just about the "media signaling" but
also about the "channel-related signalling".

We cannot mandate that because WWW already allows each developer to
decide his messages and protocol, and we don't know the requirements
of all the websites (and future websites) in the world, so we cannot
create and mandate a singaling protocol which fulfills every needs. We
cannot assume that every RTC communication involves a single "From"
and a single "To", we cannot assume that the hypothetical user_id
format (to identify the destination user) is valid for all the
websites, neither we can assume that every RTC communication has a
specific "user" destination.

IMHO RTCweb (and W3C) should be limited to define:

- A JavaScript API to manage media sessions (communication between
custom JS and the browser). If this involves state values then let's
call it a "protocol". ROAP accomplishes with this.

- Media related stuff (RTP, SRTP, codecs management, ICE, RTP
security/validation...).

How the "channel-related signalling" and the "media signaling" is
carried in-the-wire should not be defined (IMHO) because it adds
dangerous constrains and it's against the spirit of the WWW world (in
which the lack of constrains is the key of its success).

We cannot go to Facebook and say "if you want to add RTCweb in your
website you must create user identifiers in this exact format,
authentication must be done in this way, you can add to the message
request just these fields...", that is a no-go.

As shown in other thread, currently Facebook JS sends the following
HTTP POST when a user sends a IM to other user in Facebook:

---------------------
POST /ajax/chat/send.php?__a=1 HTTP/1.1'
Host: www.facebook.com'
User-Agent: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:10.0a1)
Gecko/20111017 Firefox/10.0a1'
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8'
Accept-Language: en-us,en;q=0.5'
Accept-Encoding: gzip, deflate'
DNT: 1'
Connection: keep-alive'
X-SVN-Rev: 460802'
Content-Type: application/x-www-form-urlencoded; charset=UTF-8'
Referer: http://www.facebook.com/?sfrm=1'
Content-Length: 399'
Cookie: datr=ZuyfTjurvmsqvYVBDcXF8u; c_user=104442654509775; L=2;
lu=RgQytVtJJBQSvWUNOYzs0oQg; sct=1319153603;
xs=60%3A1c179a6dfb7f08277477b20e778bd391; p=112;
presence=EM319103631L212REp_5f1B04654409875F4EriF0CEstateFDutF1319103633096EvisF1H0EblcF0EsndF1ODiFA21B02602687525A2C_5dEfFA21B02602687525A2EuctF1319103618EsF0CEblFD55F1G319103604PEuoFD1B02602687525FDexpF1319103680370EflF_5b1_5dEolF0CCEalFD1B02602687525FDiF0EmF0CCCC;
wd=1366x675'
Pragma: no-cache'
Cache-Control: no-cache'
'
msg_id=1319103647568%3A3620978310&client_time=1319103646048&to=100002772687525&num_tabs=1&pvs_time&msg_text=hello&to_offline=false&to_idle=false&window_id=2877189837&sidebar_launched=true&sidebar_enabled=true&sidebar_capable=true&sidebar_should_show=false&sidebar_visible=false&post_form_id=449eb730c851e127f21d8a88b6a00667&fb_dtsg=AQC3StlW&lsd&post_form_id_source=AsyncRequest&__user=100002654409995
---------------------

Who will tell Facebook that it cannot use a similar message for RTCweb
audio/video request and instead Facebook must use a specific request
format with specific and limited fields? Not me :)

Best regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Oct 2011 15:31:52 +0200

> I believe "channel-related signalling" needs to be treated together with

Hi Harald, after re-reading this mail from you I've realized that I
don't fully understand it.

For example, a SIP INVITE has:

1) Request URI and headers, which contain the identity information,
the destination of the request, and so. This is what I called
"JS-Server Information Signaling".

2) An SDP, which contains media description. This is what I've called
"JS-Server Media Signaling".

Of course both are carried together (the "JS-Server Information
Signaling" carries the "JS-Server Media Signaling").

Initially I understood that your "channel-related signalling" is the
same concept as my "JS-Server Information Signaling" (bullet 1), but

> signalling", where the whole question of "who am I talking to" is relevant.

What do you mean with "channel-related signalling"?

Thanks a lot.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2011 16:44:42 +0200

On 10/20/11 15:31, Iñaki Baz Castillo wrote:
> 2011/10/20 Harald Alvestrand<[email-masked]>:

"which media is sent on which SSRC on which port".

This is usually sent as part of SDP, but some of Neil Stratford's 
messages have indicated a desire to separate the codec negotiation from 
the channel negotiation, so I thought it was worth pointing out that I 
think they both need to be considered in the group that you called 
"media signaling".

Hope this helps!

                    Harald

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Oct 2011 16:58:31 +0200

> standard signaling for RTCweb. Well, this is basically the same you

Sorry if I wasn't clear enough. I don't intended that we would have any
discussion either of your draft. Only that it is useful background
material for the discussion.

The below links seems useful to have read also before yesterdays conference.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Oct 2011 17:25:45 +0200

> The below links seems useful to have read also before yesterdays conference.
Replace yesterday with tomorrow.

cheers

Magnus Westerlund

---

From: Wolfgang Beck <[email-masked]>
Date: Thu, 20 Oct 2011 18:59:00 +0200

> don't get presentation time.
It's a bit difficult to present an actual signaling situation if the
proposal is not to specify a signaling solution at all..

Wolfgang Beck

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 20 Oct 2011 10:00:25 -0700

> proposal is not to specify a signaling solution at all..
+1

Matthew Kaufman

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Oct 2011 10:07:21 -0700

+1

> Date: Thu, 20 Oct 2011 10:00:25 -0700
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> Subject: Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion
>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2011 19:54:04 +0200

> proposal is not to specify a signaling solution at all..
Well, there's always the idea of specifying how the group's goals can be 
met without specifying a "signaling solution" (noting that, as Inaki has 
pointed out, this term has multiple meanings).

A logical approach would involve showing that it is possible to do all 
the tasks that need to be done by the functions otherwise described as 
"signalling" through a reasonably described API, that all the tricky 
bits (such as deciding to use codec parameters that did not exist when 
the Javascript was written) can be done using only the information that 
this API will be willing to expose to the Javascript, and that it's 
reasonable to assume that the API cannot be used in ways that would 
negatively impact the safety, security and stability of the browser 
platform.

I believe specifying an API such as is being proposed is a significant 
chunk of work, but I do not have the competence to even evaluate the 
size of the effort from the present state of my ignorance, far less the 
chances of arriving at something that can be used successfully.

I'm just somewhat skeptical.

                Harald

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Oct 2011 09:29:46 +0000

I have seen no details about the call time/number/etc.
Is this still happening?

-hadriel

On Oct 20, 2011, at 3:43 AM, Magnus Westerlund wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Oct 2011 11:32:53 +0200

Hi Hadriel,

Details were sent out on Wednesday (19.10). See below.

Regards,

Christer

---------------------

Topic: RTCWeb 

1. Go to https://cisco.webex.com/ciscosales/j.php?ED=177179667&UID=482186897&PW=NN2U5ZTQxYmE5&RT=MiM0 

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. 

2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. 

To update this meeting to your calendar program (for example Microsoft Outlook), click this link: 

To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go tohttps://cisco.webex.com/ciscosales/systemdiagnosis.php 

http://www.webex.com 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 21. lokakuuta 2011 12:30
> To: Magnus Westerlund
> Cc: <[email-masked]>
> > discussion as they provides useful proposals on how 
> interconnect and 
> > SIP interop respectively can be done. But as they aren't 
> proposals for 
> > how the actual signaling solution should work. Thus these 
> are homework 
> > but don't get presentation time.
> > 
> > Cheers
> > 
> > Magnus Westerlund
> > 
> >