Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels?

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 2 Mar 2013 23:33:31 +0000

Part of my hope was that if all these things were on the BFCP list,  we could come to some sanity about what the optimal number of options are.

On Feb 24, 2013, at 3:43 PM, Paul Kyzivat <[email-masked]> wrote:

> On 2/24/13 5:28 PM, [email-masked] wrote:
>> That was my understanding. My point is that on the browser, the data
>> channel is part of the webrtc stuff. While websocket is to me more
>> suitable for such browser to server exchange.
>> Btw, what is the rationale of having bfcp over sctp/dtls on a CLUE
>> endpoint since, unless I am wrong, a CLUE endpoint will also have to
>> support bfcp over tcp (or udp) to interwork with legacy ?
> 
> First, AFAIK there are currently no plans to put bfcp over a data channel, but I think there should be.
> 
> My reason is because that is a mechanism that could be supported by a an RTCWEB client. And yes, it indeed may be the case that a CLUE endpoint may still need to support bfcp over tcp or udp for legacy interworking.
> 
> It would also be possible for an RTCWEB clue client to use bfcp over a websocket.
> 
> The question is: how many of these alternatives do we want to define and then ask people to support in their products. The more alternatives we have the less likely we are to get interoperability.
> 
> We have now started down the path of remapping existing protocols (first SIP, then MSRP, now maybe BFCP) over websockets. Meanwhile RTCWEB is defining data channels over SCTP and and CLUE is tentatively planning to put its protocol over that. So maybe we had better have a discussion of where we are trying to go, and if what we are doing will get us to a good place.
> 
> 	Thanks,
> 	Paul
> 
>> Stéphane.
>> ------------------------------------------------------------------------
>> De : Paul Kyzivat
>> Envoyé : 24/02/2013 02:32
>> À : CAZEAUX Stephane OLNC/OLPS
>> Cc : [email-masked]
>> Objet : Re: [dispatch] FW: New Version Notification for
>> draft-pascual-dispatch-bfcp-websocket-00.txt
>> 
>> On 2/22/13 11:40 AM, [email-masked] wrote:
>>> Hi Paul,
>>> 
>>> Having BFCP over data channel would limit the applicability of BFCP to webrtc (other formulation: it would require the webrtc framework to get BFCP in the browser), while we might want to have BFCP protocol in web client outside of webrtc.
>> 
>> I guess I didn't explain myself well enough.
>> 
>> What I am suggesting is bfcp over the DTLS/SCTP stack that is being used
>> for RTCWEB data channels, and that the mechanisms used to negotiate the
>> stream numbers for each direction be compatible with RTCWEB. In this way
>> a true RTCWEB browser client can be implemented, but a non-RTCWEB (e.g.
>> C-based) implementation is also possible.
>> 
>> This is the same direction we are investigating for the clue data channel.
>> 
>> The term "data channel" here is perhaps overloaded, because it could
>> mean a real RTCWEB data channel, or something similar for other
>> environments. Ideally we would just use SCTP terms, but it has no term
>> for a bidirectional "channel", only unidirectional streams. But this
>> should end up being formalized in the SDP.
>> 
>>         Thanks,
>>         Paul
>> 
>>> Stéphane.
>>> 
>>> -----Message d'origine-----
>>> De : Paul Kyzivat [mailto:[email-masked]]
>>> Envoyé : jeudi 21 février 2013 22:32
>>> À : [email-masked]
>>> Objet : Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt
>>> 
>>> Victor,
>>> 
>>> A question for you:
>>> 
>>> Another possibility is to map bfcp over a data channel as being specified for rtcweb.
>>> 
>>> If that were done, would it be a suitable alternative to bfcp over websocket?
>>> 
>>> We are also going to need bfcp support in conjunction with CLUE.
>>> And CLUE is going to have its own data channel. We are aiming to use an rtcweb-compatible data channel so that we can have rtcweb browser based clue clients.
>>> 
>>> If bfcp also worked over a data channel, then these multiple uses of data channels could all coexist on a single SCTP association. And they could work the same regardless of whether or not there are web clients.
>>> 
>>>       Thanks,
>>>       Paul
>>> 
>>> On 2/21/13 12:38 PM, Victor Pascual Avila wrote:
>>>> Hi all,
>>>> 
>>>> We have submitted a new Internet draft to describe the WebSocket
>>>> Protocol as a Transport for the Binary Floor Control Protocol (BFCP).
>>>> We are looking forward to your review comments.
>>>> 
>>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00
>>>> 
>>>> Best regards,
>>>> -Victor
>>>> 
>>>> 
>>>> On 2/15/13 6:17 PM, "[email-masked]"
>>>> <[email-masked]>
>>>> wrote:
>>>> 
>>>>> 
>>>>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt
>>>>> has been successfully submitted by Victor Pascual and posted to the
>>>>> IETF repository.
>>>>> 
>>>>> Filename:       draft-pascual-dispatch-bfcp-websocket
>>>>> Revision:       00
>>>>> Title:          The WebSocket Protocol as a Transport for the Binary Floor
>>>>> Control Protocol (BFCP)
>>>>> Creation date:  2013-02-15
>>>>> Group:          Individual Submission
>>>>> Number of pages: 9
>>>>> URL:
>>>>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-webso
>>>>> cket-
>>>>> 00.txt
>>>>> Status:
>>>>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket
>>>>> Htmlized:
>>>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00
>>>>> 
>>>>> 
>>>>> Abstract:
>>>>>    The WebSocket protocol enables two-way realtime communication between
>>>>>    clients and servers.  This document specifies a new WebSocket sub-
>>>>>    protocol as a reliable transport mechanism between Binary Floor
>>>>>    Control Protocol (BFCP) entities to enable usage of BFCP in new
>>>>>    scenarios.  This document normatively updates
>>>>>    [I-D.draft-ietf-bfcpbis-rfc4582bis] and
>>>>>    [I-D.draft-ietf-bfcpbis-rfc4583bis]
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> The IETF Secretariat
>>>>> 
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>> 
>>> 
>>> 
>>> 
>> 
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 3 Mar 2013 12:32:57 +0100

At the moment these things are out of scope of BFCPBIS as the charter as currently worded would prevent this.

But I agree that we do still need a proper discussion of what are the correct mechanisms going forward.

I'd note at the moment, and from my perspective, that in terms of public visible support there is not enough momentum for any of the options going forward - that I guess is partly because noone has called for it, but I certainly don't want any of the options allocated to BFCPBIS and find that noone is interested in reviewing the documents.

At the moment the ADs have indicated the DISPATCH list as the consensus building forum for identifying this. That may change, but that is where the discussion needs to be for now.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cullen Jennings (fluffy)
> Sent: 02 March 2013 23:34
> To: Paul Kyzivat
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dispatch] Remapping existing protocols for web usage:
> websockets or data channels?
> 
> 
> Part of my hope was that if all these things were on the BFCP list,  we
> could come to some sanity about what the optimal number of options are.
> 
> 
> > My reason is because that is a mechanism that could be supported by a an
> RTCWEB client. And yes, it indeed may be the case that a CLUE endpoint may
> still need to support bfcp over tcp or udp for legacy interworking.
> >
> > The question is: how many of these alternatives do we want to define and
> then ask people to support in their products. The more alternatives we
> have the less likely we are to get interoperability.
> >
> > We have now started down the path of remapping existing protocols (first
> SIP, then MSRP, now maybe BFCP) over websockets. Meanwhile RTCWEB is
> defining data channels over SCTP and and CLUE is tentatively planning to
> put its protocol over that. So maybe we had better have a discussion of
> where we are trying to go, and if what we are doing will get us to a good
> place.
> >
> > 	Thanks,
> > 	Paul
> >
> >> Stéphane.
> >>> Having BFCP over data channel would limit the applicability of BFCP to
> webrtc (other formulation: it would require the webrtc framework to get
> BFCP in the browser), while we might want to have BFCP protocol in web
> client outside of webrtc.
> >>
> >>> And CLUE is going to have its own data channel. We are aiming to use
> an rtcweb-compatible data channel so that we can have rtcweb browser based
> clue clients.
> >>>
> >>> If bfcp also worked over a data channel, then these multiple uses of
> data channels could all coexist on a single SCTP association. And they
> could work the same regardless of whether or not there are web clients.
> >>>
> >>>       Thanks,
> >>>       Paul
> >>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Mar 2013 12:58:05 +0800

I didn't mean to suggest that there is any interest in doing this in 
bfcpbis, or that thre should be. I have been inquiring around a bit just 
to sense if there is any sort of interest. And at the same time 
wantching these various one-off activities re websockets.

I agree that dispatch is a likely place to start discussing this.
And I think it may be best to start discussing it in general rather than 
treating each case independently.

It is probably premature, and too late, to do anything formal about this 
in Orlando. But we might want to talk about it informally, over beer.

	Thanks,
	Paul

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 04 Mar 2013 12:48:56 +0100

Hi all,

I am interested in this topic to implement it in our MCU,  so I can 
provide some real life feedback:

http://www.medooze.com/products/mcu.aspx

 From my point of view, while the datachannels provides natural 
solutions for some of the issues of bfcp over websockets, implementing 
support for datachannels is an overkill when we just want to use bcfp.
Also, there are quite a lot of clients not supporting bcfp natively, so 
we would like to provide those clients an alternative http interface to 
be able to provide the bcfp functionalities. In that scenario, 
datachannels will not be the best choice.

So, as in our case, we will be implementing bcfp over websockets in any 
case to support this html interface, it would be great to be able to 
reuse the same implementation for webrtc clients (i.e exchanging the set 
up information in the sdp), and avoid the costs of implementing 
datachannels at all.

Also, as a side discussion, regardless of the transport chosen, I don't 
see managing binary messages in the browser is something natural, if 
possible, it would be a good idea to add support for other serialization 
formats for bcfp messages more usable in browsers (i.e. json or xml).

Best regards
Sergio

> ---------- Forwarded message ----------
> From:  <[email-masked]>
> Date: Sun, Feb 24, 2013 at 10:28 AM
> Subject: Re: [dispatch] FW: New Version Notification for
> To: [email-masked]
> Cc: [email-masked]
>
>
> ________________________________
> De : Paul Kyzivat
>> Having BFCP over data channel would limit the applicability of BFCP 
>> to webrtc (other formulation: it would require the webrtc framework 
>> to get BFCP in the browser), while we might want to have BFCP 
>> protocol in web client outside of webrtc.
>> an rtcweb-compatible data channel so that we can have rtcweb browser 
>> based clue clients.
>>
>> data channels could all coexist on a single SCTP association. And 
>> they could work the same regardless of whether or not there are web 
>> clients.
>>
>>         Thanks,
>>         Paul
>>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 04 Mar 2013 12:46:33 +0100

Hi all,

Best regards
Sergio

---

From: Mary Barnes <[email-masked]>
Date: Mon, 4 Mar 2013 11:42:09 -0600

On Sun, Mar 3, 2013 at 10:58 PM, Paul Kyzivat <[email-masked]> wrote:
> bfcpbis, or that thre should be. I have been inquiring around a bit just to
> sense if there is any sort of interest. And at the same time wantching these
> various one-off activities re websockets.
>
[MB] Yes - that's exactly what we need to do.  The ADs suggested doing
this on the RAI area mailing list.  But, there are far less people
subscribed to that list than this one (260 vs 444).  I'll start a new
thread on the general topic. [/MB]
>
> It is probably premature, and too late, to do anything formal about this in
> Orlando. But we might want to talk about it informally, over beer.
>
>         Thanks,
>         Paul
>
>
>> I'd note at the moment, and from my perspective, that in terms of public
>> visible support there is not enough momentum for any of the options going
>> forward - that I guess is partly because noone has called for it, but I
>> certainly don't want any of the options allocated to BFCPBIS and find that
>> noone is interested in reviewing the documents.
>>
>> At the moment the ADs have indicated the DISPATCH list as the consensus
>> building forum for identifying this. That may change, but that is where the
>> discussion needs to be for now.
>>
>> Keith
>>
>>>> First, AFAIK there are currently no plans to put bfcp over a data
>>>
>>> channel, but I think there should be.
>>>>
>>>>
>>>> It would also be possible for an RTCWEB clue client to use bfcp over a
>>>
>>> websocket.
>>>>
>>>>
>>>>> -----------------------------------------------------------------------
>>>
>>> -
>>>>>
>>>>> De : Paul Kyzivat
>>>>> What I am suggesting is bfcp over the DTLS/SCTP stack that is being
>>>
>>> used
>>>>>
>>>>> stream numbers for each direction be compatible with RTCWEB. In this
>>>
>>> way
>>>>>
>>>>> This is the same direction we are investigating for the clue data
>>>
>>> channel.
>>>>>
>>>>>
>>>>>> Objet : Re: [dispatch] FW: New Version Notification for draft-pascual-
>>>
>>> dispatch-bfcp-websocket-00.txt
>>>>>>
>>>>>>
>>>>>> Victor,
>>>>>>
>>>>>> A question for you:
>>>>>>
>>>>>> Another possibility is to map bfcp over a data channel as being
>>>
>>> specified for rtcweb.
>>>>>>
>>>>>>
>>>>>> If that were done, would it be a suitable alternative to bfcp over
>>>
>>> websocket?
>>>>>>
>>>>>>
>>> based
>>>>>>>> Title:          The WebSocket Protocol as a Transport for the Binary
>>>
>>> Floor
>>>>>>>>
>>>>>>>> Control Protocol (BFCP)
>>>>>>>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-
>>>
>>> webso
>>>>>>>>
>>>>>>>> cket-
>>>>>>>> 00.txt
>>>>>>>> Status:
>>>>>>>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-
>>>
>>> websocket
>>>>>>>>
>>>>>>>> Htmlized:
>>>>>>>>     The WebSocket protocol enables two-way realtime communication
>>>
>>> between
>>>>>>>>
>>>>>>>>     clients and servers.  This document specifies a new WebSocket
>>>
>>> sub-
>>>>>>>>

---

From: Mary Barnes <[email-masked]>
Date: Mon, 4 Mar 2013 11:42:55 -0600

I just realized the title of this thread is general (and not unique to
bfcpbis despite the content). So, I believe we can have the general
discuss here.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 5 Mar 2013 12:56:24 +0100

2013/2/24 Paul Kyzivat <[email-masked]>:
> then ask people to support in their products. The more alternatives we have
> the less likely we are to get interoperability.

Hi, WebSocket is an already existing protocol implemented in both
clients (mostly web browsers) and servers (there are tons of WebSocket
server implementations). In the other side WebRTC Data Channel will be
first implemented as a direct communication mechanism between browsers
and, maybe in a future, there will appear *complex* server side
implementations (which all the SCTP-over-DTLS-over-UDP that Data
Channel requires).

I don't know BFCP protocol but it seems to be a protocol to "manage a
conference server", am I right? If so, WebSocket protocol already
provides the pieces for carrying BFCP messages from WebSocket capable
clients to a WebSocket server. Doing the same with Data Channel will
require much more work.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Mar 2013 02:29:19 +0800

Iñaki,

In the specific case of bfcp, it is likely that one end will always be 
on a server. (Its unlikely that one would want to use bfcp in a pt-pt 
call between two web clients.) So that makes websockets suitable, where 
it would be less so for something that might be used between two web 
clients.

My point in bringing up the question is so that we consider the 
pros/cons in the context of the likely alternatives.

	Thanks,
	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 5 Mar 2013 19:56:32 +0100

On 3/5/13 7:29 PM, Paul Kyzivat wrote:
> call between two web clients.) So that makes websockets suitable, 
> where it would be less so for something that might be used between two 
> web clients.
>
from the JavaScript API prospective the standardization effort in W3C is 
to make the WebSocket and DataChannel API behavior as similar as possible,
so that they can be interchangeable. I hope this aim will be met.

It make sense, and actually it is required, standardize the protocol 
transported over WebSocket (i.e. the WebSocket subprotocols).
While at moment there is not a need to do that for DataChannel.

my 2 cents
/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 5 Mar 2013 19:51:03 +0000

> Behalf Of Paul Kyzivat
> Sent: Tuesday, March 05, 2013 10:29 AM
> To: Iñaki Baz Castillo

I disagree, in that even in a pt to pt call, BFCP is used to negotiate which endpoint is allowed to transmit content. The offer/answer exchange is used to determine which end should be the BFCP server and which should be the BFCP client. In the case of a conference, the conference server typically tries to be the BFCP server and the conference participants happily let it.

Cheers,
Charles

> have

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Mar 2013 05:01:01 +0800

> I disagree, in that even in a pt to pt call, BFCP is used to negotiate which endpoint is allowed to transmit content. The offer/answer exchange is used to determine which end should be the BFCP ser…

Good to have a comment from someone who actually knows about bfcp!

In that case, websockets wouldn't work between two rtcweb clients 
without a relay in the middle, right?

	Thanks,
	Paul

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 05 Mar 2013 22:27:36 +0100

El 05/03/2013 22:01, Paul Kyzivat escribió:
>> I disagree, in that even in a pt to pt call, BFCP is used to 
>> negotiate which endpoint is allowed to transmit content. The 
>> offer/answer exchange is used to determine which end should be the 
>> BFCP server and which should be the BFCP client. In the case of a 
>> conference, the conference server typically tries to be the BFCP 
>> server and the conference participants happily let it.
>

But on the other side, if a browser doesn't support webrtc, you won't be 
able to use BFCP. Typical situation is when you are connecting to the 
conference simultaneously from a phone/videophone and also connected in 
your PC via web.

Also, adding datachannels support to a server just to support BFCP on 
web clients is an absolute overkill.

Best regards
Sergio

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 5 Mar 2013 22:54:18 +0100

2013/3/5 Paul Kyzivat <[email-masked]>:
> In that case, websockets wouldn't work between two rtcweb clients without a
> relay in the middle, right?

Right. WebSocket is client-server bi-directional communication.

BTW I strongly consider an error assuming that a web application will
run without knowledge of the web server from where the page was
retrieved.

A web application (let's name it "JavaScript application") is not like
a standalone desktop app. Instead it plays the Web rules. WebRTC Data
Channel aim is to provide a direct communication between browsers for
those cases in which having the web server as intermediary is not a
good idea (realtime applications like games, big file transfers and so
on). But implementing a pure network protocol on top of Data Channel
is not the "Web style" at all and website admins will like the idea
because they loose the control.

WebSocket requires server side so the website admin can "match" web
logins and WebSocket connections if both are separate servers (via
Cookies or whatever other well known Web mechanism). But in case Data
Channels is used for direct communication between browsers then the
server/provider/service is not aware of such a communication. That's
not the Web model IMHO.

My two cents.

Best regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 5 Mar 2013 22:56:03 +0100

2013/3/5 Iñaki Baz Castillo <[email-masked]>:
> and website admins will like the idea

I mean: "the WON'T like the idea".

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Mar 2013 06:28:38 +0800

> web clients is an absolute overkill.

What are we trying to accomplish here?

If we want to support use of BFCP by an RTCWEB client, then presumably 
the browser supporting that client supports RTCWEB. So it could use BFCP 
over data channel. Or we could use websocket.

If we want to support a web client that is not an RTCWEB client, and 
running with a web browser that doesn't support RTCWEB, then we could 
use BFCP over websocket. But then two of those couldn't talk to one 
another - they could only talk to a server. That would work with 
conference servers that support BFCP over websocket.

The main impact seems to be whether the server prefers to support 
websocket or data channel for BFCP. Maybe it would be a bit easier. But 
some will be doing data channels anyway. (E.g. for CLUE.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Mar 2013 06:43:09 +0800

> server/provider/service is not aware of such a communication. That's

This is not something I know a lot about, so I'd like to hear from 
others who do.

There are two different use cases here:

- endpoints talking to each other, pt-pt
- endpoints talking to a conference server

When web endpoints are involved, there is also a web server for each of 
those. (It may be the same one, or not.) And there can be mixed cases 
where one endpoint is a web client and the other is not.

When there is a conference server, it may be the same, or affiliated 
with, a web server that services the web clients. In that case it might 
be quite natural for BFCP over websocket to terminate on that web server 
and be directly coupled to the conference server.

But it is also possible that there is a pt-pt call between two endpoints 
who want to do floor control among themselves, as Charles described. (I 
have no idea if this happens much in practice.) If so, then requiring a 
web server to mediate over the BFCP is problematic.

And its also possible that we have a conference server that knows 
nothing of the web. And then a separate web server that provides an 
RTCWEB gateway to calls and conferences. Do we want it to be involved in 
the BFCP? I don't think so.

Except in the case where the web server is coupled to the conference 
server I can see no rationale for the web server to be aware of the BFCP.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 6 Mar 2013 18:00:39 +0100

2013/3/4 Sergio Garcia Murillo <[email-masked]>:
> So, as in our case, we will be implementing bcfp over websockets in any case
> to support this html interface, it would be great to be able to reuse the
> same implementation for webrtc clients (i.e exchanging the set up
> information in the sdp), and avoid the costs of implementing datachannels at
> all.

I don't know BCFP, but by looking at SDP examples in RFC 4583 I see this:

---------------
   m=application 50000 TCP/TLS/BFCP *
   a=setup:passive
   a=connection:new
   a=fingerprint:SHA-1 \
        4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
   a=floorctrl:s-only
   a=confid:4321
   a=userid:1234
   a=floorid:1 m-stream:10
   a=floorid:2 m-stream:11
   m=audio 50002 RTP/AVP 0
   a=label:10
   m=video 50004 RTP/AVP 31
   a=label:11
---------------

Well, I strongly hope nobody plans to pass such an SDP to a WebRTC
RTCPeerConnection constructor since it will die. This is, I hope
running BCFP does not require sending an INVITE with SDP containing
both audio/video data and BCFP data, because that will never work in
WebRTC land, and playing with JavaScript for parsing, splitting and
merging SDP fragments is not funny at all.

> Also, as a side discussion, regardless of the transport chosen, I don't see
> managing binary messages in the browser is something natural, if possible,
> it would be a good idea to add support for other serialization formats for
> bcfp messages more usable in browsers (i.e. json or xml).

WebSocket allows both UTF-8 and binary WebSocket messages. How the JS
client code (in the web application) handles binary data is up to the
developer, but JavaScript is not "byte aware" at all, so probably this
is a show-stopper.

What I mean is that, prior to starting a work for standarizing BCFP
over WebSocket or over WebRTC Data Channel, it's required to verify
whether the *binary* data carried on top of the transport is
manageable, OR NOT, by a JS application. I insist: JavaScript knows
about unicode symbols, not about bytes. I may miss something, of
course.

Regards.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2013 01:01:28 +0800

Iñaki,

Yes, IIUC the existing BFCP can't be used from a browser - neither the 
TCP nor the UDP form. And that won't be fixed by webrtc.

So what to do about that? It appears there are three possibilities:

1) A new mapping of BFCP over websockets

2) A new mapping of BFCP over webrtc data channel

3) build a BFCP "proxy" in the web server, converting to proprietary
    signaling between the web server and the browser.

Hopefully we can discard (3) as unreasonable.

It sounds like (2) will be more secure unless some improvements are made 
to websockets.

And (2) will work when doing BFCP pt-pt between two browsers, where (1) 
won't without some sort of proxy in the middle.

OTOH (1) may be easier to implement when the other end is a server 
rather than a browser.

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 7 Mar 2013 23:10:08 +0530

Paul,

> OTOH (1) may be easier to implement when the other end is a server

Hope you assume that server is the combination of signaling & media entity. (1) is not good in case server is designed in a decomposed way wherein signaling & media are handled by different physical entity in the server. 

Thanks
Partha

> Sent: Thursday, March 07, 2013 10:31 PM
> To: [email-masked]
> Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-

<Partha> Hope you assume that server is the combination of signaling & media entity. (1) is not good in case server is designed in a decomposed way wherein signaling & media are handled in different physical entity. </Partha>

---

From: Mary Barnes <[email-masked]>
Date: Thu, 7 Mar 2013 11:43:41 -0600

<As an individual since we're still discussing this on DISPATCH>

Personally, I think one is a better approach. There may be
applications that want to use BFCP that don't want to the WebRTC data
channel.  While we think CLUE might use the WebRTC data channel that
is not yet a given.  Thus, I am far more comfortable with the 1)
moving forward.

Mary.

On Thu, Mar 7, 2013 at 11:01 AM, Paul Kyzivat <[email-masked]> wrote:
> Iñaki,
>
> Yes, IIUC the existing BFCP can't be used from a browser - neither the TCP
> nor the UDP form. And that won't be fixed by webrtc.
>
> It sounds like (2) will be more secure unless some improvements are made to
> websockets.
>
> OTOH (1) may be easier to implement when the other end is a server rather
> than a browser.
>
>         Thanks,
>         Paul
>
>
>
>>> case
>>> see

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2013 02:12:02 +0800

For BFCP I don't have a strong preference.

I notice in the conversation about mrsp over websocket that there is 
some concern over the level of security possible with websockets. That 
should at least be considered, though maybe BFCP isn't at the top of 
anyone's list of security concerns.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 7 Mar 2013 22:27:30 +0100

2013/3/7 Paul Kyzivat <[email-masked]>:
> I notice in the conversation about mrsp over websocket that there is some
> concern over the level of security possible with websockets.

Hi Paul, which are those security concerns about WebSocket? More then
500 millons of persons chat via HTTPS (Facebook). WebSocket provides
similar security (as the authorization can also be done via Cookies
and the traffic can be encrypted via SSL/TLS when ussing WSS).

Maybe the concerns you mean are just when implementing MSRP over WebSocket?

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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 07 Mar 2013 22:34:04 +0100

> Hope you assume that server is the combination of signaling & media entity. (1) is not good in case server is designed in a decomposed way wherein signaling & media are handled by different physica…

I have implemented the MCU with independent signaling and media 
components and that is not a problem for me. I will implement websockets 
support in the media component without much effort.

Best regards
Sergio

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 10 Mar 2013 17:28:19 -0500

On Mar 6, 2013, at 11:00 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> RTCPeerConnection constructor since it will die.

If an offer such s that got passed into a browser and it died, I would view that as a bug. Of course I don' expect it to implement BFCP but I expect the newer to correctly reject it. Actually, if there was any string you could pass in from JS to the browser that caused the browser to die, I would consider that  a bug.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 10 Mar 2013 17:32:15 -0500

It seems to me an important point on this is thinking about where BFCP is used. Does it need to be P2P or can it just form a web socket to some server. The API for web sockets and data channels is very close to the same so the important feature is do you need the P2P capabilities of data channel or not. 

On Mar 5, 2013, at 4:28 PM, Paul Kyzivat <[email-masked]> wrote:

> If we want to support use of BFCP by an RTCWEB client, then presumably the browser supporting that client supports RTCWEB. So it could use BFCP over data channel. Or we could use websocket.
> 
> If we want to support a web client that is not an RTCWEB client, and running with a web browser that doesn't support RTCWEB, then we could use BFCP over websocket. But then two of those couldn't talk to one another - they could only talk to a server. That would work with conference servers that support BFCP over websocket.
> 
> The main impact seems to be whether the server prefers to support websocket or data channel for BFCP. Maybe it would be a bit easier. But some will be doing data channels anyway. (E.g. for CLUE.)
> 
> 	Thanks,
> 	Paul
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 10 Mar 2013 23:38:21 +0100

> If an offer such s that got passed into a browser and it died, I would view that as a bug. Of course I don' expect it to implement BFCP but I expect the newer to correctly reject it. Actually, if t…

Probably it's a bug as you say. But my question is: will browser
vendors allow passing "strange" stuff into the SDP? Taking into
account the SDP format complexity and the issues already being
discussed rigth now in rtcweb WG about SDP usage, I don't expect that
such an exotic SDP will work.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Mar 2013 10:43:31 +0800

> It seems to me an important point on this is thinking about where BFCP is used. Does it need to be P2P or can it just form a web socket to some server. The API for web sockets and data channels is…

I'm not a bfcp expert. ISTM that it is most likely to be used with a 
media server in a conference. But when I said that I got feedback that 
it may also be used in a p2p environment. I don't know if that is real, 
or theoretical.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 11 Mar 2013 04:01:31 +0000

For SIP based video conference, BFCP is required or else the second video m-line for content sharing will not be setup. This is true for an endpoint connecting to a conference server but also for two endpoints connecting to each other. 

Cheers,
Charles

> Sent: Sunday, March 10, 2013 10:44 PM
> To: Cullen Jennings
> Cc: [email-masked]
> > It seems to me an important point on this is thinking about where BFCP is
> used. Does it need to be P2P or can it just form a web socket to some server.
> The API for web sockets and data channels is very close to the same so the
> important feature is do you need the P2P capabilities of data channel or not.
> 
> where
> another - they could only talk to a server. That would work with conference
> servers that support BFCP over websocket.
> >>

---

From: Adam Roach <[email-masked]>
Date: Mon, 11 Mar 2013 09:38:41 -0400

> such an exotic SDP will work.

All I think you'll see is that the browser -- just like any other 
endpoint that doesn't support BFCP -- would decline the BFCP media section.

/a

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 11 Mar 2013 15:27:36 +0100

2013/3/11 Adam Roach <[email-masked]>:
> All I think you'll see is that the browser -- just like any other endpoint
> that doesn't support BFCP -- would decline the BFCP media section.

Hopefully yes :)

Then the problem is how the JS code *parses* and *mangles* the SDP to
interact with the BFPC media section, which is hard to accomplish
given the SDP format... but that's another subject :)

PS: Anyhow I would like to insist that, if BFPC means a "binary
protocol", then it will be really hard to implement it at JavaScript
level.

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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 11 Mar 2013 15:33:46 +0100

> protocol", then it will be really hard to implement it at JavaScript

Fully agree. Whatever protocol it is used, either websocket or 
datachannel, we will need to create a json/xml representation of the 
bcfp messages to be able to easily use it on browsers.

Best regards
Sergio

---

From: Mary Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 09:02:06 -0500

Hi all,

As discussed in the DISPATCH WG session, we are doing an official call
for comments/agreement to move this work item to the BFCPbis WG.  If
folks could please respond if they support this or provide comments if
you do not.

As discussed in the meeting, if we get agreement, the chairs/ADs would
update BFCPbis WG charter to include this work item and forward to WG
and IESG for review/approval.  The WG would then need to decide
whether to adopt this specific document towards that WG deliverable.

Please respond no later than Friday, March 22nd, 2013.  Silence will
be taken as agreement.

Thanks,
Mary
DISPATCH WG co-chair

On Thu, Feb 21, 2013 at 11:38 AM, Victor Pascual Avila
<[email-masked]> wrote:
> On 2/15/13 6:17 PM, "[email-masked]" <[email-masked]>
> wrote:
>
>>
>>http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-websocket-
>>00.txt
>>Status:

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Mar 2013 00:51:11 +0800

I am ok with this.

*BUT* I still want to again raise the question whether we should be 
thinking in general about the porting of existing protocols to new 
transports.

The RTCWEB effort is putting a lot of emphasis on rapid session startup 
and connection establishment. In that environment it is attractive to 
think about having lots of protocols run over data channels, so they can 
take advantage of multiplexing and quick startup. This could apply to 
BFCP and MSRP that are working on websocket transports. And how many 
more will there be?

Because websockets and data channels will be similar from an API 
perspecitive, perhaps it would be possible to define a transport mapping 
that works for both. But that won't help unless both are actually 
implemented.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 11:55:30 -0500

That's a different question and there's already a separate thread on that:
http://www.ietf.org/mail-archive/web/dispatch/current/msg04609.html

So, if folks can please have the general discussion under the
appropriate subject that would help a lot.

Mary.

On Tue, Mar 12, 2013 at 11:51 AM, Paul Kyzivat <[email-masked]> wrote:
> I am ok with this.
>
> *BUT* I still want to again raise the question whether we should be thinking
> in general about the porting of existing protocols to new transports.
>
> The RTCWEB effort is putting a lot of emphasis on rapid session startup and
> connection establishment. In that environment it is attractive to think
> about having lots of protocols run over data channels, so they can take
> advantage of multiplexing and quick startup. This could apply to BFCP and
> MSRP that are working on websocket transports. And how many more will there
> be?
>

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 13 Mar 2013 21:46:44 +0530

Mary,

Hope the general discussion about data channel vs Websocket will be 
concluded before BFCPbis adds WG item for new transport. 

IMO, it is not good to recommend both data channel & WebSocket for 
the same protocol as the implementers will be forced implement both.

Thanks
Partha

> Behalf Of Mary Barnes
> Sent: Tuesday, March 12, 2013 10:26 PM
> To: Paul Kyzivat
> Cc: DISPATCH
> thinking
> websocket-

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 13 Mar 2013 18:00:22 +0000

My main concern with BFCP over WebSockets is that because BFCP is a binary protocol, transporting over WebSockets would put implementation challenges on the JavaScript applications. I'm not saying binary cannot be handled in JavaScript, but my impression is that needing to do so is not desirable. Therefore, it may be worth considering defining a mapping of BFCP to JSON instead of or in addition to BFCP over WebSockets.
That said, I am not very fluent in web-speak, so please forgive me and set me straight if what my concern is unfounded.

Cheers,
Charles

> Sent: Tuesday, March 12, 2013 10:02 AM
> To: DISPATCH
> Cc: Cullen Jennings (fluffy); Richard Barnes; Victor Pascual; rai-
> [email-masked]

---

From: Kevin Fleming <[email-masked]>
Date: Wed, 13 Mar 2013 15:37:22 -0400

On Wed, Mar 13, 2013 at 2:00 PM, Charles Eckel (eckelcu)
<[email-masked]>wrote:

> My main concern with BFCP over WebSockets is that because BFCP is a binary
> protocol, transporting over WebSockets would put implementation challenges
> on the JavaScript applications. I'm not saying binary cannot be handled in
> JavaScript, but my impression is that needing to do so is not desirable.
> Therefore, it may be worth considering defining a mapping of BFCP to JSON
> instead of or in addition to BFCP over WebSockets.
> That said, I am not very fluent in web-speak, so please forgive me and set
> me straight if what my concern is unfounded.
>
>
Unlike WebRTC, Websocket is not JavaScript-specific (or even
JavaScript-oriented). It's general purpose, and supports binary message
transport. There are certainly applications envisionable for using
WebSockets to transport protocols between a client that is *not* a browser
and a server.

---

From: Mary Barnes <[email-masked]>
Date: Wed, 13 Mar 2013 14:50:06 -0500

> concluded before BFCPbis adds WG item for new transport.
[MB] I don't think that will necessarily happen.  [/MB]
> the same protocol as the implementers will be forced implement both.
[MB] We already have BFCP over TCP and UDP is currently being
specified.  There has not yet been a concrete proposal for BFCP over a
data channel that is being defined for WebRTC.  That might happen and
we can discuss that when it does. [/MB]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Mar 2013 11:12:50 +0800

On 3/14/13 3:37 AM, Kevin Fleming wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     My main concern with BFCP over WebSockets is that because BFCP is a
>     binary protocol, transporting over WebSockets would put
>     implementation challenges on the JavaScript applications. I'm not
>     saying binary cannot be handled in JavaScript, but my impression is
>     that needing to do so is not desirable. Therefore, it may be worth
>     considering defining a mapping of BFCP to JSON instead of or in
>     addition to BFCP over WebSockets.
>     That said, I am not very fluent in web-speak, so please forgive me
>     and set me straight if what my concern is unfounded.
>
>
> WebSockets to transport protocols between a client that is *not* a
> browser and a server.

But there is reason to think that a browser *would* want to use BFCP, so 
one would think that when defining a new binding that *could* be used 
from a browser it would make sense to ensure that it really could.

But I don't have javascript skills. I have heard variously that doing 
such a binary protocol in javascript would be impossible, or just 
inconvenient. If it is just inconvenient, then a suitable library on top 
could fix that.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 14 Mar 2013 15:30:56 +0100

2013/3/14 Paul Kyzivat <[email-masked]>:
> But I don't have javascript skills. I have heard variously that doing such a
> binary protocol in javascript would be impossible, or just inconvenient. If
> it is just inconvenient, then a suitable library on top could fix that.

I don't think so. The "issue" here is that JavaScript cannot properly
deal with binary information. This is, JS cannot get each "byte" of a
received string. Maybe there are some workarounds but, for sure, it
finally becomes painful.

Another JS library on top of the JS BPFC stack would not help a lot.

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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 25 Mar 2013 08:44:27 -0600

> such an exotic SDP will work.

I would not describe this as exotic SDP - it's offer / answer SDP. Try it out in firefox and see what happens.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 25 Mar 2013 17:44:03 -0400

On Thu, Mar 14, 2013 at 10:30 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> such a

Iñaki:
News of JavaScript's lack of binary access is highly overrated.  There are
efficient structures for binary access in most browsers today, based on
Typed Arrays.
<http://www.khronos.org/registry/typedarray/specs/latest/>
People even do crypto with JS, arguably one of the applications most
sensitive to which bits are where.
<https://code.google.com/p/crypto-js/>

Paul:
Net of all that, I would say that reality is more on the "inconvenient" end
of your spectrum.  However, popping back up, WS and DataChannel APIs are
essentially the same (by design), so what's defined for one should work
over the other.

--Richard

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 25 Mar 2013 23:20:05 +0100

> <https://code.google.com/p/crypto-js/>

Sure, but I wouldn't like to code a JS library to handle a binary
protocol which could also have a text representation, much more
suitable and friendly for a JS environment. This is not cryptography
but a network protocol. IMHO a text based representation of the
protocol should be needed.

Regards.

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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 25 Mar 2013 23:21:40 +0100

> protocol should be needed.

+1

Best regards
Sergio

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Mar 2013 07:19:50 +0800

Richard,

On 3/26/13 5:44 AM, Richard Barnes wrote:
> On Thu, Mar 14, 2013 at 10:30 AM, Iñaki Baz Castillo <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     2013/3/14 Paul Kyzivat <[email-masked]
>     <mailto:[email-masked]>>:
> News of JavaScript's lack of binary access is highly overrated.  There
> are efficient structures for binary access in most browsers today, based
> on Typed Arrays.
> Net of all that, I would say that reality is more on the "inconvenient"
> end of your spectrum.

Great. That is what I was hoping to hear.

> However, popping back up, WS and DataChannel APIs
> are essentially the same (by design), so what's defined for one should
> work over the other.

Yes, I understand that should be the case. But from a deployment 
perspective it makes quite a bit of difference which one(s) are actually 
deployed. Signaling in SDP that you can do it either way is incredibly 
messy, so I don't expect to see that.

Practically speaking, bfcp over websocket will probably close the door 
on bfcp over data channel. So I think it is important to carefully 
consider which one to pursue.

ISTM the main issue is that bfcp over datachannel can work peer to peer, 
while bfcp over websocket will only be useful with a webserver in the 
middle. (Presumably that can be resolved in some cases by inserting a 
websocket relay of some sort.)

	Thanks,
	Paul

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Mon, 25 Mar 2013 20:42:13 -0500

On Mon, Mar 25, 2013 at 6:19 PM, Paul Kyzivat <[email-masked]> wrote:
> Yes, I understand that should be the case. But from a deployment perspective
> it makes quite a bit of difference which one(s) are actually deployed.
> Signaling in SDP that you can do it either way is incredibly messy, so I
> don't expect to see that.
>
> Practically speaking, bfcp over websocket will probably close the door on
> bfcp over data channel.
[MB] Why specifically do you think this?  [/MB]
> So I think it is important to carefully consider
> which one to pursue.
>

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Mon, 25 Mar 2013 22:33:21 -0400

> [MB] Why specifically do you think this?  [/MB]

I'll go a bit further and say that I think that the BFCP over Websocket IMO is useful and worth pursuing irrespective of whether BFCP over data channel is standardized or not.  I see no reason why these must mutually exclude.

Gonzalo

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 26 Mar 2013 10:07:22 +0100

> websocket relay of some sort.)

Hi Paul, which is the problem with having a relay server? This is WWW
and not SIP physical devices with fixed code. In WWW world, clients
(browsers) connect to a central server (the WWW server, which now can
also be a WebSocket server) and signal with it.

Honestly I don't like the idea of considering a JS application like a
standalone SIP client which does not run in the context of a website,
because that is not the way in which web apps work. So IMHO there is
no advantage at all in having BFCP over data channel. In Web
deployments the server wants to know about what happens in client
side. I strongly discourage the vision of considering a JS application
something like a "desktop softphone". It's not.

Also, BFCP is a "signaling protocol", so let's say "a light protocol".
It can be perfectly carried across central servers,  there is no need
at all for using client-to-client communication (this is not a media
flow but a signaling flow).

In short, I consider having MSRP over DataChannel something useful,
but I consider that any other SIP related protocol (that does not
involve carrying big data) should be implemented over WebSocket and
never over DataChannel. And even more: using DataChannel for
"signaling" breaks the WWW rules because here we are not in SIP land
but in WWW land in which central servers exist and want to be in the
path of the communications between clients.

Best regards.

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

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 26 Mar 2013 21:47:01 +0530

Hi all,

I agree with Paul that BFCP over data channel is preferred because 
BFCP is not related to SIP (focus) but it is more relevant to media 
layer. Irrespective of signaling layer is SIP or HTTP, BFCP shall be 
carried in media layer specific protocols (data channel) rather than 
signaling layer specific protocol (WebSocket). 

In case of the architecture wherein conferenence signaling entity
(like SIP focus) is not physically co-located with RTP mixer, then
RTP Mixer has no need to implement WebSocket for sake of supporting
BFCP over WebSocket.

Thanks
Partha

> Behalf Of Iñaki Baz Castillo
> Sent: Tuesday, March 26, 2013 2:37 PM
> To: Paul Kyzivat
> Cc: [email-masked]

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 26 Mar 2013 17:38:43 +0100

> RTP Mixer has no need to implement WebSocket for sake of supporting

No, it just has to implement DataChannel, which is 100 times more
difficult to implement than WebSocket.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Mar 2013 00:52:37 +0800

>> [MB] Why specifically do you think this?  [/MB]

I question how many alternatives developers will implement.
With bfcp over UDP there are two alternative. Adding websockets makes 
three, and also adding datachannels makes four. The more there are the 
lower the probability both ends will support a common one. And signaling 
support for more than one is difficult. This is already quite a problem 
with three, much less four.

> I'll go a bit further and say that I think that the BFCP over Websocket IMO is useful and worth pursuing irrespective of whether BFCP over data channel is standardized or not.  I see no reason why…

Perhaps the only way this can really work is with a "relay/transcoder".
A webserver hosting an WEBRTC client can insert such a thing to match 
the two sides. It will then "know" the WEBRTC client supports BFCP over 
websocket, and can then apply some knowledge of what the other end 
supports, within limits. If the other end is sip, then it may assume the 
choice is only BFCP over TCP or UDP and construct signaling for that.

Bottom line: I think bfcp over websocket will probably preclude bfcp 
over data channel. (In a practical, not theoretical sense.) The converse 
is also probably true. But most likely a draft for bfcp over websocket 
can be completed sooner, and will fill many needs. In this case fewer is 
better. So I'll stop arguing about it.

	Thanks,
	Paul

---

From: "Avasarala, Ranjit (NSN - IN/Bangalore)" <[email-masked]>
Date: Tue, 26 Mar 2013 17:06:48 +0000

Partha

I really do not think there can be a SIP focus which is just signaling entity, it would also have RTP mixer. 

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Parthasarathi R
Sent: Tuesday, March 26, 2013 9:47 PM
To: 'Iñaki Baz Castillo'; 'Paul Kyzivat'
Cc: [email-masked]
Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt

Hi all,

Thanks
Partha

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Mar 2013 01:24:53 +0800

> something like a "desktop softphone". It's not.

Your argument could also be applied to all the media.
But the point of WEBRTC is to allow the media and the data channels to 
go e2e.

> flow but a signaling flow).

I realize that bfcp is likely to be a low data rate, and so its less of 
a problem for it to go indirectly via the server, but that only makes it 
less bad, it doesn't make it good.

In general its bad to put something in the middle that doesn't need to 
be in the middle.

> path of the communications between clients.

Why doesn't that argument apply to *everything* that might go over a 
data channel?

But please see my earlier reply in this thread. I'm giving up.

	Thanks,
	Paul

---

From: Richard Barnes <[email-masked]>
Date: Tue, 26 Mar 2013 13:25:55 -0400

It may be that implementing WS on the server side is easier than
DataChannel.  However, that's only because there are no libraries available
right now.  WS is not a dream to implement either, but there was enough
interest and people built the libraries.  There's enough interest in
DataChannel that I wouldn't be surprised if the same thing happens.

Thinking about the SDP a little further, however, it seems like DC is nicer
from a WebRTC point of view, but WS is nicer from a backward-compatibility
point of view.

On the one hand: I don't think there's any expectation that a browser would
implement BFCP, so it would have to be done in JS. That would mean that
 the JS would have to manipulate the SDP to add the BFCP offer, look for an
answer, and possibly remove the answer before feeding the SDP back into the
browser.  It's not simple, but it's doable.  DataChannel would be simpler
for JS, since there's already a channel for JS to request data channels,
without manipulating SDP.

On the other hand: There's not really a good syntax for saying "this
DataChannel stream will be used for BFCP".  So adding WS as a transport for
BFCP, on its own M-line, seems like a simpler way to allow for legacy
interoperability.  Legacy implementations would only have to add the WS
transport for BFCP, as opposed to adding another layer of processing on top
of SDP (i.e., identifying DataChannel streams).

--Richard

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 26 Mar 2013 18:28:28 +0100

Hi Paul, just some comments and let us give up this subject ;)

> But the point of WEBRTC is to allow the media and the data channels to go
> e2e.

Right, but still WebRTC clients are web browsers which runs web
applications. I expect that datachannel is good for file transfer,
realtime info (i.e. games) between *browsers*. But having a server
that speaks datachannel seems a bit "complex" IMHO.

> In general its bad to put something in the middle that doesn't need to be in
> the middle.

What I have in mind is that the WebSocket server is co-located in the
conference focus. :)

Regards.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Mar 2013 02:20:30 +0800

On 3/27/13 1:25 AM, Richard Barnes wrote:

> DataChannel stream will be used for BFCP".  So adding WS as a transport
> for BFCP, on its own M-line, seems like a simpler way to allow for
> legacy interoperability.  Legacy implementations would only have to add
> the WS transport for BFCP, as opposed to adding another layer of
> processing on top of SDP (i.e., identifying DataChannel streams).

Hence my interest in the SCTP SDP proposal that *did* have a way to say 
"this DataChannel stream will be used for BFCP" (as well as saying "this 
other DataChannel will be used for CLUE".) But I can live without that 
for now.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Mar 2013 02:32:01 +0800

I think we have some different assumptions...

> What I have in mind is that the WebSocket server is co-located in the

You seem to be assuming a couple of things that I am not:

- that we only care about bfcp with conferences, not p2p calls.

- that the web server supporting a webrtc client is also the conference
   focus when there is a conference.

I don't think either of those is true. Especially not the latter one. 
For instance, I can easily foresee a webserver that provides CLUE 
support to browsers - as a sort of enhanced functionality sip client. It 
would support establishing a session to any other sip UA and provide 
clue functionality whenever both ends support it. Sometimes the other 
end will be a clue conference focus. Sometimes it will be another 
clueful endpoint.

If websocket support is required to support bfcp in this context, then 
the webrtc server will need to provide a websocket relay/gateway to 
connect to the other clue endpoint.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 26 Mar 2013 23:22:19 +0100

> - that we only care about bfcp with conferences, not p2p calls.

I must recognize that I don't know BFCP well enough. Not sure about
what is the purpose of BFC in p2p calls.

> I don't think either of those is true. Especially not the latter one. For
> instance, I can easily foresee a webserver that provides CLUE support to
> browsers - as a sort of enhanced functionality sip client. It would support
> establishing a session to any other sip UA and provide clue functionality
> whenever both ends support it. Sometimes the other end will be a clue
> conference focus. Sometimes it will be another clueful endpoint.
>
> If websocket support is required to support bfcp in this context, then the
> webrtc server will need to provide a websocket relay/gateway to connect to
> the other clue endpoint.

I understand your point. Just as a side note, nothing prevents a JS
app running in a browser to make more than a single WebSocket
connection against different servers (i.e. a WS connection with a SIP
server and another WS connection with a BFCP server/relay/gateway.

Regards.

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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 26 Mar 2013 23:39:33 +0100

> - that we only care about bfcp with conferences, not p2p calls.

While BFCP can be used in p2p calls, I don't think it is its main use 
case, from the RFC:

Scope

    As stated earlier, BFCP is a protocol to coordinate access to shared
    resources in a conference following the requirements defined in [9].
    Floor control complements other functions defined in the XCON
    conferencing framework [10].

Also, coordinating the access to a shared resource between two parties 
in which one of them has the ownership of the resource doesn't seem 
quite a big deal.

> support to browsers - as a sort of enhanced functionality sip client. 
> It would support establishing a session to any other sip UA and 
> provide clue functionality whenever both ends support it. Sometimes 
> the other end will be a clue conference focus. Sometimes it will be 
> another clueful endpoint.
>

Why it is needed that the web server is also the focus server? My MCU 
has different components for SIP handing and media mixing and web server 
for the web client HTML and it is order of magnitude implementing web 
sockets (even from scratch) than supporting datachannels at all.

Best regards
Sergio

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 26 Mar 2013 23:12:24 +0000

> Behalf Of Sergio Garcia Murillo
> Sent: Tuesday, March 26, 2013 3:40 PM
> To: [email-masked]

I agree that coordination between two parties is easier than among many parties. That said, with SIP based video conferencing implementations, the same coordination is used for both cases. The determination of which side owns which resource is via SDP, and the real-time request and granting of the resource is via BFCP. For sessions between an endpoint and a conference focus, the conference focus typically requires that it be the owner of the content sharing resource. For point to point calls, it could be either endpoint assuming this role. This way the same SDP negotiation and BFCP messaging is used consistently for both conference and point to point calls.

Cheers,
Charles

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 27 Mar 2013 00:28:41 +0100

> I agree that coordination between two parties is easier than among many parties. That said, with SIP based video conferencing implementations, the same coordination is used for both cases. The dete…

I agree that having the same sollution for p2p and conference would be a 
nice to have. But, in my opinion implementing the logic on top of BFCP 
is the hard part for the client side. Given than the JS interface for 
websockets and datachannel is very similar (only setup is different), it 
will be fairly trivial for clients to support BOTH transport protocols 
and select which one to use depending on the SDP negotiation.

Best regards
Sergio

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 27 Mar 2013 19:38:37 +0000

> From: Sergio Garcia Murillo
> Sent: Tuesday, March 26, 2013 6:29 PM

> I agree that having the same sollution for p2p and conference would be
> a nice to have. But, in my opinion implementing the logic on top of
> BFCP is the hard part for the client side. Given than the JS interface
> for websockets and datachannel is very similar (only setup is
> different), it will be fairly trivial for clients to support BOTH
> transport protocols and select which one to use depending on the SDP
> negotiation.

We might want to consider this in a wider context, as there are other protocols we should consider for WS (websockets) or DC (data channel) transport, e.g., T140 and MSRP.  P2P is more common with these protocols, where DC makes more sense.  While WS can be used for e2m and legacy scenarios, it seems preferable even here to use DC to enable muxing with other media.  Even though a client could support both, DC can be more efficient in most cases.  

> From: Richard Barnes
> Sent: Tuesday, March 26, 2013 12:26 PM

> DataChannel.  However, that's only because there are no libraries
> available right now.  WS is not a dream to implement either, but there
> was enough interest and people built the libraries.  There's enough
> interest in DataChannel that I wouldn't be surprised if the same thing
> happens.
...
 
> processing on top of SDP (i.e., identifying DataChannel streams).

I'm not sure that there is a significant difference in complexity between adding a BFCP over WS m-line to SDP compared to inserting a BFCP over DC stream attribute within the DC m-line.  The only difference I can fathom is that the latter requires finding the DC m-line within the SDP to insert the additional attribute while the former can just be appended.

There also seems to be an assumption here that p2p scenarios could not benefit from having the option to use SDP to negotiate the use of BFCP (or other protocols) on a DC.  In p2p cases where the peers execute different webrtc applications, it would be an advantage to discover up front during the offer/answer exchange which DC protocols can be supported before doing all the work to set up ICE, DTLS and the SCTP association.  While many p2p connections will be based on running the same application in both peers, do we need to mandate or even assume this?

I would prefer to have the option to signal the use of BFCP (and other protocols) over DC within SDP.  There is no need to define the SDP extension needed to do this until the first time we define how to transport BFCP (or some other protocol) over DC.

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 31 Mar 2013 22:06:46 +0530

Ranjit,

As we discussed in offline, SIP focus and RTP mixer shall exists physically different devices. It is possible to achieve using Sec 3.3. of draft-ietf-bfcpbis-rfc4582bis mechanism or H.248.

Thanks
Partha 

> From: Avasarala, Ranjit (NSN - IN/Bangalore)
> [mailto:[email-masked]]
> Sent: Tuesday, March 26, 2013 10:37 PM
> To: ext Parthasarathi R; 'Iñaki Baz Castillo'; 'Paul Kyzivat'
> Cc: [email-masked]
> Subject: RE: [dispatch] FW: New Version Notification for draft-pascual-
> Behalf Of ext Parthasarathi R

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 31 Mar 2013 22:26:29 +0530

I could not understand how 100 times tougher to implement in datachannel.

Please note that Conference RTP mixer products has to handle datachannel
When they support RTCWeb. So, it is not so tough to implement. OTOH, 
RTP Mixer may not have HTTP server itself wherein implementing/maintaining
Websocket application is real overhead.

> From: Iñaki Baz Castillo [mailto:[email-masked]]
> Sent: Tuesday, March 26, 2013 10:09 PM
> To: Parthasarathi R
> Cc: Paul Kyzivat; [email-masked]