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 11:16:21 UTC