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

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: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg [christer.holmberg@ericsson.com]
Sent: Monday, February 20, 2012 10:02 PM
To: Justin Uberti
Cc: rtcweb@ietf.org; public-webrtc@w3.org
Subject: [rtcweb] JSEP-02: New offer and answer to previous offer [was: JSEP-02: SDP_PRANSWER and FEDEX use-case]

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 [juberti@google.com]
Sent: Monday, February 20, 2012 5:12 PM
To: Christer Holmberg
Cc: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings; rtcweb@ietf.org; public-webrtc@w3.org
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 <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> 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:pravindran@sonusnet.com<mailto:pravindran@sonusnet.com>]
Sent: 20. helmikuuta 2012 13:53
To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
Cc: rtcweb@ietf.org<mailto:rtcweb@ietf.org>; public-webrtc@w3.org<mailto:public-webrtc@w3.org>
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:christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>]
>Sent: Monday, February 20, 2012 4:46 PM
>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>Cc: rtcweb@ietf.org<mailto:rtcweb@ietf.org>; public-webrtc@w3.org<mailto:public-webrtc@w3.org>
>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:pravindran@sonusnet.com<mailto:pravindran@sonusnet.com>]
>Sent: 20. helmikuuta 2012 12:41
>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
>Cc: rtcweb@ietf.org<mailto:rtcweb@ietf.org>; public-webrtc@w3.org<mailto:public-webrtc@w3.org>
>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:christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>]
>>Sent: Monday, February 20, 2012 3:39 PM
>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>>Cc: rtcweb@ietf.org<mailto:rtcweb@ietf.org>; public-webrtc@w3.org<mailto:public-webrtc@w3.org>
>>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:pravindran@sonusnet.com<mailto:pravindran@sonusnet.com>]
>>Sent: 20. helmikuuta 2012 11:55
>>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
>>Cc: rtcweb@ietf.org<mailto:rtcweb@ietf.org>; public-webrtc@w3.org<mailto:public-webrtc@w3.org>
>>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:christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>]
>>>Sent: Monday, February 20, 2012 12:51 PM
>>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>>>Cc: rtcweb@ietf.org<mailto:rtcweb@ietf.org>; public-webrtc@w3.org<mailto:public-webrtc@w3.org>
>>>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:christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>]
>>>>Sent: Monday, February 20, 2012 12:12 PM
>>>>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings
>>>>Cc: rtcweb@ietf.org<mailto:rtcweb@ietf.org>; public-webrtc@w3.org<mailto:public-webrtc@w3.org>
>>>>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: rtcweb-bounces@ietf.org<mailto:rtcweb-bounces@ietf.org> [mailto:rtcweb-bounces@ietf.org<mailto:rtcweb-bounces@ietf.org>] On
>>>>Behalf Of Hutton, Andrew
>>>>Sent: 19. helmikuuta 2012 23:26
>>>>To: Ravindran, Parthasarathi; Cullen Jennings
>>>>Cc: rtcweb@ietf.org<mailto:rtcweb@ietf.org>; public-webrtc@w3.org<mailto:public-webrtc@w3.org>
>>>>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:pravindran@sonusnet.com<mailto:pravindran@sonusnet.com>]
>>>>> Sent: 19 February 2012 17:53
>>>>> To: Cullen Jennings; Hutton, Andrew
>>>>> Cc: public-webrtc@w3.org<mailto:public-webrtc@w3.org>; rtcweb@ietf.org<mailto:rtcweb@ietf.org>
>>>>> 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: rtcweb-bounces@ietf.org<mailto:rtcweb-bounces@ietf.org> [mailto:rtcweb-bounces@ietf.org<mailto:rtcweb-bounces@ietf.org>] On
>>>>> Behalf
>>>>> >Of Cullen Jennings
>>>>> >Sent: Saturday, February 18, 2012 2:29 AM
>>>>> >To: Hutton, Andrew
>>>>> >Cc: public-webrtc@w3.org<mailto:public-webrtc@w3.org>; rtcweb@ietf.org<mailto:rtcweb@ietf.org>
>>>>> >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
>>>>> >rtcweb@ietf.org<mailto:rtcweb@ietf.org>
>>>>> >https://www.ietf.org/mailman/listinfo/rtcweb
>>>>_______________________________________________
>>>>rtcweb mailing list
>>>>rtcweb@ietf.org<mailto:rtcweb@ietf.org>
>>>>https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
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

Received on Monday, 20 February 2012 20:06:15 UTC