Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

[Randell Jesup <[e-mail]>]

On 5/3/2012 11:01 AM, Roman Shpount wrote:
>
> On Thu, May 3, 2012 at 2:02 AM, Christer Holmberg
> <[e-mail] <mailto:[e-mail]>>
> wrote:
>
>     You are absolutely right. I still question whether we need to
>     support parallel forking. If you say it occurs often, I can't argue
>     against you, even though my own experience is different :)
>
>
> You do end up with parallel forking when you allow registrations from
> multiple devices. This is a policy option, but once you enable this,
> parallel forking or B2BUA are the only options.

Correct; I brought this up multiple times last year, when we had one of 
the original discussions of cloning.

If I call [e-mail], and he has a phone, and a tablet, and a 
computer, and a star trek communicator all "attached" to google's JSEP 
signaling proxy, it's going to want to fork the offer to all of them. 
So I really believe parallel forking is needed for very basic use-cases. 
  And both Scotty (in the Away Team) and his assistant (sitting at the 
computer) might accept.  If his assistant accepts first, Scotty is out 
of luck unless some parallel forking is supported and PeerConnection 
cloning is done.  That doesn't mean you must render or encode data for 
all clones simultaneously, though that's a nice option and mirrors 
normal requirements for mesh conferencing.  You can send the same data 
to both (mesh), or possibly act as a conference bridge instead of a full 
mesh conference (ah-hoc bridged conference).

Another usecase I bandied about was "hanging" cloned offers being 
provided to new participants in a partial-mesh conference.  Think Second 
Life, or a virtual conference with positional locality (it doesn't have 
to be visual Virtual Reality ala Second Life; it can be abstract - but 
it's easiest to think of in a Second Life or MMORPG type of setting). 
I.e. the signaling server holds a cloned copy of your invite, and when 
someone new comes into hearing range of you it forwards your (cloned) 
OFFER to them (delayed parallel forking, if you will).  Otherwise, it 
would need a protocol to let the server tell you to generate a new offer 
that it could then forward, adding roughly 1 client-server-RTT to setup 
time, plus requiring extra application protocols and logic.

>     (Another option, if we want to support parallel forking, would of
>     course be to create a completely new PeerConnection, with a *new*
>     local IP address:port. But, you would of course then have to provide
>     that information to the remote peer.)
>
>
> This would probably do absolutely nothing to SIP interop. And if we do
> not need SIP interop we can live without forking (at the cost of being
> slightly less efficient in some call setup scenarios).

Ignoring SIP interop, this might work as an equivalent to cloning, but 
requiring an extra O/A exchange (and adding considerable chance of 
clipping on a second fork being activated).

>
>     I have no strong feeling on whether we want to do cloning, but do
>     people agree that, for a given PeerConnection, we only need to
>     support a single remote peer (which can be modified, though)?
>
>
> I think if we do cloning we will only need to support a single remote
> peer per PeerConnection. Strictly speaking even updates due to
> provisional responses would not be necessary, since you can always clone
> the connection and provide a new answer to it instead.

I believe that's correct.

-- 
Randell Jesup
[e-mail]