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

Hi,

Just to clarify: my suggestion has been to support only serial forking for a given PeerConnection, and for that PeerConnection any new answer would replace the previous one.

If paralell forking in the browser really is needed, one option is to "clone" the PeerConnection.

Regards,

Christer




-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ravindran, Parthasarathi
Sent: 22. helmikuuta 2012 5:32
To: Ejzak, Richard P (Richard); 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]

Hi Richard,

Thanks for your comments. I have put the focus on the offer/answer exchange between OffererJS and OffererUA in the callflow and assumed 18x as reliable. I'm bit afraid to write too much details about SIP in this forum (see RTCWeb archive for more details) :-)

I'll update the callflow with PRACK & 200. Out of the 3 requested usecases, I have provided 1 and 3 with this assumption. I'll send 2nd usecase of serial forking with UPDATE and updated standard callflow for 1st & 3rd usecase ASAP.

My intention is not to violate standard but I have provided the deployed (real-time) usecases as Cullen requested and also mentioned in the same mail how to make those callflow standard compliance. For your concern on signaling standard deviation discussion within WebRTC, I'll write the separate mail.

Thanks
Partha

>-----Original Message-----
>From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel-
>lucent.com]
>Sent: Wednesday, February 22, 2012 4:15 AM
>To: Ravindran, Parthasarathi; 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]
>
>Hi Partha,
>Thanks for the call flows and explanations.
>
>For all of your flows, it would really help if any deviation from RFC
>3261 or RFC 3264 is clearly noted in your flows.  Further, it would
>help to be clear when you assume reliable or unreliable provisionals,
>since that makes a big difference.  You appear to usually assume
>reliable provisionals, but I want to be sure.
>
>It would also help to identify the purpose of some key operations in
>each flow when not strictly for protocol conformance.  For example,
>setting some flows to "inactive" is used to avoid having multiple media
>flows when parallel forking, but this is an application choice rather
>than a protocol necessity.
>
>You state that your earlier flow violates RFC 3261, and in an earlier
>posting you insist that it should be supported because some
>implementations behave that way.  I have a real problem with this.
>Standards are meant to help in avoiding exactly this kind of situation
>and I don't think that non-standard behavior should be condoned by
>rtcweb.  If there is good reason to support this kind of flow then it
>should be brought to the appropriate working group for consideration
>(not rtcweb).  An endpoint could achieve similar behavior by mimicking
>standard serial forking procedures (which is what I thought you
>intended but you forgot to include the interim final responses or
>byes).  Why not just use a sequence of UPDATEs and avoid these hassles?
>
>The three use cases I had in mind were:
>
>1) mimicking standard serial forking from a single endpoint to realize
>the equivalent of multiple ANSWERs to a single OFFER (although separate
>OFFER/ANSWER transactions using UPDATE would be cleaner)
>2) standard serial forking (with optional UPDATEs)
>3) standard parallel forking (with optional UPDATEs)
>
>Do we really need anything other than 2) and 3)?
>
>Richard
>
>-----Original Message-----
>From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]
>Sent: Tuesday, February 21, 2012 2:51 PM
>To: Ejzak, Richard P (Richard); rtcweb@ietf.org; public-webrtc@w3.org;
>Randell Jesup
>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer
>[was: JSEP-02: SDP_PRANSWER and FEDEX use-case]
>
>Hi all,
>
>Till now, I'm writing the callflow with the assumption of browser as
>RTP Endpoint. Two JSEP example call flow are attached:
>
>       1) Two 180 with SDP (answer) and second 180's dialog comes up with 2xx
>with SDP
>      2) Two 180 with SDP (answer) and first 180's dialog comes up with
>2xx with SDP
>
>The above callflows are not the only way to solve the problem but it is
>one of the way to solve this callflow. The intention of these callflows
>are to indicate that multiple answers support in JSEP facilities for
>designing SIP parallel forking kind of services.  The exact intention
>is as per
>http://www.ietf.org/mail-archive/web/rtcweb/current/msg03455.html
>and as follows:
>
>1) allow a setRemoteDesc(SDP_ANSWER) to follow a
>setRemoteDesc(SDP_ANSWER)
>2) document that in this case (multiple 2xx), the JS is responsible for
>sending BYE to the previous answerer.
>
>Please let me know your comments on the callflow.
>
>Hi Richard,
>
>Thanks for your clarification in the below mail. Please read inline for
>more comments
>
>Thanks
>Partha
>
>>-----Original Message-----
>>From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel-
>>lucent.com]
>>Sent: Tuesday, February 21, 2012 8:05 PM
>>To: Ravindran, Parthasarathi; 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]
>>
>>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?).
>
><partha> I agree that this callflow is allowed in JSEP and it is a
>violation of RFC 3261 and not RFC 3264. I explained in detail why this
>callflow shall be allowed in http://www.ietf.org/mail-
>archive/web/rtcweb/current/msg03478.html </partha>
>
> How do you determine that this is a
>>special type of serial forking and not a parallel forking case?
>
><partha> I won't determine it. I will just update based on the last
>active answer. </partha>
>
> 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.
>>
><partha> Please mentioned the three of them. I'll provide the callflow
>for the same </partha>
>
>>Also, PRANSWER as currently defined seems to have no analog in SIP.
>>Is this also your understanding?
><partha> We have the common understanding here. I'm requesting to
>remove PR_ANSWER state as it complicates JS Offer/Answer FSM still more (See:
>http://www.ietf.org/mail-archive/web/rtcweb/current/msg03489.html).
></partha>
>
>>
>>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.
>>
><partha> Hope the callflow clarifies </partha>
>
>>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
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

Received on Wednesday, 22 February 2012 11:46:24 UTC