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

From: [email-masked]
Date: Wed, 03 Dec 2014 12:31:59 -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.

Thanks
Ranjit

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Dec 2014 10:36:08 -0800

On 3 December 2014 at 10:31,  <[email-masked]> wrote:
> 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.

Who are you interoperating with?

---

From: Roman Shpount <[email-masked]>
Date: Wed, 3 Dec 2014 13:37:56 -0500

Is there any reason you cannot use SIP over WebSocket (
https://tools.ietf.org/html/rfc7118)?

Call signaling will require a lot more information then what is provided in
JSEP. JSEP mostly deals with offer and answer processing. Signaling will
also need to deal with things like who is calling, why they are calling,
transfers, other application specific details. In other words, I think this
is a very bad idea.

_____________
Roman Shpount

On Wed, Dec 3, 2014 at 1:31 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 : 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.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 03 Dec 2014 11:40:12 -0700

On 12/3/14, 11:37 AM, Roman Shpount wrote:
> Is there any reason you cannot use SIP over WebSocket
> (https://tools.ietf.org/html/rfc7118)?

Or XMPP over WebSocket for that matter:

https://tools.ietf.org/html/rfc7395

> Call signaling will require a lot more information then what is provided
> in JSEP. JSEP mostly deals with offer and answer processing. Signaling
> will also need to deal with things like who is calling, why they are
> calling, transfers, other application specific details.

Indeed.

> In other words,
> I think this is a very bad idea.

At the least, limited and irrelevant. :-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 3 Dec 2014 18:40:56 +0000

+ 1 for using SIP over WebSocket.

From: rtcweb [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Wednesday, December 03, 2014 12:38 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets

Is there any reason you cannot use SIP over WebSocket (https://tools.ietf.org/html/rfc7118)?

Call signaling will require a lot more information then what is provided in JSEP. JSEP mostly deals with offer and answer processing. Signaling will also need to deal with things like who is calling, why they are calling, transfers, other application specific details. In other words, I think this is a very bad idea.

_____________
Roman Shpount

On Wed, Dec 3, 2014 at 1:31 PM, <[email-masked]<mailto:[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 : 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.

Thanks
Ranjit

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

---

From: [email-masked]
Date: Wed, 03 Dec 2014 12:57:15 -0600

Hello all

While I agree SIP over Websockets is default signaling protocol for 
WebRTC while working with IMS, there could be scenarios where WebRTC 
calls can get initiated from non SIP UAs like web browsers which do not 
support SIP. Then in such cases, the following things could happen
1) the WebRTC client on the browser can use JSEP to send its signaling 
information over WebSocket,
2) the JSEP message would then land on the WebRTC GW over WS.
3) This JSEP message would then be converted to a SIP message and then 
sent to IMS core.
4) within IMS core, its a regular SIP message
5) Again in the reverse direction, WebRTC GW would convert SIP to JSEP
6) JSEP message is sent over Websocket to UE.

now we see JSEP messages getting exchanged over Websockets. so if the 
websocket sub-protocol does not define the type as "jsep", then the 
WebRTC GW would not know the incoming message type and hence may discard 
it or its behavior may be uncertain.

Also the JSEP message needs to be enhanced to add more message types 
(along with current OFFER / ANSWER) to be able to map it with standard 
signaling protocol like SIP as defined in 
https://tools.ietf.org/html/draft-partha-rtcweb-jsep-sip-01

Regards
Ranjit

On 2014-12-03 12:40 pm, Makaraju, Maridi Raju (Raju) wrote:
> FROM: rtcweb [mailto:[email-masked]] ON BEHALF OF Roman
> Shpount
>  SENT: Wednesday, December 03, 2014 12:38 PM
>  TO: [email-masked]
>  CC: [email-masked]
>  SUBJECT: Re: [rtcweb] Interest and need for Websocket subprotocol -
> JSEP over websockets
> 
> (https://tools.ietf.org/html/rfc7118 [1])?
> 
> Call signaling will require a lot more information then what is
> provided in JSEP. JSEP mostly deals with offer and answer processing.
> Signaling will also need to deal with things like who is calling, why
> they are calling, transfers, other application specific details. In
> other words, I think this is a very bad idea.
> 
> _____________
>  Roman Shpount
> 
> 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
>  https://www.ietf.org/mailman/listinfo/rtcweb [2]
> 
> 
> 
> Links:
> ------
> [1] https://tools.ietf.org/html/rfc7118
> [2] https://www.ietf.org/mailman/listinfo/rtcweb

---

From: [email-masked]
Date: Wed, 03 Dec 2014 13:02:08 -0600

Hello all

Regards
Ranjit

---

From: Roman Shpount <[email-masked]>
Date: Wed, 3 Dec 2014 14:07:50 -0500

Ranjit,

If you want to create yet another signaling protocol which uses WebSockets
as a transport, please do. No one is stopping you. Just don't call it JSEP.
Signaling is very different from JSEP, does a lot more then JSEP and
requires a lot of effort to design properly and then map to JSEP API. If
you create something compelling, other people will implement it
and standardize it. At this point, I do not think this group is interested
in creating yet another signaling protocol. I do not think this is
something which is covered by this group charter.

_____________
Roman Shpount

On Wed, Dec 3, 2014 at 1:57 PM, <[email-masked]> wrote:

> Hello all
>
> While I agree SIP over Websockets is default signaling protocol for WebRTC
> while working with IMS, there could be scenarios where WebRTC calls can get
> initiated from non SIP UAs like web browsers which do not support SIP. Then
> in such cases, the following things could happen
> websocket sub-protocol does not define the type as "jsep", then the WebRTC
> GW would not know the incoming message type and hence may discard it or its
> behavior may be uncertain.
>
> signaling protocol like SIP as defined in https://tools.ietf.org/html/
> draft-partha-rtcweb-jsep-sip-01
>
> Regards
> Ranjit
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 03 Dec 2014 20:15:52 +0100

This approach was proposed, discussed and abandoned by the WG in spring 
2012.

You might find 
https://tools.ietf.org/html/draft-jennings-rtcweb-signaling-01 interesting.

On 12/03/2014 08:02 PM, [email-masked] wrote:
> calls can get initiated from non SIP UAs like web browsers which do 
> not support SIP. Then in such cases, the following things could happen
> WebRTC GW would not know the incoming message type and hence may 
> discard it or its behavior may be uncertain.
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 03 Dec 2014 20:32:27 +0100

+1

On 03/12/2014 20:07, Roman Shpount wrote:
> Ranjit,
>
> If you want to create yet another signaling protocol which uses 
> WebSockets as a transport, please do. No one is stopping you. Just 
> don't call it JSEP. Signaling is very different from JSEP, does a lot 
> more then JSEP and requires a lot of effort to design properly and 
> then map to JSEP API. If you create something compelling, other people 
> will implement it and standardize it. At this point, I do not think 
> this group is interested in creating yet another signaling protocol. I 
> do not think this is something which is covered by this group charter.
>
> _____________
> Roman Shpount
>
> On Wed, Dec 3, 2014 at 1:57 PM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello all
>
>     While I agree SIP over Websockets is default signaling protocol
>     for WebRTC while working with IMS, there could be scenarios where
>     WebRTC calls can get initiated from non SIP UAs like web browsers
>     which do not support SIP. Then in such cases, the following things
>     could happen
>     1) the WebRTC client on the browser can use JSEP to send its
>     signaling information over WebSocket,
>     3) This JSEP message would then be converted to a SIP message and
>     then sent to IMS core.
>     now we see JSEP messages getting exchanged over Websockets. so if
>     the websocket sub-protocol does not define the type as "jsep",
>     then the WebRTC GW would not know the incoming message type and
>     hence may discard it or its behavior may be uncertain.
>
>     Also the JSEP message needs to be enhanced to add more message
>     types (along with current OFFER / ANSWER) to be able to map it
>     with standard signaling protocol like SIP as defined in
>         FROM: rtcweb [mailto:[email-masked]
>         <mailto:[email-masked]>] ON BEHALF OF Roman
>         Shpount
>          TO: [email-masked] <mailto:[email-masked]>
>          CC: [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 3 Dec 2014 12:54:31 -0800

Hi Ranjit,

> the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving JSEP
​If I understand your proposal correctly, I believe it is currently out of
scope for the working group.  If I understand
the minimally necessary item, it is to define a websocket sub-protocol
"jsep" so that gateways can use this token to indicate the appropriate
handling.   At least to my reading, this work is outside of our current
charter.

I'd suggest you start by approaching the area directors for pointers on
where the work might take place.

regards,

Ted

---

From: Erik Lagerway <[email-masked]>
Date: Wed, 3 Dec 2014 13:14:34 -0800

+1

*Erik Lagerway <http://ca.linkedin.com/in/lagerway> | *Hookflash
<http://hookflash.com/>* | 1 (855) Hookflash ext. 2 | Twitter
<http://twitter.com/elagerway> | WebRTC.is Blog <http://webrtc.is/> *

On Wed, Dec 3, 2014 at 11:07 AM, Roman Shpount <[email-masked]> wrote:

>> WebRTC while working with IMS, there could be scenarios where WebRTC calls
>> can get initiated from non SIP UAs like web browsers which do not support
>> SIP. Then in such cases, the following things could happen

---

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

2014-12-03 19:57 GMT+01:00  <[email-masked]>:
> initiated from non SIP UAs like web browsers which do not support SIP.

There are not "browsers which do not support SIP" and there are not
browsers supporting SIP. But fortunately browsers do support WebSocket
and JavaScript, so we can implement&use SIP, XMPP, fooJSON or barJSON
over WebSocket, or even CHICKEN over WebSocket.

>  Then

OK, I know your SDP. Can you also tell me *who* you are?

> behavior may be uncertain.

You don't get the point. If you use SIP over WebSocket (within a
WebRTC context) or XMPP over WebSocket or whatever other protocol, you
are already using JSEP. Where?

- When you use the W3C WebRTC API.
- When you transmit the SDP offer from peerA to peerB (using
SIP/XMPP/CHICKEN over WebSocket).
- etc.

> Also the JSEP message needs to be enhanced to add more message types (along
> with current OFFER / ANSWER) to be able to map it with standard signaling
> protocol like SIP as defined in

Fortunately it won't happen. But feel free to design your own wire
protocol to transmit media related information among with your custom
signaling information (who you are, who you are calling to, etc). Just
don't request it to be a standard please.

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Dec 2014 04:46:39 +0000

Hi Ranjit,

For WebRTC access to IMS, there is no such thing as a "default protocol".

It is true that, inside IMS, SIP is used, but you can use whatever protocol you want to access   IMS, as long as the eP-CSCF (acting as a WebRTC Gateway) can map it into SIP.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: [email-masked]<mailto:[email-masked]>
Sent: ‎03/‎12/‎2014 21:02
To: Makaraju, Maridi Raju (Raju)<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets

Hello all

Regards
Ranjit