Subject: [dispatch] Fwd: Interest and need for Websocket subprotocol - JSEP over websockets

From: [email-masked]
Date: Thu, 04 Dec 2014 09:44:54 -0600

Hi

With websockets as a de-facto transport protocol for WebRTC signaling 
and JSEP being the format of encoding information, there is a need for a 
defining a websocket sub-protocol : jsep. So I would like to know if 
there is any interest in the community and also the views from experts 
about the need for a websocket-sub protocol for JSEP.

The main purpose of defining the sub protocol (jsep) is to make sure 
that the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving 
JSEP encoded messages.

Note: I had initially posted this topic on rtcweb mailing list and there 
I was suggested that rtcweb is not the appropriate mailing list to 
discuss this topic.

Thanks
Ranjit

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 4 Dec 2014 16:55:05 +0000

Hi Ranjit

On Dec 4, 2014, at 5:44 PM, [email-masked] wrote:

> Hi
> 
> With websockets as a de-facto transport protocol for WebRTC signaling and JSEP being the format of encoding information, there is a need for a defining a websocket sub-protocol : jeep.

actually this need is not completely clear to me yet!

> So I would like to know if there is any interest in the community and also the views from experts about the need for a websocket-sub protocol for JSEP.
> 
> The main purpose of defining the sub protocol (jsep) is to make sure that the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving JSEP encoded messages.
> 
> Note: I had initially posted this topic on rtcweb mailing list and there I was suggested that rtcweb is not the appropriate mailing list to discuss this topic.

is there any specific reason why you want to transfer directly JSEP ?
i.e. any reason you cannot use SIP over WebSocket?

br
Salvatore

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 4 Dec 2014 18:24:38 +0100

2014-12-04 16:44 GMT+01:00  <[email-masked]>:
> With websockets as a de-facto transport protocol for WebRTC signaling and
> JSEP being the format of encoding information, there is a need for a
> defining a websocket sub-protocol : jsep. So I would like to know if there
> is any interest in the community and also the views from experts about the
> need for a websocket-sub protocol for JSEP.
>
> The main purpose of defining the sub protocol (jsep) is to make sure that
> the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving JSEP
> encoded messages.
>
> Note: I had initially posted this topic on rtcweb mailing list and there I
> was suggested that rtcweb is not the appropriate mailing list to discuss
> this topic.

Yes, but what you ignore here is all the rationale already given to
you in the rtcweb mailing list. Not sure if you don't understand the
received feedback or you just prefer to ignore it because you still
think that "JSEP over WebSocket" is a need.

Link to your thread in rtcweb:

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

Summarizing: In contrast to what you suggest, JSEP is just about
signaling SDPs between peers and between devices and the W3C WebSocket
API. In the rtcweb thread you also request for "adding more info to
JSEP messages in order to indicate caller, called and so on". OK, you
could create a new signaling protocol with headers (similar to HTTP)
and attach the SDP in the body. Then add some kind of "From" and "To"
headers to identity parties. You can call it "SIP".

Please, leave it.

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

---

From: [email-masked]
Date: Thu, 04 Dec 2014 13:57:01 -0600

Hi Salvatore

it is actually not practical to support a full fledged SIP stack in web 
browsers. SO there are implementations or proposals which say that a 
basic SIP stack with a small footprint is needed in web browsers. now it 
is really difficult to decide on what features of SIP are needed and 
which of them are not needed. so it boils down the issue of how much SIP 
do we support in web browsers. so it is ideally better not to support 
SIP in web browsers, and instead use Java script based notation i.e JSON 
format for exchanging signaling information.  I am not proposing the 
term "JSEP" as it is misleading, but my intent to send the following 
required information like
1) call initiation with initial offer,
2) call acceptance,
3) call termination and
4) basic call features like hold / resume

the above information would go as JSON messages over Websocket 
connection. now both the web browser client and web server understand 
websockets and have established the connection too. so now they can also 
exchange JSON messages - just like SIP or XMPP.  so when we have 
websocket sub-protocol types for SIP and XMPP, it is ideal to have a 
sub-protocol type for JSON as well.

some of the benefits of indicating the message type as JSON
1. the web server receiving the message would know the message type as 
JSON and redirect it to a particular converter - e.g JSON to SIP or JSON 
to XMPP
2. the state machine on client side would be lean and the parser / 
builder logic too would be small - unlike SIP parser / builder
3. JSON being a generic format is not tied to any specific protocol and 
hence web browsers too need not care about signaling protocols like SIP, 
H.323, etc. it will be the job of WebRTC GW to do the
    required conversion
4. JSON allows Use of Web identity which can be authenticated by any 
Auth server - unlike SIP where only a sip url needs to be used and 
public auth servers like Google, Linkedin, Facebook cannot
    authenticate.

Note: my main intent is to ease the building / parsing logic on web 
browsers so that they remain lite while the GWs can take additional load 
of protocol conversion.

comments welcome

Regards
Ranjit

On 2014-12-04 10:55 am, Salvatore Loreto wrote:
>> and JSEP being the format of encoding information, there is a need for 
>> a defining a websocket sub-protocol : jeep.
> 
> 
>> So I would like to know if there is any interest in the community and 
>> also the views from experts about the need for a websocket-sub 
>> protocol for JSEP.
>> 
>> Note: I had initially posted this topic on rtcweb mailing list and 
>> there I was suggested that rtcweb is not the appropriate mailing list 
>> to discuss this topic.
>

---

From: [email-masked]
Date: Thu, 04 Dec 2014 14:12:53 -0600

Hi Inaki

I understand your concern of using the word "JSEP". That is fine - the 
word can be changed to some other suitable name. but my intent is that 
using SIP over Websockets has several disadvantages. some of them are
1. to use SIP over Websockets, WICs which can also be web browsers need 
to support SIP stack. which I do not think any web browser vendor would 
do
2. if we use SIP, then we cannot use the standard web identities and 
cannot use standard auth servers for authentication. this defeats the 
purpose of using web identity. Ideally I should be able to use my
    web identity - e.g [email-masked] / [email-masked] / 
[email-masked] , etc to make web calls and operators could use 
standard auth servers to authenticate and validate my identity. once
    authenticated and validated, the operators can do create a sip 
identity for me and use that subsequently.

the format of messages would be JSON over a websocket connection. so the 
name of the protocol need not be JSEP as many have reservations with it, 
but a more suitable name would be better.

Regards
Ranjit

On 2014-12-04 11:24 am, Iñaki Baz Castillo wrote:
>> and
>> there
>> that
>> there I

---

From: Tim Panton new <[email-masked]>
Date: Thu, 4 Dec 2014 20:27:32 +0000

> On 4 Dec 2014, at 20:12, [email-masked] wrote:
> 
> 
> Hi Inaki
> 
> I understand your concern of using the word "JSEP". That is fine - the word can be changed to some other suitable name. but my intent is that using SIP over Websockets has several disadvantages. some of them are
> 1. to use SIP over Websockets, WICs which can also be web browsers need to support SIP stack. which I do not think any web browser vendor would do

Have you taken a look at the following : http://jssip.net <http://jssip.net/> , http://sipjs.com <http://sipjs.com/> , http://sipml5.org <http://sipml5.org/> - all of which implement SIP in the browser. 

> 2. if we use SIP, then we cannot use the standard web identities and cannot use standard auth servers for authentication. this defeats the purpose of using web identity. Ideally I should be able to use my
>   web identity - e.g [email-masked] / [email-masked] / [email-masked] , etc to make web calls and operators could use standard auth servers to authenticate and validate my identity. once
>   authenticated and validated, the operators can do create a sip identity for me and use that subsequently.

Yep - all of the above can do that, should you want to….

> 
> the format of messages would be JSON over a websocket connection. so the name of the protocol need not be JSEP as many have reservations with it, but a more suitable name would be better.

In the spirit of the IETF (rough consensus and running code),
you might like to write a little javascript library that implements the protocol you feel you need and illustrate how it differs from draft-ibc-sipcore-sip-websocket <http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket> .

Tim.

---

From: [email-masked]
Date: Thu, 04 Dec 2014 14:38:03 -0600

Hi Tim

my point was implementing SIP natively in browser without the need to 
use additional JS libraries. so e.g. chrome or IE may not support SIP 
natively. so you need to install JS libraries. so the features you use 
depend on the JS library you use.

Regards
Ranjit

On 2014-12-04 2:27 pm, Tim Panton new wrote:
>> I understand your concern of using the word "JSEP". That is fine -
>> the word can be changed to some other suitable name. but my intent
>> is that using SIP over Websockets has several disadvantages. some of
>> them are
>> 1. to use SIP over Websockets, WICs which can also be web browsers
>> need to support SIP stack. which I do not think any web browser
>> vendor would do
> 
> Have you taken a look at the following : http://jssip.net [2] ,
> http://sipjs.com [3] , http://sipml5.org [4] - all of which implement
> SIP in the browser.
> 
>> cannot use standard auth servers for authentication. this defeats
>> the purpose of using web identity. Ideally I should be able to use
>> my
>> the format of messages would be JSON over a websocket connection. so
>> the name of the protocol need not be JSEP as many have reservations
>> with it, but a more suitable name would be better.
> 
> you might like to write a little javascript library that implements
> the protocol you feel you need and illustrate how it differs from
> draft-ibc-sipcore-sip-websocket [5] .
> 
> Tim.
> 
>> Regards
>> Ranjit
>> 
Hi Tim

>> [1]
> Links:
> ------
> [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13602.html
> [2] http://jssip.net
> [3] http://sipjs.com
> [4] http://sipml5.org
> [5] http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 4 Dec 2014 22:44:34 +0100

2014-12-04 21:12 GMT+01:00  <[email-masked]>:
> Hi Inaki
>
> I understand your concern of using the word "JSEP". That is fine - the word
> can be changed to some other suitable name. but my intent is that using SIP
> over Websockets has several disadvantages. some of them are

> 1. to use SIP over Websockets, WICs which can also be web browsers need to
> support SIP stack. which I do not think any web browser vendor would do

If those WICs are web browsers then they have WebSocket and can run
JavaScript, so they can run a JavaScript SIP stack.

> 2. if we use SIP, then we cannot use the standard web identities and cannot
> use standard auth servers for authentication. this defeats the purpose of
> using web identity. Ideally I should be able to use my
> [email-masked] , etc to make web calls and operators could use standard
> auth servers to authenticate and validate my identity. once

Sorry, but this is 100% wrong. I use JsSIP library (JavaScript SIP
over WebSocket) and authenticate/authorize by using HTTP Cookies,
OAuth, etc etc. In fact I usually avoid using SIP/HTTP Digest
authentication.

So I strongly contradict your bullet #2.

> name of the protocol need not be JSEP as many have reservations with it, but
> a more suitable name would be better.

JSON is of course more suitable for browsers given that a JSON message
is mapped into a JavaScript object and vice-versa. In contrast, in
server side (the SIP server written in C, C+, Java, etc) using a
HTTP-or-SIP like message format may be faster for parsing purposes.

Said that, I run JsSIP even in Cordova apps with no performance problems at all.

Anyhow, feel free to design a new signaling protocol. But please note
that if two protocols are compatible then they are the same protocol.
So if your aim is to make such a new protocol 1-1 mappable to SIP then
it will be SIP (regardless it uses a JSON format instead of HTTP like
headers).

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 4 Dec 2014 22:47:47 +0100

2014-12-04 21:38 GMT+01:00  <[email-masked]>:
> my point was implementing SIP natively in browser without the need to use
> additional JS libraries. so e.g. chrome or IE may not support SIP natively.
> so you need to install JS libraries. so the features you use depend on the
> JS library you use.

Sorry, I don't fully understand this point. Do you mean that you want
SIP (or something 1-1 mappable to SIP) natively built in browsers so
you don't "need" JavaScript libraries?

If so:

1. Browsers are not phones.
2. Browsers run JavaScript. Use it.
3. No browser vendor will do that NEVER.

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

---

From: [email-masked]
Date: Thu, 04 Dec 2014 20:57:13 -0600

Hi Inaki

It is not that I want to develop a new protocol and map it to SIP, that 
is of no use, I too agree. All I am trying to say is that since JSON 
messages are already used for exchanging information, why can't we have 
the sub-protocol type as "JSON". This will simplify things both on 
client and server side.  What we send in JSON can be SIP messages - but 
they do not go as SIP, but as JSON.

Regards
Ranjit

On 2014-12-04 3:44 pm, Iñaki Baz Castillo wrote:
>> word
>> need to
>> cannot
>> standard
>> the

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 8 Dec 2014 18:57:26 +0100

2014-12-05 3:57 GMT+01:00  <[email-masked]>:
> It is not that I want to develop a new protocol and map it to SIP, that is
> of no use, I too agree. All I am trying to say is that since JSON messages
> are already used for exchanging information, why can't we have the
> sub-protocol type as "JSON".

JSON is NOT a protocol, but a message format. There is no protocol
called XML, YAML, INI, so nor JSON.

> This will simplify things both on client and
> server side.  What we send in JSON can be SIP messages - but they do not go
> as SIP, but as JSON.

I do not see any value in that proposal, but again, feel free to write
a draft and implementations.

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

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 09 Dec 2014 16:28:57 -0500

Iñaki Baz Castillo <[email-masked]> writes:
>> This will simplify things both on client and server side.  What we
>> send in JSON can be SIP messages - but they do not go as SIP, but as
>> JSON.
>

This is true:  The proper test is to write a proposal (that explains
the protocol and why it is useful) and see how many people express
support of it.

Dale