Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
"Ravindran, Parthasarathi" <pravindran@sonusnet.com> Mon, 20 February 2012 11:52 UTC
Return-Path: <pravindran@sonusnet.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012DC21F8749 for <rtcweb@ietfa.amsl.com>; Mon, 20 Feb 2012 03:52:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level:
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcsJToMWEvff for <rtcweb@ietfa.amsl.com>; Mon, 20 Feb 2012 03:52:51 -0800 (PST)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 933AD21F872B for <rtcweb@ietf.org>; Mon, 20 Feb 2012 03:52:51 -0800 (PST)
Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1KBrZuG013670; Mon, 20 Feb 2012 06:53:35 -0500
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 06:52:47 -0500
Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 17:22:59 +0530
Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Mon, 20 Feb 2012 17:22:59 +0530
From: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>, Cullen Jennings <fluffy@iii.ca>
Thread-Topic: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
Thread-Index: AQHM7IE9KMJ367wTfUugOb7j2iGwS5Y/lw0AgAGhwICAA0qV0IAAPNUggACbz/CAAAEzEIAACBRAgAASIBCAAB2GgIAABh6AgAANu/CAAAYSQA==
Date: Mon, 20 Feb 2012 11:52:58 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E040D32@inba-mail01.sonusnet.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E060@ESESSCMS0356.eemea.ericsson.se> <3CBDF06F-F52D-4C09-A78F-1A0D8479572A@iii.ca> <7F2072F1E0DE894DA4B517B93C6A05852C3D87E58F@ESESSCMS0356.eemea.ericsson.se> <101C6067BEC68246B0C3F6843BCCC1E31202EDA663@MCHP058A.global-ad.net> <15CD1ECE-6BDD-4EE0-AA5B-EF40616578CD@iii.ca> <387F9047F55E8C42850AD6B3A7A03C6C0E040A1D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312942242CD@MCHP058A.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C60E1@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C04@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C6134@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040C6D@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D8C630B@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E040CBF@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C49@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D914C49@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.70.54.70]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Feb 2012 11:52:59.0888 (UTC) FILETIME=[316FDF00:01CCEFC6]
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Feb 2012 11:52:56 -0000
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
- [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case Christer Holmberg
- Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-… Ravindran, Parthasarathi
- Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-… Cullen Jennings
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Christer Holmberg
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Hutton, Andrew
- Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-… Justin Uberti
- Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-… Christer Holmberg
- Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-… Justin Uberti
- Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-… Bernard Aboba
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Cullen Jennings
- Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-… Christer Holmberg
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Ravindran, Parthasarathi
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Ravindran, Parthasarathi
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Hutton, Andrew
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Christer Holmberg
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Christer Holmberg
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Iñaki Baz Castillo
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Ravindran, Parthasarathi
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Christer Holmberg
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Ravindran, Parthasarathi
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Roman Shpount
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Christer Holmberg
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Ravindran, Parthasarathi
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Christer Holmberg
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Ravindran, Parthasarathi
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Iñaki Baz Castillo
- Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-… Justin Uberti