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

[Iñaki Baz Castillo <[e-mail]>]

2014-12-03 19:57 GMT+01:00  <[e-mail]>:
> 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.

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
> 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,

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


> 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.

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
> https://tools.ietf.org/html/draft-partha-rtcweb-jsep-sip-01

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
<[e-mail]>