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

["Ravindran, Parthasarathi" <[e-mail]>]

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:[e-mail]]
>Sent: Monday, February 20, 2012 4:46 PM
>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>Cc: [e-mail]; [e-mail]
>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:[e-mail]]
>Sent: 20. helmikuuta 2012 12:41
>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
>Cc: [e-mail]; [e-mail]
>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:[e-mail]]
>>Sent: Monday, February 20, 2012 3:39 PM
>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>>Cc: [e-mail]; [e-mail]
>>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:[e-mail]]
>>Sent: 20. helmikuuta 2012 11:55
>>To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
>>Cc: [e-mail]; [e-mail]
>>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:[e-mail]]
>>>Sent: Monday, February 20, 2012 12:51 PM
>>>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>>>Cc: [e-mail]; [e-mail]
>>>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:[e-mail]]
>>>>Sent: Monday, February 20, 2012 12:12 PM
>>>>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings
>>>>Cc: [e-mail]; [e-mail]
>>>>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: [e-mail] [mailto:[e-mail]] On
>>>>Behalf Of Hutton, Andrew
>>>>Sent: 19. helmikuuta 2012 23:26
>>>>To: Ravindran, Parthasarathi; Cullen Jennings
>>>>Cc: [e-mail]; [e-mail]
>>>>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:[e-mail]]
>>>>> Sent: 19 February 2012 17:53
>>>>> To: Cullen Jennings; Hutton, Andrew
>>>>> Cc: [e-mail]; [e-mail]
>>>>> 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: [e-mail] [mailto:[e-mail]] On
>>>>> Behalf
>>>>> >Of Cullen Jennings
>>>>> >Sent: Saturday, February 18, 2012 2:29 AM
>>>>> >To: Hutton, Andrew
>>>>> >Cc: [e-mail]; [e-mail]
>>>>> >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
>>>>> >[e-mail]
>>>>> >https://www.ietf.org/mailman/listinfo/rtcweb
>>>>_______________________________________________
>>>>rtcweb mailing list
>>>>[e-mail]
>>>>https://www.ietf.org/mailman/listinfo/rtcweb