Subject: [sipcore] Questions on SIP over websockets.

From: Binod <[email-masked]>
Date: Tue, 07 May 2013 17:07:31 +0530

HI,

As part of JSR 359 (SIP Servlet 2.0) standardization, we are working on 
supporting SIP
over websocket ID in SIP servlets. I have a few questions on this I-D 
and will be great,
if you can answer the following questions.

- How do you envision the sip/websocket to be used? Do you expect 
webservers
   that use webrtc to also support sip/websocket or do you expect, the 
sip/websocket
   to be supported by the sip servers independent of webservers and thus 
web
   application and sip application run as independent entities? Or both?

- When a call come from a SIP UA to web browser (reverse of what is 
shown in 8.2),
   one option the draft is suggesting is the use of RFC 5626 as the way 
to identify the
   flow to send the request. But the draft does not stop a proxy/b2b 
from using some other
   mechanism either. Is that intentional? Do the spec allow a webserver 
to use a
   websocket connection based on its logic to send the requests to the 
client?

- JSEP in webrtc (section A.1.5) has a model that simply does 
offer/answer using INVITE dialog.
   So, if I understand correctly, REGISTER is not really required for a 
web application.
   Is that model allowed? The examples in the rfc draft  and reference 
to 5626 suggest the
   use of REGISTER. Is that the intention?

thanks,
Binod.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 May 2013 13:50:05 +0200

2013/5/7 Binod <[email-masked]>:
> over websocket ID in SIP servlets. I have a few questions on this I-D and
> will be great,
> - How do you envision the sip/websocket to be used? Do you expect webservers
>   to be supported by the sip servers independent of webservers and thus web

I expect both, but for now all the server implementations I know are
pure SIP servers with recent WebSocket support.

> - When a call come from a SIP UA to web browser (reverse of what is shown in
> 8.2),
>   one option the draft is suggesting is the use of RFC 5626 as the way to
> identify the
>   flow to send the request. But the draft does not stop a proxy/b2b from
> using some other
>   mechanism either. Is that intentional? Do the spec allow a webserver to
> use a

SIP rules define that a request is routed based on its Route headers
and Request-URI value. If a SIP-WebSocket proxy/server/entity routes
the requests to a WS client based on other criterion then it is not
playing SIP rules so such a behavior is out of the scope of SIP
protocol and the draft.

Anyhow some SIP servers/PBXs/B2BUAs already implement their own
routing logic, regardless they don't implement RFC 5626. This is not
something new in SIP over WebSocket, some occurs in SIP over TCP.

> - JSEP in webrtc (section A.1.5) has a model that simply does offer/answer
> using INVITE dialog.
>   So, if I understand correctly, REGISTER is not really required for a web
> application.
>   Is that model allowed? The examples in the rfc draft  and reference to
> 5626 suggest the

draft-sipcore-sip-websocket just defines a new transport for SIP, and
not a new SIP protocol. If the SIP WebSocket Client does not perform
SIP registration then it's hard to understand how a server/proxy could
route requests to it. Of course it can be done in tons of proprietary
ways, but the draft plays to SIP rules and thus registration + RFC
5626 seems a proper way for a SIP WebSocket Client to be able to
receive incoming initial requests.

Let us not consider SIP over WebSocket as something else than what it
is: a new transport for SIP protocol, no more. This is still SIP.

Best regards.

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

---

From: Binod <[email-masked]>
Date: Tue, 07 May 2013 17:49:25 +0530

Thanks Inaki.

On the JSEP and REGISTER, you are saying that, the server MUST use
REGISTER + 5626. Did I get it right?

In that case, why it is not mandated in the I-D?

Given WS connections are always initiated from the client, Is there any way
other than using 5626 to send a request from the server to the
websocket client?

thanks,
Binod.

On Tuesday 07 May 2013 05:20 PM, Iñaki Baz Castillo wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 May 2013 14:35:03 +0200

> REGISTER + 5626. Did I get it right?

No, I never said "MUST" :)

> In that case, why it is not mandated in the I-D?

The SIPCORE WG already decided in a previous IETF meeting that the
draft should not mandate Outbound, and I agree, since the draft just
defines a new transport for SIP.

> other than using 5626 to send a request from the server to the

Yes, proprietary solutions like those implemented in MOST of the SIP
servers when a SIP TCP client connects to it and the server reuses
such a TCP connection for routing *everything* to the UA regardless
RFC 5626 is not used, announced or supported by the UA and/or the
server. Examples: Asterisk, SER/Kamailio/OpenSIPS, 99% of comercial
SIP servers I've tested, etc.

Regards.

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

---

From: Binod <[email-masked]>
Date: Tue, 07 May 2013 21:03:53 +0530

> SIP servers I've tested, etc.

It matches with my understanding. As it stands today, the I-D allows,
though it doesn't encourage, webservers to use their own mechanism
to route the SIP messages instead of using REGISTER+5626.

I don't necessarily disagree with either approach. Just wanted to
make sure that the standard we are working on allows what the
I-D intends to allow.

Thanks.
Binod.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 May 2013 13:58:06 -0400

>> defines a new transport for SIP.

Not mandating it allows flexibility and support of future extensions.
If you are building strictly standards compliant products, then *for 
now* outbound is the only way you will be able to receive outbound 
calls. But of course you could still *initiate* calls without this.

> make sure that the standard we are working on allows what the

There is nothing inherently *wrong* with this. SIP gives proxies great 
leeway to employ their own routing policies. It just means that the 
portions of the system that do this are *proprietary*.

	Thanks,
	Paul