W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2012

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

From: Roman Shpount <roman@telurix.com>
Date: Mon, 20 Feb 2012 15:31:25 -0500
Message-ID: <CAD5OKxv9FcoGibaRmwL1D4x6WKDhjp4Wp6968QU_qxsd64nPsw@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Iņaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
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.
Roman Shpount

On Mon, Feb 20, 2012 at 3:14 PM, Christer Holmberg <
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]
> 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>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
Received on Monday, 20 February 2012 20:31:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:27 UTC