Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case]

On 2/20/2012 3:31 PM, Roman Shpount wrote:
> Not to beat this horse to death, but why is it "suggested not to have
> parallel forking"? WebRTC intorduces additional restrictions on RTP
> stream (remote media sources and SSRCs are known in advance) that make
> parallel forking implementation trivial. Only thing that is missing is
> some way to clone the PeerConnection in the API.

Right; parallel forking has uses.

We've talked about this, but not for a while.  One way to implement it 
would be to on each forked answer clone the state of the PeerConnection 
as it was with any previous answer removed.  However, I'm concerned 
about how this will interact with the ICE, etc stuff.  Someone want to 
throw out a suggestion?  Cullen, Justin - how *should*/*could* forking 
work within JSEP?


Aside on uses of forking:
I can see some additional interesting uses for parallel forking, 
especially in non-phone-like usecases (games among others).  The server 
(or another participant) could hold open an OFFER in order to forward it 
to any potential new partners.  This might apply to a conference call as 
well if there's a peer-2-peer aspect (mesh, partial-mesh, etc) to it.

Think in a game or 2nd-life-type-sim, where you're automatically in a 
voice chat with anyone within hearing range, and those voice chats are 
done p2p by forking each player's original offer to the server, and 
forwarding it (forking it) to the new user, who would answer and they'd 
be in a call.

If you wanted to get really fancy, you could even do some of the 
negotiation in the server and rephrase each offer as an answer to the 
other side, leading to a 1/2-RTT-to-the-server setup time (more-or-less:

player 1                   server                   player 2
------------------------------------------------------------
|                             |                         |
|--> Offer 1 ---------------->|                         |
|                             |<---------- Offer 2 <----|
|                             |                         |
...
                 Server decides they should talk
|                             |                         |
|<-- Answer(Offer 2) <--------|-----> Answer(Offer 1)-->|
|<------------------------- media --------------------->|

Even if this is initiated by a player, there are equivalent graphs that 
use 1/2 RTT (through the server to other player) to set up channels.

I should note however that ICE overhead may well swamp this fancy setup 
and it may be over-reaching, but each 1/2 RTT removed is significant, so 
there may be uses.

> _____________
> Roman Shpount
>
>
> On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg
> <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com>>
> wrote:
>
>
>     Hi,
>
>     Just to clarify: the new offer is for the same "session" as the
>     previous offer, and is supposed to replace the previous offer.
>
>     The browser can of course send a just-audio offer somewhere, and a
>     just-video offer somewhere else, but would those even be associated
>     with the same PeerConnection? I thought we wanted only one
>     offer/answer, which is the reason it has been suggested e.g. not to
>     support paralell forking in the browser.
>
>     Regards,
>
>     Christer
>     ________________________________________
>     From: Iņaki Baz Castillo [ibc@aliax.net <mailto:ibc@aliax.net>]
>     Sent: Monday, February 20, 2012 10:13 PM
>     To: Christer Holmberg
>     Cc: Justin Uberti; rtcweb@ietf.org <mailto:rtcweb@ietf.org>;
>     public-webrtc@w3.org <mailto:public-webrtc@w3.org>
>     Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous
>     offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case]
>
>     2012/2/20 Christer Holmberg <christer.holmberg@ericsson.com
>     <mailto:christer.holmberg@ericsson.com>>:
>      > Q1. When the JS app requests the new offer (o-2), I assume all
>     resources etc associated with o-1 will be released (unless they are
>     also needed for o-2, that is).
>
>     Does it mean that the browser is just capable of having *one*
>     multimedia session at the same time? Well, in SIP world this typically
>     means putting on-hold the previous call so, indeed, resources would be
>     released.
>
>     But, why couldn't the browser send a just-audio offer somewhere and a
>     just-video offer to other destination at the same time?
>
>     --
>     Iņaki Baz Castillo
>     <ibc@aliax.net <mailto:ibc@aliax.net>>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Monday, 20 February 2012 22:03:34 UTC