- From: Ejzak, Richard P (Richard) <richard.ejzak@alcatel-lucent.com>
- Date: Tue, 21 Feb 2012 08:34:55 -0600
- To: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi Partha, Regarding my earlier email (this earlier email was not distributed on the webrtc list), I do not dispute that forking must be supported by all SIP endpoints. Let me rephrase my earlier questions in light of your latest call flow. Looking at your call flow, I see that you treat the case of multiple answers from the same endpoint as a serial forking case (or do I misunderstand your intent?). How do you determine that this is a special type of serial forking and not a parallel forking case? We have at least three use cases for multiple ANSWER and it would be helpful to see how they can be handled and distinguished in SIP signaling. Also, PRANSWER as currently defined seems to have no analog in SIP. Is this also your understanding? I don't understand your statement that "It is possible to implement parallel forking by keeping only one answer active in the offerer side at the given time". It would appear that an implementation of parallel forking would need to keep the last answer from each dialog active. Please explain. I look forward to your next call flow. Richard -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ravindran, Parthasarathi Sent: Tuesday, February 21, 2012 12:58 AM To: Randell Jesup; 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] Randell, It is possible to implement parallel forking by keeping only one answer active in the offerer side at the given time. I attached one of the example "18x with SDP and 2xx with different SDP" for your reference which will map to serial forking. Please let me know your concern about ICE interaction concern here. I'll send multiple 18x with SDP and one 2xx with SDP response JSEP example using UPDATE O/A mechanism ASAP for clarity on parallel forking (assumption: multiple answer for single offer is supported in JSEP). Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Randell Jesup >Sent: Tuesday, February 21, 2012 3:32 AM >To: 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] > >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 >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb
Received on Thursday, 23 February 2012 09:25:03 UTC