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

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]
Sent: Monday, February 20, 2012 10:13 PM
To: Christer Holmberg
Cc: Justin Uberti; rtcweb@ietf.org; 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>:
> 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>

Received on Monday, 20 February 2012 20:19:23 UTC