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> 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]
> 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
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>