Subject: [rtcweb] Relationship of ROAP and PeerConnection?

From: <[email-masked]>
Date: Wed, 26 Oct 2011 07:33:28 +0000

Hi,

I have been trying to figure out how ROAP and the W3C PeerConnection object are intended to work together. The sequence diagrams in the ROAP I-D give some idea about that, but I'd like to clarify if my understanding is correct.

If I understand correctly, the SDP (ROAP) offer-answer and ICE state machines are implemented within the browser (UA). The browser gathers the ICE candidates and does the end-to-end STUN connectivity check. The browser does not however really send/receive the SDP/ROAP messages. Rather, that is left to the Javascrip app. PeerConnection has the processSignalingMessage() method by which the JS app can pass a message to the browser, and the signalingCallback function for passing the message in the other direction. ROAP defines the syntax and semantics of these messages (based on SDP O/A) and explains how they drive the state machine within the browser. The JS app can use any means to carry the messages to the other browser (in principle using XmlHttpRequest or Websocket towards the web server). It can change the syntax (e.g. to "real" SDP or Jingle XML or whatever), add or remove anything, as long as it is able to give a valid message to the other peer using processSignalingMessage().

Is this roughly how this is supposed to work?

If we take this approach, wouldn't it be better to integrate the ROAP definition to the W3C API spec? If they are separate documents as they are at the moment, it is a bit difficult to do the mapping. I understand that currently it is like it is because W3C is responsible for the API and IETF for the protocol.

Markus

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 26 Oct 2011 10:46:36 +0200

> Is this roughly how this is supposed to work?

Hi Markus. I hope that is supposed to work exactly as you describe
above. But indeed, it would be great if this WG confirms it so we can
move on.

Recently we have written an informational draft exposing the same as
in your mail:

  http://tools.ietf.org/html/draft-sipdoc-rtcweb-open-wire-protocol-00

The RTCweb example scenarios (sections 4 and 5 in the draft) are
designed whit this assumption in mind.

Regards.

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 26 Oct 2011 08:41:56 -0600

> Is this roughly how this is supposed to work?

Yes. However, a signaling gateway would probably want to implement ROAP over Websockets over TLS.  

> 
> If we take this approach, wouldn't it be better to integrate the ROAP definition to the W3C API spec? If they are separate documents as they are at the moment, it is a bit difficult to do the mapping.

Right now the W3C API and ROAP are way out of sync so it makes it particularly hard to do the mapping in ones head. Eventually we will need to sort out which spec defines the JSON object as the string form of that is the ROAP protocol and also would be passed across the RTCWeb API. There are arguments either way but I'm sure that we want it defined one place and the other place to point at it. I think as we get this all sorted out, it will become relatively clear which document to put the text in. Right now, I'm just trying to focus on does the idea look like it is on the right path regardless of which document it is in. The fact the various specs are so out of sync makes it hard to get ones head around the whole idea. In the meantime, the ROAP JSON object is primarily about a concrete instantiation of the abstract RFC 3264 Offer/Answer protocol and is key to the over the wire ROAP protocol to a signaling gateway so I think it fairly reasonable to be driving the discussion from and IETF document vs a W3C one. From W3C API point of view, it is more of an opaque contain of information used for IETF protocols. 

> I understand that currently it is like it is because W3C is responsible for the API and IETF for the protocol.
> 
> Markus
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: <[email-masked]>
Date: Thu, 27 Oct 2011 11:48:24 +0000

Hi Cullen,

Cullen Jennings wrote:
>
>Right now, I'm just trying to
>focus on does the idea look like it is on the right path regardless of which
>document it is in.

My initial assumption was that we'd not even standardize things on the level of ROAP or SDP O/A, but more along the lines what Hadriel and others have been advocating. But ROAP and PeerConnection look quite decent, and for instance Iñaki's draft (http://datatracker.ietf.org/doc/draft-sipdoc-rtcweb-open-wire-protocol) show how they could be used in quite diverse ways. So, continuing on that path seems fine to me. This way we may have something concrete within a year. At least I don't think we should go any further than what ROAP does in defining a specific session setup protocol. 

Markus

---

From: Tim Panton <[email-masked]>
Date: Thu, 27 Oct 2011 08:03:39 -0600

On 26 Oct 2011, at 08:41, Cullen Jennings wrote:
> 
> Right now the W3C API and ROAP are way out of sync so it makes it particularly hard to do the mapping in ones head. Eventually we will need to sort out which spec defines the JSON object as the string form of that is the ROAP protocol and also would be passed across the RTCWeb API. There are arguments either way but I'm sure that we want it defined one place and the other place to point at it. I think as we get this all sorted out, it will become relatively clear which document to put the text in. Right now, I'm just trying to focus on does the idea look like it is on the right path regardless of which document it is in. The fact the various specs are so out of sync makes it hard to get ones head around the whole idea. In the meantime, the ROAP JSON object is primarily about a concrete instantiation of the abstract RFC 3264 Offer/Answer protocol and is key to the over the wire ROAP protocol to a signaling gateway so I think it fairly reasonable to be driving the discussion fr
> om and IETF document vs a W3C one. From W3C API point of view, it is more of an opaque contain of information used for IETF protocols. 

Agreed, with the exception that we need the W3C to help specify an API for the 'Hints' and 'Properties' interfaces
that we agreed were required in the last call.

Tim.