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 07:21:05 UTC