Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket

From: Mary Barnes <[email-masked]>
Date: Mon, 1 Apr 2013 10:48:40 -0500

Partha,

It's not entirely clear to me that RTCWEB is the "compelling" use case
for MSRP over websockets.  I'd be interested to hear who might think
that is the case.  I can envision other Real Time applications using
web servers to make use of this, as well.

I don't see any requirements in the RTCWEB WG (charter or
requirements) that indicate this is a compelling use case:
http://www.ietf.org/id/draft-ietf-rtcweb-use-cases-and-requirements-10.txt
There are no use cases for IM, Chat or MSRP specifically that I could
find and I couldn't find anything in the RTCWEB archives:
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10
If there has been discussion, please provide a pointer.

The discussion of MSRP over websockets should continue on this mailing
list.  Per the dispatching of IETF-86 topics, the current proposal is
to AD sponsor this document unless there are very compelling reasons
not to publish.
http://tools.ietf.org/wg/dispatch/trac/wiki

The proposal had been for the general discussion of "foo" over
websockets to happen on the RAI list.    The last I looked there are
at least 200 people subscribed to DISPATCH that are not on the RAI
area mailing list.  I strongly encourage folks with an interest in the
topic to make sure they are subscribe to the RAI area mailing list:
https://www.ietf.org/mailman/listinfo/rai

Regards,
Mary.

On Sun, Mar 31, 2013 at 11:52 AM, Parthasarathi R
<[email-masked]> wrote:
> The compelling reason for this draft is RTCWeb. In case of non-RTCWeb,
> TCP Shall be used which avoids the overhead introduced due to
> WebSocket. Please clarify in case WebSocket has some specific
> advantage over TCP in non-RTCWeb environment.
>
> In case dispatch or BFCPbis are not the right WG to make recommendation,
> then let us discuss in RTCWeb WG itself. Also, Please suggest if any
> other mailing list like ([email-masked]) is the right place to discuss.
>
> Thanks
> Partha
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Mary Barnes
>> Sent: Thursday, March 28, 2013 8:28 PM
>> To: DRAGE, Keith (Keith)
>> Cc: [email-masked]
>> Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or
>> websocket
>>
>> I don't think it's the job of dispatch or BFCPbis WG to define or even
>> make recommendations for RTCWEB.  That choice is up to the RTCWEB WG
>> and it shouldn't be influencing this work.  There are applications
>> other than RTCWEB that can and will make use of BFCPbis over
>> websockets.  I really don't understand why we are getting so hung up
>> on this - it's the BFCP messages themselves that are important - how
>> one chooses to transport is up to the application.
>>
>> Mary.
>>
>> On Thu, Mar 28, 2013 at 7:35 AM, DRAGE, Keith (Keith)
>> <[email-masked]> wrote:
>> > From what I have seen of the discussion so far, there appears to be a
>> body of support that there is a use case for both BFCP and MSRP over
>> websocket, for use in a non-rtcweb environment.
>> >
>> > If when we get to the rtcweb environment we allow this, and also
>> allow a usage over datachannel version, we essentially have two
>> solutions in the market place.
>> >
>> > If that occurs, what guidance will we give to a rtcweb developer as
>> to which to implement?
>> >
>> > Or do we envisage that only one will be allowed (and if so which) in
>> an rtcweb environment?
>> >
>> >
>> >
>> > Regards
>> >
>> > Keith
>> > _______________________________________________
>> > 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: "Parthasarathi R" <[email-masked]>
Date: Mon, 1 Apr 2013 22:41:55 +0530

Mary,

I think that my point on RTCWEB does not come out well.
Browser has the limitation of including TCP applications (like 
BFCP over TCP) directly. To achieve this Datachannel or WebSocket 
Shall be used which is under discussion here. As you mentioned, 
RTCWeb WG does not cover these usecases. The discussion 
required in RTCWeb WG whether BFCP and MSRP usecase are qualified
as usecase or as the additional usecase (sec 8 of 
draft-ietf-rtcweb-use-cases-and-requirements-10) as other 
conference related usecases exist in additional usecase already. 

Please note that browser limitation does not apply for the generic
Web (HTTP) client. In your envisioned Real time applications using 
web servers, web client shall use TCP for BFCP & MSRP as web client
MUST support TCP protocol. It is not clear to me why websocket is
required for those real time applications. 

As you suggest, Let us discuss in RAI for further discussion on
"foo" over WebSocket or Datachannel.

Thanks
Partha

> From: Mary Barnes [mailto:[email-masked]]
> Sent: Monday, April 01, 2013 9:19 PM
> To: Parthasarathi R
> Cc: DRAGE, Keith (Keith); DISPATCH

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 2 Apr 2013 13:50:31 +0200

2013/3/31 Parthasarathi R <[email-masked]>:
> The compelling reason for this draft is RTCWeb.

Why? where did you get such a conclusion from?

> In case of non-RTCWeb,
> then let us discuss in RTCWeb WG itself.

The RTCWeb WG has nothing to do with *what* is sent over a DataChannel
communication.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 2 Apr 2013 14:02:01 +0200

> conference related usecases exist in additional usecase already.

You can send BFCP messages over WebSocket and you can also send them
over a WebRTC DataChannel "connection". So this is not a "WebRTC use
case" that should be defined in
draft-ietf-rtcweb-use-cases-and-requirements because anyone can send
*whatever* he wants over a DataChannel connection or over a WebSocket
connection.

Please don't disturb the RTCWEB WG with BFCP stuff.

> In your envisioned Real time applications using
> MUST support TCP protocol.

"web client MUST support TCP protocol" ??

Sorry but, is that a joke? It's obvious that a web browser cannot open
a raw TCP connection, that's why we need WebSocket as the *standard*
realtime and bidirectional communication mechanism for applications
running in web browsers.

> It is not clear to me why websocket is

Realtime bidirectional communication from browser to server and vice
versa. What other *standard* mechanism you know for realtime
bidirectional communication in web applications? Please let me know
(reply please).

Regards.

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

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 3 Apr 2013 21:59:08 +0530

Inaki,

As Mary suggested, Let us discuss data channel vs WebSocket in
RAI list.

Please look into snip from your earlier mail which answer your 
own query of Why BFCP over Websocket has to be discussed in RTCWeb 
WG.

<snip1>
anyone can send
> Please don't disturb the RTCWEB WG with BFCP stuff.
</snip1>

<snip2>  It's obvious that a web browser cannot open
> running in web browsers. </snip2>

Thanks
Partha

> From: Iñaki Baz Castillo [mailto:[email-masked]]
> Sent: Tuesday, April 02, 2013 5:32 PM
> To: Parthasarathi R
> Cc: Mary Barnes; DISPATCH

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 3 Apr 2013 19:27:31 +0200

Thanks Partha. As I expected you don't reply to my question (you never do

Regards.

2013/4/3 Parthasarathi R <[email-masked]>

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 3 Apr 2013 19:30:06 +0200

> own query of Why BFCP over Websocket has to be discussed in RTCWeb

Regardless to this, as you know "SIP over WebSocket" (
http://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket/) is in
Last Call status, and we required nothing from RTCWEB WG for that, so the
same for "BFCP over WebSocket" or "Anything related to SIP over WebSocket".

Best regards.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Apr 2013 05:01:32 +0800

On 4/4/13 1:27 AM, Iñaki Baz Castillo wrote:
> Thanks Partha. As I expected you don't reply to my question (you never
> do it). Please let me try it again:
>
>

I see a significant difference between "media" streams such as msrp and 
bfcp, and the sip over websocket spec.

For sip over websocket there is little expectation that the target of 
the websocket is the ultimate destination. It is more likely to be an 
outbound proxy. So interop with peers that aren't web servers is preserved.

That may be true for msrp too, since a caller-specific msrp relay can be 
used to ensure interop.

It is more of a problem for bfcp, since AFAIK there is no spec for a 
bfcp relay. In general you can't know in advance if the peer in your sip 
call is a web server, so you can't depend on being able to set up a 
websocket to that peer.

I am not decided on what is the right answer for bfcp. But I have 
succeeded in getting the issue discussed more widely.

	Thanks,
	Paul

> Regards.
>
>
>
> 2013/4/3 Parthasarathi R <[email-masked]
> <mailto:[email-masked]>>
>
>     Inaki,
>
>      > From: Iñaki Baz Castillo [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      > 2013/4/1 Parthasarathi R <[email-masked]
>     <mailto:[email-masked]>>:
>      > >
>      > <[email-masked] <mailto:[email-masked]>>
>
>
>
>
> --
> Iñaki Baz Castillo
> <[email-masked] <mailto:[email-masked]>>
>
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 3 Apr 2013 23:36:31 +0200

2013/4/3 Paul Kyzivat <[email-masked]>
> I see a significant difference between "media" streams such as msrp and bfcp, and the sip over websocket spec.
>
> For sip over websocket there is little expectation that the target of the websocket is the ultimate destination. It is more likely to be an outbound proxy. So interop with peers that aren't web servers is preserved.
>
> That may be true for msrp too, since a caller-specific msrp relay can be used to ensure interop.

Agreed.

> It is more of a problem for bfcp, since AFAIK there is no spec for a bfcp relay. In general you can't know in advance if the peer in your sip call is a web server, so you can't depend on being able to set up a websocket to that peer.

It could be just a WebSocket server (without Web component) but it
changes nothing. I agree with your point and, may be what it would
make sense is to (also) define the concept of BFCP relay.

> I am not decided on what is the right answer for bfcp. But I have succeeded in getting the issue discussed more widely.

Using BFCP over DataChannel would not help a lot here since,
obviously, a WebRTC browser/client would not be able to establish a
BFCP session with a non WebRTC client (i.e. a "common" SIP device).
So, again, the concept of a BFCP relay seems needed regardless
WebSocket or DataChannel is defined for transporting BFCP data.

Anyhow, and trying to be realistic: are there *real* use cases in
which BFCP is talked directly between SIP endpoints (instead of "SIP
endpoint <--> SIP conference server")? I expect (and may be I'm wrong)
that the answer is "no" so, in that case, defining BFCP over WebSocket
seems a much more appropriate, easy to implement and realistic
approach (implementing a WebSocket interface in a server is much more
easier than implementing a WebRTC DataChannel client, which involves
SCTP over DTLS over UDP).

Regards.

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

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 3 Apr 2013 23:58:21 +0200

On Wed, 3 Apr 2013 23:36:31 +0200

> SCTP over DTLS over UDP).

I do agree on your realistic view (more on that below), but I also do share Paul's confusion in part... to digress a little, I remember there was some debate at the time when BFCP was being specified, about where a floor control server was to be deployed in a conferencing environment: some (including me) thought it better colocated with the application server (the one handling the application logic), others with the media server (the one enforcing the decisions). This new discussion partly seems to take the same way, especially if we rephrase it in slightly a different way: is BFCP more of a "signalling" protocol, or a media protocol? The very fact that BFCPBIS is completing the works on a UDP transport for BFCP makes this question less easy to answer to.

I still think it's closer to the former as, wherever decisions are taken, there's application logic enforcing something at the media level (which is how we implemented it as well, by the way). This makes me more keen to view a websocket approach being used for BFCP, especially if we assume the floor control server somewhere on the server side and as such not colocated with any of the WebRTC-compliant browsers: this is similar to how we currently implement the web based interface to our conferencing platform, where simple HTTP interactions are used to wrap a BFCP participant that is originated server side, and it seems to work fine for our needs. Besides, as you say, no change needed on legacy devices as they'd keep on "talking" BFCP with the FCS the old way.

That said, though, I may have this view because of how, just as you, I'm currently associating BFCP with the conferencing world (well, it was born in XCON after all), which may be a wrong assumption: people may be using BFCP for entirely different scenarios as well, and the example made by someone a few posts ago (I think it was Victor but I may be wrong) about one of two peers acting as the floor control server in a call may be a perfectly valid scenario for it being used differently than what I'm used to. I also remember Adam Roach proposing a Call Completion service based on BFCP a few years ago, which is just another scenario that may change the roles a bit.

Such a shift in the roles may very well motivate a use of datachannels for BFCP as well, especially if we think of scenarios where no centralized control will be needed, or at least no centralized control outside of the WebRTC peers that are part of the conversation. Of course, if an application DOES need some control on the server side, this means that this server would need to implement the backend of a datachannel; and yes, it would make things definitelt harder when interoperating with legacy devices, but as some seem to advocate, WebRTC should be a fresh start, and should not look back too much. Whether this would be a dealbreaker for some I don't know, but I guess that, as there already are non-browser WebRTC implementations for media out there, it won't be long before datachannels will be handled as well: maybe it won't be optimal, but someone will make it work one way or the other.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: Victor Pascual Avila <[email-masked]>
Date: Thu, 4 Apr 2013 07:40:03 +0200

On Wed, Apr 3, 2013 at 11:58 PM, Lorenzo Miniero <[email-masked]> wrote:
> That said, though, I may have this view because of how, just as you, I'm currently associating BFCP with the conferencing world (well, it was born in XCON after all), which may be a wrong assumption: people may be using BFCP for entirely different scenarios as well, and the example made by someone a few posts ago (I think it was Victor but I may be wrong) about one of two peers acting as the floor control server in a call may be a perfectly valid scenario for it being used differently than what I'm used to.

It was not me -- all my use cases include a conf server. On the client
side, we have WebRTC and non-WebRTC web endpoints (all of them
supporting WebSockets already) as well as "legacy" BFCP devices.

Cheers,
-Victor

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 4 Apr 2013 08:18:30 +0200

On Thu, 4 Apr 2013 07:40:03 +0200

> supporting WebSockets already) as well as "legacy" BFCP devices.

Ops you're right, sorry about that! As they say here in Napoli, "that's how you send people to jail" :-)

I just checked the archives and it was Charles Eckel that referred to the possibility in a couple of posts.

Cheers,
Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 04 Apr 2013 11:04:32 +0200

> supporting WebSockets already) as well as "legacy" BFCP devices.

Also, there will be use cases for BFCP endpoints not involved in the 
media flow at all.

Best regards
Sergio

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 5 Apr 2013 22:09:10 +0000

> Behalf Of Lorenzo Miniero
> Sent: Wednesday, April 03, 2013 11:19 PM
> To: Victor Pascual Avila
> Cc: [email-masked]
> Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket
> 
> > > That said, though, I may have this view because of how, just as you, I'm
> currently associating BFCP with the conferencing world (well, it was born in
> XCON after all), which may be a wrong assumption: people may be using
> BFCP for entirely different scenarios as well, and the example made by
> someone a few posts ago (I think it was Victor but I may be wrong) about
> one of two peers acting as the floor control server in a call may be a
> perfectly valid scenario for it being used differently than what I'm used to.
> >

Yes, and I still stand by BFCP being useful and implemented for point to point and peer to peer use cases, not just for conference calls between a client and a conference server. If you want additional details, please have a look at the following IMTC Best Practice shared with the IETF through a liaison statement last year:
https://datatracker.ietf.org/documents/LIAISON/liaison-2012-05-31-imtc-the-ietf-imtc-work-on-sip-feature-parity-with-h323-attachment-3.pdf

That said, I am not saying BFCP over websockets is a bad idea. Rather, I am saying it is not sufficient for all the use cases for which BFCP is used today. Perhaps that is okay, and we just need to define something else for the other use cases, and applications need to know when to use one method as opposed to another. This adds complexity other than that of implementing BFCP over websockets.

Cheers,
Charles

---

From: Mary Barnes <[email-masked]>
Date: Sun, 7 Apr 2013 13:32:08 -0500

> That said, I am not saying BFCP over websockets is a bad idea. Rather, I am saying it is not sufficient for all the use cases for which BFCP is used today. Perhaps that is okay, and we just need to…
[MB] Right. I don't think anyone's suggesting BFCP over websockets
would subsume other usages.  We have different application
environments that need some of the same building blocks, but the
flexibility in "transports" is a good thing IMHO. [/MB]

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Sun, 7 Apr 2013 20:25:12 +0000

On Apr 7, 2013, at 2:32 PM, "Mary Barnes" <[email-masked]> wrote:

 <snip>

> flexibility in "transports" is a good thing IMHO. [/MB]

This is pretty much my same feeling on this.  There are customer use cases, proven instances where it is the superior solution, and it plays nicely with legacy implementations.  I see no reason not to pursue this, despite any (IMO grossly overestimated) perceived additional complexity introduced as a result of an additional transport choice.

Gonzalo

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 15 Apr 2013 12:14:41 +0000

It appears to me that we are fine in the area of non-WebRTC usage. We know what we are doing.

When it comes to webRTC usage, then we have two options. That implies to me either this document needs to include considerations of why it might be used rather than the data channel versus webrtc, or it needs to be decided that some other document should cover it - but webrtc owns no such document.

Dispatch to me needs to decide whether this document should have those considerations, or whether some other document should be provided.

Regards

Keith

> Sent: 28 March 2013 14:58
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> > If when we get to the rtcweb environment we allow this, and also allow a
> usage over datachannel version, we essentially have two solutions in the
> market place.
> >
> > If that occurs, what guidance will we give to a rtcweb developer as to
> which to implement?
> >
> > Or do we envisage that only one will be allowed (and if so which) in an
> rtcweb environment?
> >
> >
> >
> > Regards
> >
> > Keith

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Apr 2013 14:27:08 +0200

> Dispatch to me needs to decide whether this document should have those considerations, or whether some other document should be provided.

I agree.

Just one consideration more: This draft is just intended for a BFCP
WebSocket Client to establish a BFCP session with a BFCP WebSocket
Server (terms defined within the drat [*]), thus the draft should
state that it's not possible for a BFCP WebSocket Client to establish
a session with another BFCP WebSocket Client or with any other BFCP
peer that is not a BFCP WebSocket Server (and given WebSocket nature I
don't expect at all that there will be BCFP nodes behaving as both a
WS client and a WS server).

Another option would be defining the concept of "BCFP relay server"
but IMHO that is out of the scope of this specification. May be
another document for this purpose?

Regards.

[*] http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00#section-2.1

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

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Mon, 15 Apr 2013 11:56:53 -0400

>> Dispatch to me needs to decide whether this document should have those considerations, or whether some other document should be provided.

+1

Having a section in this document discussing typical use cases, scope, limitations and advantages/disadvantages of other similar  transport mechanisms seems entirely reasonable for this document.

> another document for this purpose?

I think this is a future consideration for another document.

Gonzalo