Subject: [rtcweb] Does ROAP mandate the on-the-wire format?

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 21 Oct 2011 18:25:43 +0200

Hi, I'm a bit afraid after listeing/reading this phrase in the conf:

-----------------
Cullen:  I will clarify ROAP is over-the-wire protocol, add
termination, and do some other clarifications, then re-issue.
-----------------

I expect that ROAP does NOT mandate the format of the messages
exchanged on-the-wire, but just the communication between the JS
custom code and the RTCweb stack in the browser, am I right? say "yes"
please.

What I understand (or want to understand) is that any custom RTCweb
on-the-wire protocol must satisfy ROAP requirements in some way, so
when the JavaScript receives some kind of custom message it can
interpret it and convert into the appropriate ROAP request, and then
make a ROAP call to the browser via the RTCweb API. Am I right?

Thanks.

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

---

From: Ralph Giles <[email-masked]>
Date: Fri, 21 Oct 2011 09:36:02 -0700

> custom code and the RTCweb stack in the browser, am I right? say "yes"

I'm not Cullen, but my understanding is that this is the case.

The terminology is confusing, and I think we've been talking past each
other a lot over the past weeks. I believe the point is that ROAP is
the message format, state machine, and 'protocol' which one
peerconnection object in one browser uses to talk to another
peerconnection object in another browser to set up the direct media
connections.

Because there's more than one browser implementation this needs to be
standardized, and an easy way to think of that requirement is if the
roap messages are passed directly between the user agents without
modification.

Of course, since the format, state machine, etc. are documented, then
of course whatever code is conveying the messages between the user
agents can translate or edit the data, as long as it's a compatible
manipulation.

 -r

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Oct 2011 16:39:26 +0000

> Hi, I'm a bit afraid after listeing/reading this phrase in the conf:

Well since the Browser will never know whether ROAP is really to another Browser vs. the Javascript, then yes it could be used that way. (it will probably be painful, but possible)

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 21 Oct 2011 18:43:33 +0200

> Well since the Browser will never know whether ROAP is really to another Browser vs. the Javascript, then yes it could be used that way. (it will probably be painful, but possible)

The question comes because my wire signaling implementation (SIP over
WebSocket) is that: SIP. So the JS sends and receives pure SIP
messages (with SDP) over the wire.

If ROAP includes a real SDP (as the draft currently states) then I'm
done as I just need to create a ROAP object (in JavaScript) and pass
it the received SDP string (and also set some session status
variables, which can be easily mapped from the received SIP
request/response).

Hope I'm right and I don't have to drop the work of long months.

Regards.

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Oct 2011 17:37:05 +0000

You know, doing that would be awesome because then you could test it against real SIP devices, or even at Sipit, to verify we've got the legacy-SIP-compatibility-model right for more esoteric cases.

-hadriel

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 21 Oct 2011 19:40:45 +0200 (CEST)

> Well since the Browser will never know whether ROAP is really to another Browser vs. the Javascript, then yes it could be used that way. (it will probably be painful, but possible)

I agree, and have pointed this out in previous discussions.

I'd just like the painful part to be as little pain as we can possibly achieve, because this is exactly how I intend to use it.

Matthew Kaufman

Sent from my iPad, on a plane

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 21 Oct 2011 19:47:13 +0200 (CEST)

> variables, which can be easily mapped from the received SIP

If you can do this as easily as it sounds above, and it supports both early media and forking, then I think we've put far too much into the browser logic. So this is actually a good test of the design.

For a browser, there should be no such thing as early media... Just media.

And for a browser, there should be no such thing as forking, just two (or more) connection objects that represent the two (or more) possible call legs.

And it should be possible, with the right JavaScript and the right APIs to achieve exactly what you describe above. But perhaps not as easily as you describe.

Matthew Kaufman

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 21 Oct 2011 20:04:54 +0200

> You know, doing that would be awesome because then you could test it against real SIP devices, or even at Sipit, to verify we've got the legacy-SIP-compatibility-model right for more esoteric cases.

Oh, I already test it against real SIP devices. Even better, I can
test SIP devices against my (our) much better SIP implementation :)

http://www.youtube.com/watch?v=qfFlK1KyF6Q

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Oct 2011 18:05:49 +0000

> For a browser, there should be no such thing as early media... Just media.

Not disagreeing with your high-level point... but I don't think early media is possible in RTCweb no matter how we dice it, if by "early media" you mean your JS+browser being able to render media before getting some high-path info back from the Server.  Because you can't do ICE until you know the other side's ICE user/pass, so media won't flow till then.  Right?

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 21 Oct 2011 20:12:09 +0200

> For a browser, there should be no such thing as early media... Just media.

As Hadriel has pointed out, in SIP early media is just a *normal*
media session but without a confirmed INVITE transaction (not a final
response yet, but just 180/183 with SDP). So there is no problem in
implementing early media in the browser.

> And for a browser, there should be no such thing as forking,

Why not? my current implementation can receive different SIP 180/183
with different To-tags, which means "forking".

Regards.

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

---

From: Randell Jesup <[email-masked]>
Date: Fri, 21 Oct 2011 18:05:29 -0400

On 10/21/2011 2:12 PM, Iñaki Baz Castillo wrote:
> 2011/10/21 Matthew Kaufman<[email-masked]>:

In ROAP, this would be a TENTATIVE ANSWER, which can set up ICE and 
media channels for one-way media (if desired).

> with different To-tags, which means "forking".

I believe it's very important to be able to receive multiple answers to 
an offer, which allows for all sorts of interesting uses by the app 
writer.  For example, the case I gave yesterday, where each participant 
in a game OFFERed to the game server at the start, and if during the 
game it wanted them connected to another player, it would forward (fork) 
the OFFER to the other player as an ANSWER to *their* OFFER, and vice 
versa. This 'tricky' server-side manipulation might require the server 
to manually perform O/A resolution to transform the OFFERs into ANSWERs; 
though that shouldn't be that hard for this case.  This also means it 
can leverage the existing authority granted for access to camera and 
mic.  Also, this "transformation" isn't needed if the existing authority 
can be leveraged in some other manner

This is roughly equivalent to the use-case of a "mesh" conference, where 
the server isn't serving as a media hub/mixer, and in that case we 
wouldn't want a new user joining to force everyone to individually 
authorize talking to them.  So if we can solve that problem 
security-wise, then the game scenario above just becomes "fork the 
original offer to the other player, and route the answer back" - very easy.

-- 
Randell Jesup
[email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 30 Oct 2011 15:06:39 -0600

Let's say the RTCWeb API passed JSON objects like the ones in ROAP in and out of the PeerConnection object. (I will be arguing that is one thing we should consider).  At that oping you could write the SIP over webesockets in JS in the browsers. You might even find some useful info on how to do the mapping in draft-jennings-rtcweb-signaling-gateway-01

I think there has been a lot of talking past each other on this. In some cases ROAP over webesockets might be a protocol used to speak directly to a ROAP to SIP signaling GW. So I view ROAP over a well defined transport to be a on the wire protocol but certainly not the only on the wire protocol. Just one that some systems could use. 

On the other hand, if one does SIP in JS (or the browser), that works too. 

Hope that helps clarify.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 31 Oct 2011 10:44:56 +0100

> On the other hand, if one does SIP in JS (or the browser), that works too.

Sure, thanks a lot.

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

---

From: Wolfgang Beck <[email-masked]>
Date: Mon, 31 Oct 2011 16:34:02 +0100

It's the question whether we see 'SDP' as browser-to-browser or as
browser-to-server communication. If it was strictly
browser-to-browser, W3C could define a blob format that just needs
some transport, like ROAP. If we have interconnection, we have to do
protocol translation and know the blob's format on some server. In
this case, SDP is a good choice as we can avoid translating this
format most of the time. Let's hope your implementation will not choke
on SDPs like this one:
http://osdir.com/ml/ietf.mmusic/2006-05/msg00045.html