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

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Feb 2012 21:02:05 +0100

Hi,

A related question regarding resources.

Assume the following case:

1. A JS app requests the broswer to generate an offer (o-1), which the JS app sends away to the remote end (e.g. using SIP INVITE).
2. The JS app receives a provisional answer, and sends it to the browser using SDP_PRANSWER (I assume we will keep PRANSWER, but otherwise it could also be ANSWER).
3. The JS app requests a new offer (o-2) to be created by the browser.

The questions:

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).

Q2. If the JS app receives an answer for the first offer (o-1), will it send it to the browser, or will it discard it? If if sends it to the browser, what is the browser expected to do with it? I assume there is a way for the browser to determine (e.g. using the o- line) that the answer is for the first offer.

Q3. Is the JS app allowed to request a new offer in the first place, before the "final answer" has been provided to the browser (whatever the mechanism to inform the browser that an answer is the final one is)?

Regards,

Christer

________________________________________
From: Justin Uberti [[email-masked]]
Sent: Monday, February 20, 2012 5:12 PM
To: Christer Holmberg
Cc: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings; [email-masked]; [email-masked]
Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case

Right; if we retain PRANSWER, I think "may have more answers in the future" should be its meaning, and applications can map things like 18x to PRANSWER, if desired.

I agree that PRANSWER should not have implicit recvonly semantics, and we should use explicit directional attributes instead.

On Mon, Feb 20, 2012 at 7:59 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

We can do it with timers, PRANSWER, or both. I just think the browser at some point shall be able to determine that there will be no more answers to a given offer :)

Regards,

Christer

-----Original Message-----
From: Ravindran, Parthasarathi [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 20. helmikuuta 2012 13:53
To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case

Hi Christer,

I agree with you for the timer to release the unused offer resource from  offerer browser if it is really a constraint. This timer helps browser from badly designed webpage which sends offer but never complete answer. Let us get more opinion on this.

Timer mechanism shall be applicable with multiple SDP_ANSWER and there is no need of SDP_PRANSWER. The reason for requesting SDP_PRANSWER removal is to simplify O/A FSM in JS.  In case SDP_ANSWER before timer expires, setRemoteDescription returns success with updating answer in browser or else return failure. Please let me know your opinion on the same.

Thanks
Partha

>-----Original Message-----
>From: Christer Holmberg [mailto:[email-masked]<mailto:[email-masked]>]
>Sent: Monday, February 20, 2012 4:46 PM
>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>
>
>Hi,
>
>There could always be a mechanism, where the broswer automatically
>releases resources, if it hasn't received a SDP_ANSWER within a given
>time.
>
>Regards,
>
>Christer
>
>
>-----Original Message-----
>From: Ravindran, Parthasarathi [mailto:[email-masked]<mailto:[email-masked]>]
>Sent: 20. helmikuuta 2012 12:41
>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
>Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>
>Hi Christer,
>
>It is obvious fact that mobile devices has limited resource. The
>question is whether Mobile devices offer multiple codec during the
>initial offer and waiting to release during the final answer for saving
>memory resource. Final answer expecting design may have the impact
>because the badly designed webpage may hog the system easily by just
>sending offer & not mapping with answer and also in the scenario of
>answerer reply with multiple codec.
>
>As part of SRTP discussion, Eric clarifies that Media security (SRTP)
>is not an (CPU) performance issue in the endpoint. I could not
>understand about ICE issues as ICE is triggered based on the number of
>answer apart from the initial ICE procedure for offer.
>
>Thanks
>Partha
>
>>-----Original Message-----
>>From: Christer Holmberg [mailto:[email-masked]<mailto:[email-masked]>]
>>Sent: Monday, February 20, 2012 3:39 PM
>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>>Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>>
>>
>>Hi,
>>
>>Mobile devices (smartphones etc) will often have limited resources, no
>>matter whether the app is running as a browser app or a native app.
>>
>>Also, codec was only one example. A better example is perhaps
>>resources related to ICE, media security etc.
>>
>>Regards,
>>
>>Christer
>>
>>
>>-----Original Message-----
>>From: Ravindran, Parthasarathi [mailto:[email-masked]<mailto:[email-masked]>]
>>Sent: 20. helmikuuta 2012 11:55
>>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
>>Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>>
>>Hi Christer,
>>
>>Even I had thought through Cullen statement before reply to him in the
>>another mail thread. As per your clarification, Each Codec (like g711
>>library, g729 library) will be loaded in the memory in the run-time
>>based on offer and released based on the final answer for the memory
>>saving. I agree that this mechanism is useful for DSP based VoIP
>>endpoints wherein it is possible to load only one codec (or few codec)
>>at the same time, mostly only one of the codec (first codec) will be
>>loaded based on the answer and send Re-INVITE to indicate the
>>committed codec in DSP. My understanding is that the same issue does
>>not exists for WebRTC browser running in laptop, desktop and those
>>devices will be capable of loading the multiple codec without
>>impacting the system performance. Please correct me in case I
>>misunderstand the system design here. I'm not very sure about
>>Smartphone architecture w.r.t multiple codec handling.
>>
>>I have asked for 18x with SDP and 2xx without SDP scenario just to
>>indicate the complication building up in the JavaScript offer/answer
>>FSM because of the (provisional/final) response specific offer/answer
>model.
>>
>>Thanks
>>Partha
>>
>>>-----Original Message-----
>>>From: Christer Holmberg [mailto:[email-masked]<mailto:[email-masked]>]
>>>Sent: Monday, February 20, 2012 12:51 PM
>>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>>>Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>>>
>>>
>>>Hi,
>>>
>>>> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER
>>>> as equivalent to moreComing=true/false in ROAP. Also, we need to
>>>> consider
>>>the scenario like 18x with SDP (SDP_PRANSWER) and 2xx without SDP
>>>wherein JS has to take care of SDP_ANSWER even though it does not
>>>receive one. IMO, Multiple answer issue is not fully solved in ROAP
>>>as well.
>>>
>>>In that case, I guess the JS app could simply take a previous
>>>SDP_PRANSWER, and send it as SDP_ANSWER.
>>>
>>>> Also, I have the problem in the understanding the strong need for
>>>differentiating answer and final answer. Could you please clarify it.
>>>
>>>I had exactly the same issue, but what Cullen told me last week made
>>>me re-think. It's all about resources :)
>>>
>>>So, take the following example:
>>>
>>>1. The browser creates an offer, and reservers resrouces for codecs X
>>>and Y.
>>>2. At some point, the browser receives a PRANSWER, with only codec X.
>>>However, the browser still keeps the resources for Y, as a new answer
>>>may come.
>>>3. At some point, the browser receives another PRANSWER (maybe
>>>forking has occured), with only codec Y. However, the browser still
>>>keeps the resources for X (again, as a new answer may come).
>>>4. At some point, the browser recieves an ANSWER, with only codec X.
>>>Now, as this is the last answer, the browser can release the
>>>resources for Y.
>>>
>>>So, the main difference is related to the resources associated with
>>>the offer. Once a final answer (ANSWER) has been received, and
>>>resources that were reserved for the offer, but are no longer needed,
>>>can be released.
>>>
>>>(Cullen, please correct me if I've missunderstood :)
>>>
>>>Regards,
>>>
>>>Christer
>>>
>>>
>>>>-----Original Message-----
>>>>From: Christer Holmberg [mailto:[email-masked]<mailto:[email-masked]>]
>>>>Sent: Monday, February 20, 2012 12:12 PM
>>>>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings
>>>>Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>>>Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>>>>
>>>>
>>>>Hi,
>>>>
>>>>In my opinion, even if we do need SDP_PRANSWER (Cullen may have
>>>>convinced me that there is a need for it :), I don't think it should
>>>>have an implicit "recvonly" meaning.
>>>>
>>>>PRANSWER or ANSWER, I think we shall use the SDP direction attribute
>>>>(or some other explicit elements) to indicate media direction.
>>>>
>>>>Regards,
>>>>
>>>>Christer
>>>>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>>>>Behalf Of Hutton, Andrew
>>>>Sent: 19. helmikuuta 2012 23:26
>>>>To: Ravindran, Parthasarathi; Cullen Jennings
>>>>Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>>>Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>>>>
>>>>Hi,
>>>>
>>>>Yes absolutely I have come across a number of scenarios in the US
>>>>and in Europe where media is needed in the forward direction for
>>>>DTMF input after receiving a 18x response and before the 200OK. IF I
>>>>remember correctly calling FEDEX was actually one of the real life
>>examples.
>>>>
>>>>Regards
>>>>Andy
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Ravindran, Parthasarathi [mailto:[email-masked]<mailto:[email-masked]>]
>>>>> Sent: 19 February 2012 17:53
>>>>> To: Cullen Jennings; Hutton, Andrew
>>>>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>>>> Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>>>>>
>>>>> Cullen,
>>>>>
>>>>> AFAIK, 18x with sendrecv as direction attribute & DTMF (telephony-
>>>>> event) is allowed by couple of operators in FEDEX (call center)
>>>>> scenario. Andy will be able to double confirm whether he also
>>>>> comes across the similar deployment.
>>>>>
>>>>> Thanks
>>>>> Partha
>>>>>
>>>>>
>>>>>
>>>>> >-----Original Message-----
>>>>> >From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>>>>> Behalf
>>>>> >Of Cullen Jennings
>>>>> >Sent: Saturday, February 18, 2012 2:29 AM
>>>>> >To: Hutton, Andrew
>>>>> >Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>>>> >Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
>>>>> >
>>>>> >
>>>>> >On Feb 16, 2012, at 1:04 PM, Hutton, Andrew wrote:
>>>>> >
>>>>> >>> (Also, in the FEDEX case, there could be scenarios where the
>>>>> browser
>>>>> >>> does need to transit media, if the user is e.g. promted for
>>>>> >>> DTMFs, voice commands etc...)
>>>>> >>>
>>>>> >>
>>>>> >> [AndyH] - I agree that media transmission is required at this
>>>>> >> stage
>>>>> so
>>>>> >that the user can navigate through voice prompts (E.g. via DTMF)
>>>>> >I thought this was the main requirement from the FEDEX use case.
>>>>> >
>>>>> >that's not my understanding. My understanding was it was one way
>>>>> >media until the final response in the early media case. And the
>>>>> >IVR sends
>>>>> the
>>>>> >first prompt as ringtone but cuts over before two way media (IE
>>>>> >DTMF)
>>>>> is
>>>>> >needed. The whole point of this hack is to cut the time the IVR
>>>>> >gets billed for but the SP is not going to provide two way media
>>>>> >before billing starts.
>>>>> >
>>>>> >
>>>>> >_______________________________________________
>>>>> >rtcweb mailing list
>>>>> >[email-masked]<mailto:[email-masked]>
>>>>> >https://www.ietf.org/mailman/listinfo/rtcweb
>>>>_______________________________________________
>>>>rtcweb mailing list
>>>>[email-masked]<mailto:[email-masked]>
>>>>https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Feb 2012 21:04:50 +0100

Just a clarification regarding Q1. The browser will of course keep the resources associated with o-1 until the new offer has been accepted by the remote party, and can be taken into use.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Christer Holmberg [[email-masked]]
Sent: Monday, February 20, 2012 10:02 PM
To: Justin Uberti
Cc: [email-masked]; [email-masked]
Subject: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case]

Hi,

The questions:

Regards,

Christer

Hi,

Regards,

Christer

-----Original Message-----
From: Ravindran, Parthasarathi [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 20. helmikuuta 2012 13:53
To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case

Hi Christer,

Thanks
Partha

[email-masked]

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Feb 2012 21:13:58 +0100

> 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
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Feb 2012 21:14:59 +0100

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 [[email-masked]]
Sent: Monday, February 20, 2012 10:13 PM
To: Christer Holmberg
Cc: Justin Uberti; [email-masked]; [email-masked]
Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case]

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 20 Feb 2012 15:31:25 -0500

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 <
[email-masked]> 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
> Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer
> [was: JSEP-02: SDP_PRANSWER and FEDEX use-case]
>
> > 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).
>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 20 Feb 2012 17:01:43 -0500

On 2/20/2012 3:31 PM, Roman Shpount wrote:
> 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
> <[email-masked] <mailto:[email-masked]>>
> 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.
>
>     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 [[email-masked] <mailto:[email-masked]>]
>     Cc: Justin Uberti; [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>
>     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 <[email-masked]
>     <mailto:[email-masked]>>:
>      > 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).
>
>     <[email-masked] <mailto:[email-masked]>>
>     [email-masked] <mailto:[email-masked]>

-- 
Randell Jesup
[email-masked]

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 20 Feb 2012 17:35:50 -0600

I am concerned about an earlier suggestion that multiple SDP answers can be handled in SIP by forking separate dialogs without supporting forking of the media streams.  

This raises some questions: Is there a difference between multiple answers within a dialog (not currently supported in SIP and RFC 3264 but presumably a behavior some would like to be supported) and parallel forking?  Is it understood that all PRANSWERs and ANSWERs are in separate dialogs?  Or can there be multiple PRANSWERs associated with a final ANSWER for a forked dialog?  If we are to support forking then there has to be a clear way of associating sets of (PR)ANSWERs with each dialog (this concept still remains valid if the signaling protocol is not SIP) and how to resolve resource conflicts between them.

Richard Ejzak

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 21 Feb 2012 03:52:05 +0000

Richard,

I didn't understand your question w.r.t SIP. As per RFC 3261, SIP UAC with RTP endpoint (not RTP mixer) also MUST support multiple SDP answers in case of (serial & parallel) forked responses. It is matter of SIP UA application design to accommodate those callflows.

Hi all,

My concern with PRANSWER state in offer/answer (O/A) model is that JSEP JS application will be more complicated than SIP UA application as SIP UA application O/A has only two states (offer & answer) whereas JSEP JS has to maintain 3 states with different set of responses. 

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Ejzak, Richard P (Richard)
>Sent: Tuesday, February 21, 2012 5:06 AM
>To: [email-masked]
>I am concerned about an earlier suggestion that multiple SDP answers can
>be handled in SIP by forking separate dialogs without supporting forking
>of the media streams.
>
>This raises some questions: Is there a difference between multiple
>answers within a dialog (not currently supported in SIP and RFC 3264 but
>presumably a behavior some would like to be supported) and parallel
>forking?  Is it understood that all PRANSWERs and ANSWERs are in
>separate dialogs?  Or can there be multiple PRANSWERs associated with a
>final ANSWER for a forked dialog?  If we are to support forking then
>there has to be a clear way of associating sets of (PR)ANSWERs with each
>dialog (this concept still remains valid if the signaling protocol is
>not SIP) and how to resolve resource conflicts between them.
>
>Richard Ejzak
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 21 Feb 2012 06:58:19 +0000

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

>Of Randell Jesup
>Sent: Tuesday, February 21, 2012 3:32 AM
>To: [email-masked]; [email-masked]

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 21 Feb 2012 08:34:55 -0600

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: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran, Parthasarathi
Sent: Tuesday, February 21, 2012 12:58 AM
To: Randell Jesup; [email-masked]; [email-masked]
Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case]

Randell,

Thanks
Partha

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 21 Feb 2012 20:51:02 +0000

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

>From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel-
>lucent.com]
>Sent: Tuesday, February 21, 2012 8:05 PM
>To: Ravindran, Parthasarathi; [email-masked]; [email-masked]
>Subject: RE: [rtcweb] JSEP-02: New offer and answer to previous offer
>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>

>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>

>Of Ravindran, Parthasarathi
>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
>
>>From: [email-masked] [mailto:[email-masked]] On
>>Behalf Of Randell Jesup
>>> 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.
>>
>>(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.
>>
>>and it may be over-reaching, but each 1/2 RTT removed is significant,
>>so there may be uses.
>>
>>> _____________
>>> Roman Shpount
>>>
>>>

---

From: "Jim Barnett" <[email-masked]>
Date: Tue, 21 Feb 2012 13:12:39 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran, Parthasarathi
Sent: Tuesday, February 21, 2012 3:51 PM
To: EJZAK Richard; [email-masked]; [email-masked]; 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,

Hi Richard, 

Thanks
Partha

>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.
>

 We have

>Behalf Of Ravindran, Parthasarathi
>>> 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.
>>
>>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?
>>
>>
>>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.
>>
>>forwarding it (forking it) to the new user, who would answer and 
>>they'd be in a call.
>>
>>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
>>>
>>>

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 21 Feb 2012 16:44:52 -0600

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:[email-masked]] 
Sent: Tuesday, February 21, 2012 2:51 PM
To: Ejzak, Richard P (Richard); [email-masked]; [email-masked]; 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,

Hi Richard, 

Thanks
Partha

 We have

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 22 Feb 2012 03:31:41 +0000

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

>Sent: Wednesday, February 22, 2012 4:15 AM
>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?
>
>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)
>Till now, I'm writing the callflow with the assumption of browser as RTP
>Endpoint. Two JSEP example call flow are attached:
>
>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:
>
><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>
>
><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>
>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Feb 2012 12:45:54 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran, Parthasarathi
Sent: 22. helmikuuta 2012 5:32
To: Ejzak, Richard P (Richard); [email-masked]; [email-masked]
Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case]

Hi Richard,

Thanks
Partha

>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.
>
>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?
>
>Till now, I'm writing the callflow with the assumption of browser as
>RTP Endpoint. Two JSEP example call flow are attached:
>
>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:
>
>>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> We have the common understanding here. I'm requesting to
>remove PR_ANSWER state as it complicates JS Offer/Answer FSM still more (See:
>>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.
>>
>>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.
>>
>>>> have parallel forking"? WebRTC intorduces additional restrictions
>>>> on RTP stream (remote media sources and SSRCs are known in advance)
>>>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
>>>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.
>>>
>>>>     The browser can of course send a just-audio offer somewhere,
>>>> and
>>a
>>>>     offer/answer, which is the reason it has been suggested e.g.
>>>> not
>>>to

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 22 Feb 2012 11:54:22 +0000

Hi Christer,

I guess that we are talking the same in the different words. My intention is not to support parallel forking in browser (no RTP mixing and no cloning of peerconnection) but supporting SIP parallel forking callflows using JSEP multiple answer mechanism. So, any new answer in parallel forking will replace the previous one in the browser and only one active media stream is possible. Please let me where we are differing in this discussion.

Thanks
Partha

>From: Christer Holmberg [mailto:[email-masked]]
>Sent: Wednesday, February 22, 2012 5:16 PM
>To: Ravindran, Parthasarathi; Ejzak, Richard P (Richard);
>[email-masked]; [email-masked]
>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.
>
>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
>

---

From: "Khan, Sohel" <[email-masked]>
Date: Wed, 22 Feb 2012 15:18:30 +0000

Partha,

If possible, please minimize the use of PRACK in the call flow. We would like to have call flows simple and less chatty.

Sohel

-----Original Message-----
From: Ravindran, Parthasarathi [mailto:[email-masked]] 
Sent: Tuesday, February 21, 2012 10:32 PM
To: Ejzak, Richard P (Richard); [email-masked]; [email-masked]
Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case]

Hi Richard,

Thanks
Partha

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 27 Feb 2012 02:14:55 +0000

Hi Richard/Sohel,

I attached updated 3 callflows with this mail.

1) Single offer and multiple answer
2) SIP Serial forking
3) SIP Parallel forking

I have add the comment "Handling of Reliable response PRACK and 200 is not shown for simplicity" to indicate about Standard SIP callflow. Please let me know your comment on this.

Thanks
Partha

>From: Khan, Sohel [mailto:[email-masked]]
>Sent: Wednesday, February 22, 2012 8:49 PM
>If possible, please minimize the use of PRACK in the call flow. We would
>like to have call flows simple and less chatty.
>
>Sohel
>
>>	1) Two 180 with SDP (answer) and second 180's dialog comes up with
>2xx
>>with SDP

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 27 Feb 2012 02:18:36 +0000

Jim,

As you expect, there is no ICE restart in the callflow. My understanding about onOpen callback is that it is received in JS whenever the connectivity check is completed with the peer and in case of multiple answer, the callback will be thrown per peer connectivity check completion. 

Thanks
Partha

>From: Jim Barnett [mailto:[email-masked]]
>Sent: Wednesday, February 22, 2012 2:43 AM
>To: Ravindran, Parthasarathi; EJZAK Richard; [email-masked]; public-
>[email-masked]; Randell Jesup
>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
>
>2xx with SDP

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Feb 2012 11:36:02 +0100

Hi,

I guess the UPDATE is something you send just as an "optimization" (in order to avoid media to be transmitted by one remote party), but it's not something you suggest to be mandated from an API perspective?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran, Parthasarathi
Sent: 27. helmikuuta 2012 4:15
To: Khan, Sohel; Ejzak, Richard P (Richard); [email-masked]; [email-masked]
Subject: Re: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case]

Hi Richard/Sohel,

Thanks
Partha

>If possible, please minimize the use of PRACK in the call flow. We
>would like to have call flows simple and less chatty.
>
>Sohel
>
>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) :-)
>
>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
>
>>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.
>>
>>the equivalent of multiple ANSWERs to a single OFFER (although
>>separate OFFER/ANSWER transactions using UPDATE would be cleaner)
>>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
>>2) document that in this case (multiple 2xx), the JS is responsible
>>for sending BYE to the previous answerer.
>>
>>remove PR_ANSWER state as it complicates JS Offer/Answer FSM still
>>more
>(See:
>>>parallel forking by keeping only one answer active in the offerer
>>>side at the given time".  It would appear that an implementation of
>>>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
>>>>offer
>>>>> 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.
>>>>
>>>>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
>>>>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
>>>>>     resources etc associated with o-1 will be released (unless
>>>>> they
>>>>are
>>>>>     But, why couldn't the browser send a just-audio offer
>>>>> somewhere
>>>>and a

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 27 Feb 2012 11:27:53 +0000

Hi Christer,

You are right that UPDATE is just for optimization and there is nothing mandated in API. 

Thanks
Partha

>Sent: Monday, February 27, 2012 4:06 PM
>To: Ravindran, Parthasarathi; Khan, Sohel; Ejzak, Richard P (Richard);
>I guess the UPDATE is something you send just as an "optimization" (in
>order to avoid media to be transmitted by one remote party), but it's
>not something you suggest to be mandated from an API perspective?
>
>Regards,
>
>Christer
>
>
>I have add the comment "Handling of Reliable response PRACK and 200 is
>not shown for simplicity" to indicate about Standard SIP callflow.
>Please let me know your comment on this.
>
>Thanks
>Partha
>