Subject: [rtcweb] Incoming Call for RTCWeb using SIP

From: "Khan, Sohel" <[email-masked]>
Date: Mon, 6 Feb 2012 20:59:28 +0000

My question pertains to RTCWeb Incoming call.
Please assume for this discussion,  RTCWeb  uses SIP.
Also, please assume that a NAT or multiple NAT exist between the SIP-Web server and the RTC Web client (Receiver).
Here, the sender of the call is Alice and receiver of the call is Bob.
We would like to discuss the signaling protocol between the RTC Web Server to Bob

|RTC SIP-Web Server|----->|NAT|--->RTC Web-Client (receiver).

RFC 5128 Section 3.2 Connection reversal is an interesting method that we can consider for an incoming call.
http://datatracker.ietf.org/doc/rfc5128/?include_text=1
Client A is behind a NAT, but client B has a publicly addressable
IP address.  Rendezvous Server S has a publicly addressable IP
address and is used for the purposes of registration and discovery.
Hosts behind a NAT register their endpoints with the server.  Peer
hosts discover endpoints of hosts behind a NAT using the server ...
Now suppose client B wishes to establish a direct communication session with client A. ...
After attempting and failing to establish a direct connection to A,
client B can use server S to relay a request to client A to initiate
a "reversed" connection to client B.  Client A, upon receiving this
relayed request through S, opens a TCP connection to client B at B's
public IP address and port number.  NAT A allows the connection to
proceed because it is originating inside the firewall, and client B
can receive the connection because it is not behind a NAT device.
...
In RTCweb architecture, for incoming calls, are we thinking RFC5128 section 3.2 method or any other similar innovative method?

Appreciate to hear your opinion.

Sohel Khan, Comcast

---

From: Randell Jesup <[email-masked]>
Date: Tue, 07 Feb 2012 04:59:48 -0500

On 2/6/2012 3:59 PM, Khan, Sohel wrote:

> |RTC SIP-Web Server|---à|NAT|-àRTC Web-Client (receiver).
>

Please read up on ICE (another IETF RFC), which is what we're specing 
WebRTC to use.

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 9 Feb 2012 23:06:25 +0000

I think he's asking about the "signaling", not the "media". 

Sohel: 
For the "signaling" to get from a Web Server to a Web Browser behind a NAT, it would use whatever mechanism the web-developer chooses to use (and which the browser can support).  For example, it could be using a websocket to keep a permanent connection up with the web server to receive incoming messages, or it could be frequently http-polling the web server to learn of incoming calls.

If it's actually truly "SIP" on the browser-server connection, then it would do something like draft-ibc-sipcore-sip-websocket.  But there's no need for the messages between the browser and server to be real SIP.  The browser-server application is essentially proprietary, as are its message formats and semantics.

-hadriel

On Feb 7, 2012, at 4:59 AM, Randell Jesup wrote:

> Please read up on ICE (another IETF RFC), which is what we're specing WebRTC to use.
> 
> 
> -- 
> Randell Jesup
> [email-masked]
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 13 Feb 2012 12:25:23 +0100

> Please assume for this discussion,  RTCWeb  uses SIP.

That is indeed a wrong assumption (unless you use SIP over WebSocket).
The WebRTC browser uses no special transport/signaling for WebRTC
communications. It can only use existing mechanisms (HTTP, WebSocket
or proprietary protocols via plugins).

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