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

[Randell Jesup <[e-mail]>]

On 10/21/2011 2:12 PM, Iñaki Baz Castillo wrote:
> 2011/10/21 Matthew Kaufman<[e-mail]>:
>> 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.
>
> 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.

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

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

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