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

Received on Thursday, 23 February 2012 09:25:00 UTC