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

One detail on the examples.  As I understand section 5.1.3 of the JSEP draft, the second argument to iceCallback is a flag indicating whether more ICE candidates are coming.  So when iceCallback is called with 'false' as the second argument, it means ICE is done.  In line 10 of your examples, I see such a callback, but then later in the example at line 21 I see "ICE completes (at Offerer)".   Has ICE somehow been restarted in the interim, or am I misunderstanding the example (or section 5.1.3)?

- Jim

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ravindran, Parthasarathi
Sent: Tuesday, February 21, 2012 3:51 PM
To: EJZAK 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 Tuesday, 21 February 2012 21:13:25 UTC