W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2012

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

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Mon, 20 Feb 2012 11:08:37 +0100
To: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>, "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>, Cullen Jennings <fluffy@iii.ca>
CC: "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C630B@ESESSCMS0356.eemea.ericsson.se>

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 10:09:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:27 UTC