RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case

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] 
Sent: 20. helmikuuta 2012 13:53
To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
Cc: rtcweb@ietf.org; 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]
>Sent: Monday, February 20, 2012 4:46 PM
>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>Cc: rtcweb@ietf.org; 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]
>Sent: 20. helmikuuta 2012 12:41
>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
>Cc: rtcweb@ietf.org; 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]
>>Sent: Monday, February 20, 2012 3:39 PM
>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>>Cc: rtcweb@ietf.org; 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]
>>Sent: 20. helmikuuta 2012 11:55
>>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
>>Cc: rtcweb@ietf.org; 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]
>>>Sent: Monday, February 20, 2012 12:51 PM
>>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>>>Cc: rtcweb@ietf.org; 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]
>>>>Sent: Monday, February 20, 2012 12:12 PM
>>>>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings
>>>>Cc: rtcweb@ietf.org; 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] On 
>>>>Behalf Of Hutton, Andrew
>>>>Sent: 19. helmikuuta 2012 23:26
>>>>To: Ravindran, Parthasarathi; Cullen Jennings
>>>>Cc: rtcweb@ietf.org; 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]
>>>>> Sent: 19 February 2012 17:53
>>>>> To: Cullen Jennings; Hutton, Andrew
>>>>> Cc: public-webrtc@w3.org; 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] On
>>>>> Behalf
>>>>> >Of Cullen Jennings
>>>>> >Sent: Saturday, February 18, 2012 2:29 AM
>>>>> >To: Hutton, Andrew
>>>>> >Cc: public-webrtc@w3.org; 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
>>>>> >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 13:00:32 UTC