Re: [rtcweb] Use of offer / answer semantics

[Randell Jesup <[e-mail]>]

On 9/12/2011 4:56 AM, Hadriel Kaplan wrote:

Not answering the interesting arguments made earlier in his message 
right now.

> 5) Architecturally, I don't understand why the *browser* needs to know about sessions.  I'm not talking about individual "media sessions", but rather the SIP concept of "sessions".  SDP offer/answer requires this knowledge - it needs to know when a session begins, ends, and its context/state.  Minimally it needs to know this to group media info together (ie, to know that the audio and video are tied to the same session), and to handle the origin line sess-version number, and session-level attributes.  Why should the _browser_ need to know that?  What should it care whether the audio and video being used by a javascript are tied to one call vs. two separate calls??  Why should it even know there is such a thing as a "call"?  It's a media library.  Keep it simple stupid.

The browser needs to know *somehow* that certain sets of audio and video 
streams need to be synchronized, and be given the tools and data to do 
so well.  And you may want to synchronize multiple video streams to the 
same audio stream (think the dual-camera case).

I am somewhat torn between ease-of-use for the developers (and increased 
likelihood of them getting it right) and providing a truly generic 
infrastructure that people *can* build anything on top of - but 
decreases the likelihood of getting it right, and decreases the 
likelihood of interop (federation) working or being easy.

-- 
Randell Jesup
[e-mail]