Subject: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Feb 2012 11:47:42 +0100

Hi,

Section 6.1.4 of jsep-01 says:

        "SDP_PRANSWER indicates that a description should be parsed as an
        answer, but not a final answer, and so should not result in the
        starting of media transmission. A description used as a SDP_PRANSWER
        may be applied as a response to a SDP_OFFER, or an update to a
        previously sent SDP_PRANSWER."

Section 7.6 shows a SIP early media (FEDEX) use-case, where an SDP answer received in a SIP 18x response is provided to the browser as a SDP_PRANSWER.

Q1: Since SDP_PRANSWER is not supposed to start media transmission, how will the use-case work? As far as I know, media transmission is needed for the FEDEX use-case.

Q2: The draft doesn't really specify what SDP_PRANSWER is used for. I understand that it means that a "final" answer may be provided later, but it doesn't really say what the a browser would do with an SDP_PRANSWER - especially since it doesn't seem to enable media.

Q3: Assuming we would allow multiple SDP_ANSWER (see separate thread), is there a need for SDP_PRANSWER?

Regards,

Christer

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 15 Feb 2012 10:56:20 +0000

Hi Christer,

I agree with you that SDP_PRANSWER is not need in case multiple answer is supported.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, February 15, 2012 4:18 PM
To: [email-masked]; [email-masked]
Subject: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case

Hi,

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 15 Feb 2012 22:40:34 -0800

Answering for the the -02 version of jsep …

> Q1: Since SDP_PRANSWER is not supposed to start media transmission, how will the use-case work? As far as I know, media transmission is needed for the FEDEX use-case.

Consider a browser A that implemented a protocol something like ROAP using the JSEP API so it is going to a ROAP to SIP GW then then goes to a GW to the PSTN that calls 1-800 go fedex. 

The browser does a createOffer followed by setLocal with offer and sends the offer to the ROAP to SIP GW which turns it into an INVITE with offer to the PSTN GW. At this point the browse is listening to any media the PSTN GW might send. The PSTN GW sends 180 with SDP  that gets mapped  back to a setRemote with SDP_PRANSWER. That allows the browser and GW to do ICE, DTLS , etc and at this point the PSTN GW can start sending media to the browser. Given we just need 1 way media at this point, not sure it matter much if browser sends any media or not. At the point the SIP 200 happens, that gets mapped to a final answer.

> Q2: The draft doesn't really specify what SDP_PRANSWER is used for. I understand that it means that a "final" answer may be provided later, but it doesn't really say what the a browser would do wit…

I think the key thing is when the JS sets new SDP_OFFER in setLocal, it needs to be willing to receive the old media and the media for the new SDP. A final answers means you not longer need to to be able to receive the media for the old SDP. A provisional offer does not allow you stop being able to receive the media for the old SDP. 

> 
> Regards,
>  
> Christer
>  
>  
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Feb 2012 09:01:26 +0100

Hi, 

(I changed the subject to JSEP-02)

>> Q1: Since SDP_PRANSWER is not supposed to start media transmission, how will the use-case work? As 
>> far as I know, media transmission is needed for the FEDEX use-case.
>
> Consider a browser A that implemented a protocol something like ROAP using the JSEP API so it is 
> going to a ROAP to SIP GW then then goes to a GW to the PSTN that calls 1-800 go fedex. 
>
> The browser does a createOffer followed by setLocal with offer and sends the offer to the ROAP 
> to SIP GW which turns it into an INVITE with offer to the PSTN GW. At this point the browse is 
> listening to any media the PSTN GW might send. The PSTN GW sends 180 with SDP  that gets mapped  
> back to a setRemote with SDP_PRANSWER. That allows the browser and GW to do ICE, DTLS , etc and 
> at this point the PSTN GW can start sending media to the browser. Given we just need 1 way media 
> at this point, not sure it matter much if browser sends any media or not. At the point the SIP 200 
> happens, that gets mapped to a final answer.

If we want unidirectional media, can't the same be achieved e.g. with SDP_ANSWER and a=recvonly?

(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...)

>> Q2: The draft doesn't really specify what SDP_PRANSWER is used for. I understand that it means 
>> that a "final" answer may be provided later, but it doesn't really say what the a browser would 
>> do with an SDP_PRANSWER - especially since it doesn't seem to enable media.
>
> I think the key thing is when the JS sets new SDP_OFFER in setLocal, it needs to be willing to 
> receive the old media and the media for the new SDP. A final answers means you not longer need 
> to to be able to receive the media for the old SDP. A provisional offer does not allow you stop 
> being able to receive the media for the old SDP. 

That sounds very strange to me (and it's not described anywhere). In my opinoin - once an answer has been received, the browser starts using it, together with the associated offer.

Also, I don't see the need for your described behavior in the FEDEX case. Because, since the use-case takes place during session establishment, the most likely is no old SDP. So, you could as well use SDP_ANSWER, and when the call has been answered a new SDP_ANSWER.

Regards,

Christer

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 16 Feb 2012 21:04:04 +0100

See below.

> -----Original Message-----
> Sent: 16 February 2012 09:01
> To: Cullen Jennings
> Cc: [email-masked]; [email-masked]
> Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
> 
> 
> Hi,
> 
> >> Section 7.6 shows a SIP early media (FEDEX) use-case, where an SDP
> answer received in a SIP 18x response is provided to the browser as a
> SDP_PRANSWER.
> >>
> >>
> (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 sounds very strange to me (and it's not described anywhere). In my
> opinoin - once an answer has been received, the browser starts using
> it, together with the associated offer.
> 
> Also, I don't see the need for your described behavior in the FEDEX
> case. Because, since the use-case takes place during session
> establishment, the most likely is no old SDP. So, you could as well use
> SDP_ANSWER, and when the call has been answered a new SDP_ANSWER.
> 
> 
> Regards,
> 
> Christer

---

From: Justin Uberti <[email-masked]>
Date: Thu, 16 Feb 2012 21:17:07 -0500

On Wed, Feb 15, 2012 at 5:47 AM, Christer Holmberg <
[email-masked]> wrote:

> Section 7.6 shows a SIP early media (FEDEX) use-case, where an SDP answer
> received in a SIP 18x response is provided to the browser as a SDP_PRANSWER.
>
>
> Q1: Since SDP_PRANSWER is not supposed to start media transmission, how
> will the use-case work? As far as I know, media transmission is needed for
> the FEDEX use-case.
>

I think this is just me being unclear. When I say "start media
transmission", I mean that when the browser gets a SDP_PRANSWER in response
to an offer, the browser will not start transmitting media. However, it
will play out any media that is received after the offer is installed, and
the gateway can start sending media at any time after it gets the offer.

>
> Q2: The draft doesn't really specify what SDP_PRANSWER is used for. I
> understand that it means that a "final" answer may be provided later, but
> it doesn't really say what the a browser would do with an SDP_PRANSWER -
> especially since it doesn't seem to enable media.
>

SDP_PRANSWER allows, among other things, the callee's ICE and SRTP info to
be provided so that early media can be received by the caller. I think it
should make more sense given my answer to #1.

> there a need for SDP_PRANSWER?

SDP_PRANSWER has slightly different semantics in that it is not intended to
indicate consent by the callee, whereas SDP_ANSWER does.

I still need to review the other thread; there may be other ways of
handling this, but this seemed like the simplest to me.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Feb 2012 09:33:55 +0100

Hi, 
	 
> I think this is just me being unclear. When I say "start media transmission", I mean that when the browser gets a SDP_PRANSWER 
> in response to an offer, the browser will not start transmitting media. However, it will play out any media that is received 
> after the offer is installed, and the gateway can start sending media at any time after it gets the offer.

Again, you could achieve that using SDP_ANSWER and a direction attribute (a=recvonly). I don't think we need SDP_PRANSWER for unidirectional media purpose.

(And, as was mentioned, there may actually be a need to also transmit media for the FEDEX case)

>> Q2: The draft doesn't really specify what SDP_PRANSWER is used for. I understand that it means that a "final" answer
>> may be provided later, but it doesn't really say what the a browser would do with an SDP_PRANSWER - especially since 
>> it doesn't seem to enable media.
>	
>
> SDP_PRANSWER allows, among other things, the callee's ICE and SRTP info to be provided so that early media can 
> be received by the caller. I think it should make more sense given my answer to #1.

As I replied to #1, I don't think we need SDP_PRANSWER to establish unidirectional media, so I would like to know what those "other things" are :)

> SDP_PRANSWER has slightly different semantics in that it is not intended to indicate consent by the callee, whereas SDP_ANSWER does. 

What does the browser do with that information?

My understanding was that the browser is going to use media plane mechanisms (e.g. ICE) for callee consent.

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Fri, 17 Feb 2012 09:49:34 -0500

On Fri, Feb 17, 2012 at 3:33 AM, Christer Holmberg <
[email-masked]> wrote:

> >>      Q1: Since SDP_PRANSWER is not supposed to start media
> transmission, how will the use-case work? As far as I know, media
> transmission is needed for the FEDEX use-case.
> >
> >
> transmission", I mean that when the browser gets a SDP_PRANSWER
> > in response to an offer, the browser will not start transmitting media.
> However, it will play out any media that is received
> Again, you could achieve that using SDP_ANSWER and a direction attribute
> (a=recvonly). I don't think we need SDP_PRANSWER for unidirectional media
> purpose.
>
> understand that it means that a "final" answer
> >> may be provided later, but it doesn't really say what the a browser
> would do with an SDP_PRANSWER - especially since
> As I replied to #1, I don't think we need SDP_PRANSWER to establish
> unidirectional media, so I would like to know what those "other things" are
> :)
>
>
> > SDP_PRANSWER has slightly different semantics in that it is not intended
> to indicate consent by the callee, whereas SDP_ANSWER does.
>
> My understanding was that the browser is going to use media plane
> mechanisms (e.g. ICE) for callee consent.
>

When I say "consent" here, I mean the user has given permission to start
transmitting their media (i.e., "answered the call"). This is distinct from
the ICE-level "sending media to the right place" mechanisms.

Anyway, I went and looked at sendonly/recvonly/inactive handling and I
think I understand what you are suggesting. Let me see if I can distill
this into some rules:
- createOffer/Answer generates a=sendrecv offers/answers by default.
- Installing an a=sendonly/sendrecv description as an answer (via
setLocalDescription or setRemoteDescription) causes the browser to start
sending media from attached streams.
- Installing an a=recvonly/sendrecv description as an answer (via
setLocalDescription or setRemoteDescription) causes the browser to start
playing out received media.
- Multiple answers can be received; the most recent answer is the one that
is used.

Which allow for these scenarios:
- If an application wants to send an early response, but not start
sending/receving media (i.e. it is simply for faster call setup), it can
create, apply, and send an a=inactive answer.
- When that application sends its final response, indicating it wants to
send/receive media, it can apply/send an a=sendrecv answer.
- In the 1-800-FEDEX case, the answer received from 1-800-FEDEX may be a
"early response", but from the perspective of JSEP, it is a typical answer
with a=sendrecv.

Does this sound right to you? If so, I agree we can probably do away with
PRANSWER, unless others see something that we're overlooking.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 17 Feb 2012 08:24:44 -0800

Justin said:

"When I say "consent" here, I mean the user has given permission to start transmitting their media (i.e., "answered the call"). This is distinct from the ICE-level "sending media to the right place" mechanisms. 

Anyway, I went and looked at sendonly/recvonly/inactive handling and I think I understand what you are suggesting. Let me see if I can distill this into some rules:- createOffer/Answer generates a=sendrecv offers/answers by default.

- Installing an a=sendonly/sendrecv description as an answer (via setLocalDescription or setRemoteDescription) causes the browser to start sending media from attached streams.- Installing an a=recvonly/sendrecv description as an answer (via setLocalDescription or setRemoteDescription) causes the browser to start playing out received media.

- Multiple answers can be received; the most recent answer is the one that is used.
Which allow for these scenarios:- If an application wants to send an early response, but not start sending/receving media (i.e. it is simply for faster call setup), it can create, apply, and send an a=inactive answer.

- When that application sends its final response, indicating it wants to send/receive media, it can apply/send an a=sendrecv answer.- In the 1-800-FEDEX case, the answer received from 1-800-FEDEX may be a "early response", but from the perspective of JSEP, it is a typical answer with a=sendrecv.

Does this sound right to you? If so, I agree we can probably do away with PRANSWER, unless others see something that we're overlooking."

[BA] Yes, this does sound right to me.  With send/receive handling we should be covered for the Fedex case without a need for PRANSWER.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 17 Feb 2012 13:59:15 -0700

> [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 ca…

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.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Feb 2012 23:43:56 +0100

Hi,

> I think I tired to cover this in some of my slides before. You end up with this problem if you map the 180 to a final answer, then when the 200 comes along, it is 
> less clear what to do with it. If you map it to offer, then it's unclear how to handle the answer that comes in response to it.

You would not map it to an offer - you would replace the previous answer.

> I think I had some slides that showed this at one point. Basically, I don't see how using using an answer will work. The issue is not if you are sending or 
> receiving one way media, the issue is when you can free resources allocated in the offer but not needed in the answer.

That is a good point.

Regards,

Christer

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Sun, 19 Feb 2012 17:53:07 +0000

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

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Cullen Jennings
>Sent: Saturday, February 18, 2012 2:29 AM
>To: Hutton, Andrew
>Cc: [email-masked]; [email-masked]
>> [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.
>
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sun, 19 Feb 2012 22:25:51 +0100

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

> From: Ravindran, Parthasarathi [mailto:[email-masked]]
> Sent: 19 February 2012 17:53
> To: Cullen Jennings; Hutton, Andrew
> 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
> 
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Feb 2012 07:42:17 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: 19. helmikuuta 2012 23:26
To: Ravindran, Parthasarathi; Cullen Jennings
Cc: [email-masked]; [email-masked]
Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case

Hi,

Regards
Andy

> >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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 20 Feb 2012 06:59:00 +0000

Hi Christer,

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.

Also, I have the problem in the understanding the strong need for differentiating answer and final answer. Could you please clarify it.

Thanks
Partha 

>From: Christer Holmberg [mailto:[email-masked]]
>Sent: Monday, February 20, 2012 12:12 PM
>To: Hutton, Andrew; Ravindran, Parthasarathi; Cullen Jennings
>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
>
>
>
>Of Hutton, Andrew
>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
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Feb 2012 08:20:37 +0100

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

>PRANSWER or ANSWER, I think we shall use the SDP direction attribute 
>(or some other explicit elements) to indicate media direction.
>
>Regards,
>
>Christer
>
>
>
>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 
>> >>> 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
>> >first prompt as ringtone but cuts over before two way media (IE 
>> >DTMF)
>> is

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Feb 2012 09:54:43 +0100

> In that case, I guess the JS app could simply take a previous SDP_PRANSWER, and send it as SDP_ANSWER.

Right, and that is just custom JavaScript stuff just depending on the
chosen on-the-wire signaing mechanism. WebRTC should not be aware
about SIP semantics. If someone implements SIP or something "like SIP"
in JavaScript and wants to deal with an empty 200 OK after a 180/183
with SDP, then he should handle it in his custom JavaScript code.
WebRTC is out of that scope.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 20 Feb 2012 09:55:07 +0000

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

>Sent: Monday, February 20, 2012 12:51 PM
>To: Ravindran, Parthasarathi; Hutton, Andrew; Cullen Jennings
>> 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.
>
>> Also, I have the problem in the understanding the strong need for
>differentiating answer and final answer. Could you please clarify it.
>
>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.
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Feb 2012 11:08:37 +0100

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:[email-masked]] 
Sent: 20. helmikuuta 2012 11:55
To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
Cc: [email-masked]; [email-masked]
Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case

Hi Christer,

Thanks
Partha

>>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
>>
>>
>>> >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.
>>> >
>>> >

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 20 Feb 2012 10:41:01 +0000

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

>Sent: Monday, February 20, 2012 3:39 PM
>Mobile devices (smartphones etc) will often have limited resources, no
>matter whether the app is running as a browser app or a native app.
>
>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
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Feb 2012 12:15:54 +0100

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:[email-masked]] 
Sent: 20. helmikuuta 2012 12:41
To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
Cc: [email-masked]; [email-masked]
Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case

Hi Christer,

Thanks
Partha

>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.
>
>indicate the complication building up in the JavaScript offer/answer 
>FSM because of the (provisional/final) response specific offer/answer model.
>
>Thanks
>Partha
>
>>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.
>>
>>>> >media until the final response in the early media case. And the 
>>>> >IVR sends
>>>> the

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 20 Feb 2012 11:52:58 +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

>Sent: Monday, February 20, 2012 4:46 PM
>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
>
>
>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
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Feb 2012 13:59:59 +0100

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:[email-masked]] 
Sent: 20. helmikuuta 2012 13:53
To: Christer Holmberg; Hutton, Andrew; Cullen Jennings
Cc: [email-masked]; [email-masked]
Subject: RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case

Hi Christer,

Thanks
Partha

>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
>
>>Also, codec was only one example. A better example is perhaps 
>>resources related to ICE, media security etc.
>>
>>Regards,
>>
>>Christer
>>
>>
>>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.
>>
>>>> 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
>>>receive one. IMO, Multiple answer issue is not fully solved in ROAP 
>>>as well.
>>>
>>>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).
>>>Now, as this is the last answer, the browser can release the 
>>>resources for Y.
>>>
>>>>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 
>>>>> scenario. Andy will be able to double confirm whether he also 
>>>>> comes across the similar deployment.
>>>>>
>>>>> Thanks
>>>>> Partha
>>>>>
>>>>>
>>>>>
>>>>> >that the user can navigate through voice prompts (E.g. via DTMF) 
>>>>> >I thought this was the main requirement from the FEDEX use case.
>>>>> >

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 20 Feb 2012 13:59:53 +0000

Hi Christer,

I agree for timers as it is inline with Proxy Timer C in SIP (RFC 3261). In terms of SIP, Proxy Timer C helps to terminate INVITE request towards UAS that never generates a final response.  WebRTC client (browser) shall perform the similar functionality as there is no defined signaling entity.

Thanks
Partha 

>Sent: Monday, February 20, 2012 6:30 PM
>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
>
>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
>

---

From: Justin Uberti <[email-masked]>
Date: Mon, 20 Feb 2012 10:12:08 -0500

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 <
[email-masked]> wrote:

> some point shall be able to determine that there will be no more answers to
> a given offer :)
>
> Regards,
>
> Christer
>
> 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
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 20 Feb 2012 15:37:47 -0500

Actually codecs are a fairly bad example, since end point should be ready
to receive media  encoded using any codec present in the offer. The fact
that one of the codecs was not present in the answer does not mean that
remote party is not planning to send media using this codec. In any case,
there is no real overhead due to codec instance since new instance can be
created when a first RTP packet with particular payload is received (and
closed when RTP packets with a particular payload have not been received
for some period of time).

The only resource that I know that makes sense to conserve are TURN
allocated remote ports. I would be curious to know if there is anything
else.
_____________
Roman Shpount

On Mon, Feb 20, 2012 at 5:08 AM, Christer Holmberg <
[email-masked]> wrote:

> 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.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Feb 2012 21:43:25 +0100

2012/2/20 Roman Shpount <[email-masked]>:
> Actually codecs are a fairly bad example, since end point should be ready to
> receive media  encoded using any codec present in the offer. The fact that
> one of the codecs was not present in the answer does not mean that remote
> party is not planning to send media using this codec.

Exactly. At least SDP offer/answer mechanism allows asymmetric codecs
usage in the same media session, which means different codec in each
direction of the media stream.

-- 
Iñaki Baz Castillo
<[email-masked]>