Subject: [rtcweb] New JSEP draft posted

From: Justin Uberti <[email-masked]>
Date: Wed, 8 Feb 2012 15:57:21 -0500

Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt

Includes changes based on implementation feedback, and I believe it
addresses most of the concerns raised in last week's interim meetings:
- Initial documentation provided for each API call, and what state changes
it causes
- More examples, including a complete basic sample application
- Simplified approach to trickle candidate handling
- Resolved concerns about how to separate SDP attributes into media /
transport
- Provided encapsulation for SDP blobs and ICE candidate lines, in the
event we want to change encodings or provide helper functions for JS
- Provided mechanism for limiting candidates to TURN-only
- Resolved several implementation issues

I have not yet addressed the non-overlapping codec concern mentioned in the
interim meeting. I think there are ways of handling this either in the
application or the implementation, but I wanted to get this -01 out first
for feedback.

---

From: "Jim Barnett" <[email-masked]>
Date: Thu, 9 Feb 2012 07:26:54 -0800

Justin,

What happens if the application JavaScript modifies the offer?  Take the offer generation in example 7.1:

1.  OffererJS->OffererUA:   pc = new PeerConnection();

2.  OffererJS->OffererUA:   pc.addStream(localStream, null);

3.  OffererJS->OffererUA:   pc.startIce();

4.  OffererUA->OffererJS:   iceCallback(candidate, false);

5.  OffererJS->OffererUA:   offer = pc.createOffer(null);

6.  OffererJS->OffererUA:   pc.setLocalDescription(SDP_OFFER, offer.toSdp());

7.  OffererJS->AnswererJS:  {"type":"OFFER", "sdp":"<offer>"}

Could the JS modify the offer between steps 5 and 6 or between steps 6 and 7?  For example, between steps 5 and 6, could the JS add a stream for which pc.addStream had not been called previously?  Would setLocalDescription make the necessary modifications in that case?    What about changes after setLocalDescription has been called?  Are they not allowed?  If they are allowed, how does the peer connection know what to expect from the other side?  

-          Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Wednesday, February 08, 2012 3:57 PM
To: [email-masked]; [email-masked]
Subject: [rtcweb] New JSEP draft posted

Includes changes based on implementation feedback, and I believe it addresses most of the concerns raised in last week's interim meetings:

- Initial documentation provided for each API call, and what state changes it causes

- Resolved concerns about how to separate SDP attributes into media / transport

- Provided encapsulation for SDP blobs and ICE candidate lines, in the event we want to change encodings or provide helper functions for JS

I have not yet addressed the non-overlapping codec concern mentioned in the interim meeting. I think there are ways of handling this either in the application or the implementation, but I wanted to get this -01 out first for feedback.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 9 Feb 2012 14:38:52 -0500

On Thu, Feb 9, 2012 at 10:26 AM, Jim Barnett <[email-masked]>wrote:

> Justin,****
>
> What happens if the application JavaScript modifies the offer?  Take the
> offer generation in example 7.1:****
>
> **1.  **OffererJS->OffererUA:   pc = new PeerConnection();****
>
> **2.  **OffererJS->OffererUA:   pc.addStream(localStream, null);****
>
> **3.  **OffererJS->OffererUA:   pc.startIce();****
>
> **4.  **OffererUA->OffererJS:   iceCallback(candidate, false);****
>
> **5.  **OffererJS->OffererUA:   offer = pc.createOffer(null);****
>
> **6.  **OffererJS->OffererUA:   pc.setLocalDescription(SDP_OFFER,
> offer.toSdp());****
>
> **7.  **OffererJS->AnswererJS:  {"type":"OFFER", "sdp":"<offer>"}****
>
> ** **
>
> Could the JS modify the offer between steps 5 and 6 or between steps 6 and
> 7?
>

Yes for 5/6, but "not recommended" for 6/7. Otherwise, the UA will be out
of sync with what was signaled to the remote side.

>   For example, between steps 5 and 6, could the JS add a stream for which
> pc.addStream had not been called previously?  Would setLocalDescription
> make the necessary modifications in that case?
>

Since streams need to be coupled to actual media sources, this wouldn't
work. (Or if it did, the remote side would just get a stream that never had
any media).

>     What about changes after setLocalDescription has been called?  Are
> they not allowed?  If they are allowed, how does the peer connection know
> what to expect from the other side?
>

You would need to call setLocalDescription again with the modified
description in order to ensure the UA is in sync with what the other side
will send.

>  ****
>
> ** **
>
> **-          **Jim****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Justin Uberti
> *Sent:* Wednesday, February 08, 2012 3:57 PM
> *To:* [email-masked]; [email-masked]
> *Subject:* [rtcweb] New JSEP draft posted****
>
> ** **
>
> Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt***
> *
>
> ** **
>
> addresses most of the concerns raised in last week's interim meetings:****
>
> it causes****
> - More examples, including a complete basic sample application****
>
> - Simplified approach to trickle candidate handling****
>
> transport****
> event we want to change encodings or provide helper functions for JS****
>
> - Provided mechanism for limiting candidates to TURN-only****
>
> - Resolved several implementation issues****
>
> ** **
>
> I have not yet addressed the non-overlapping codec concern mentioned in
> the interim meeting. I think there are ways of handling this either in the
> for feedback.****

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 09 Feb 2012 12:29:13 -0800

On 02/09/2012 07:26 AM, Jim Barnett wrote:
> 2.OffererJS->OffererUA:   pc.addStream(localStream, null);
>
> 3.OffererJS->OffererUA:   pc.startIce();
>
> 4.OffererUA->OffererJS:   iceCallback(candidate, false);
>
> 5.OffererJS->OffererUA:   offer = pc.createOffer(null);
>
> 6.OffererJS->OffererUA:   pc.setLocalDescription(SDP_OFFER, 
> offer.toSdp());
>
> 7.OffererJS->AnswererJS:  {"type":"OFFER", "sdp":"<offer>"}
>
> Could the JS modify the offer between steps 5 and 6 or between steps 6 
> and 7?  For example, between steps 5 and 6, could the JS add a stream 
> for which pc.addStream had not been called previously?
>
The JS would not know what to enter for an added stream, I think. Most 
probably an attempt to do this should result in the SetLocalDescription 
being invalid, and thus rejected.

Removing codecs, for instance, would be expected to cause no 
difficulties, and cause the right thing to happen (local UA being 
configured not to expect incoming data in that format). I think.
>
>   Would setLocalDescription make the necessary modifications in that 
> case?    What about changes after setLocalDescription has been 
> called?  Are they not allowed?  If they are allowed, how does the peer 
> connection know what to expect from the other side?
>
Seems to me that pc.setLocalDescription would have to be called again, 
otherwise the local PC doesn't know about the change.
>
> -Jim
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Justin Uberti
> *Subject:* [rtcweb] New JSEP draft posted
>
> I have not yet addressed the non-overlapping codec concern mentioned 
> in the interim meeting. I think there are ways of handling this either 
> in the application or the implementation, but I wanted to get this -01 
> out first for feedback.
>

---

From: "Jim Barnett" <[email-masked]>
Date: Thu, 9 Feb 2012 13:47:57 -0800

So we will need to specify which aspects of an offer can be modified before setLocalDescription is called (or, equivalently, specify the conditions under which setLocalDescription must fail).    For compatibility reasons we wouldn’t want to allow the individual browser vendors decide which modifications to accept.  Could we define an API on offer that would allow only the legal changes to be made, or would that be impractical?  If changes to the offer went through the API, it might be possible to track if changes had been made since the last call to setLocalDescription, and at least issue a warning if the application tried to send an offer that was out of synch with the local description.  

I suppose it’s a matter of taste how much we try to keep app developers from shooting themselves in the foot,  but it seems to me that it’s dangerous to tell them that they can edit the offer object or the resulting SDP when there are so many ways for that to fail.

-          Jim

From: Harald Alvestrand [mailto:[email-masked]] 
Sent: Thursday, February 09, 2012 3:29 PM
To: Jim Barnett
Cc: Justin Uberti; [email-masked]; [email-masked]
Subject: Re: [rtcweb] New JSEP draft posted

Justin,

OffererJS->OffererUA:   pc = new PeerConnection();

OffererJS->OffererUA:   pc.addStream(localStream, null);

OffererJS->OffererUA:   pc.startIce();

OffererUA->OffererJS:   iceCallback(candidate, false);

OffererJS->OffererUA:   offer = pc.createOffer(null);

OffererJS->OffererUA:   pc.setLocalDescription(SDP_OFFER, offer.toSdp());

OffererJS->AnswererJS:  {"type":"OFFER", "sdp":"<offer>"}

Could the JS modify the offer between steps 5 and 6 or between steps 6 and 7?  For example, between steps 5 and 6, could the JS add a stream for which pc.addStream had not been called previously?

The JS would not know what to enter for an added stream, I think. Most probably an attempt to do this should result in the SetLocalDescription being invalid, and thus rejected.

Removing codecs, for instance, would be expected to cause no difficulties, and cause the right thing to happen (local UA being configured not to expect incoming data in that format). I think.

  Would setLocalDescription make the necessary modifications in that case?    What about changes after setLocalDescription has been called?  Are they not allowed?  If they are allowed, how does the peer connection know what to expect from the other side?  

Seems to me that pc.setLocalDescription would have to be called again, otherwise the local PC doesn't know about the change.

Jim

---

From: Justin Uberti <[email-masked]>
Date: Thu, 9 Feb 2012 16:52:06 -0500

I agree we should provide guidance here on what can be changed, and fail
any edits that are disallowed. We can do this while nailing down exactly
what parts of SDP all implementations must support.

On Thu, Feb 9, 2012 at 4:47 PM, Jim Barnett <[email-masked]>wrote:

> So we will need to specify which aspects of an offer can be modified
> before setLocalDescription is called (or, equivalently, specify the
> conditions under which setLocalDescription must fail).    For compatibility
> reasons we wouldn’t want to allow the individual browser vendors decide
> which modifications to accept.  Could we define an API on offer that would
> allow only the legal changes to be made, or would that be impractical?  If
> changes to the offer went through the API, it might be possible to track if
> changes had been made since the last call to setLocalDescription, and at
> least issue a warning if the application tried to send an offer that was
> out of synch with the local description.  ****
>
> ** **
>
> I suppose it’s a matter of taste how much we try to keep app developers
> from shooting themselves in the foot,  but it seems to me that it’s
> dangerous to tell them that they can edit the offer object or the resulting
> SDP when there are so many ways for that to fail.****
>
> ** **
>
> **-          **Jim****
>
> ** **
>
> *From:* Harald Alvestrand [mailto:[email-masked]]
> *Sent:* Thursday, February 09, 2012 3:29 PM
> *To:* Jim Barnett
> *Cc:* Justin Uberti; [email-masked]; [email-masked]
> *Subject:* Re: [rtcweb] New JSEP draft posted****
>
> ** **
>
> On 02/09/2012 07:26 AM, Jim Barnett wrote: ****
>
> Justin,****
>
> OffererJS->OffererUA:   pc = new PeerConnection();****
>
> OffererJS->OffererUA:   pc.addStream(localStream, null);****
>
> OffererJS->OffererUA:   pc.startIce();****
>
> OffererUA->OffererJS:   iceCallback(candidate, false);****
>
> OffererJS->OffererUA:   offer = pc.createOffer(null);****
>
> OffererJS->OffererUA:   pc.setLocalDescription(SDP_OFFER, offer.toSdp());*
> ***
>
> OffererJS->AnswererJS:  {"type":"OFFER", "sdp":"<offer>"}****
>
>  ****
>
> 7?  For example, between steps 5 and 6, could the JS add a stream for which
> pc.addStream had not been called previously?****
>
> Removing codecs, for instance, would be expected to cause no difficulties,
> and cause the right thing to happen (local UA being configured not to
> expect incoming data in that format). I think.
>
> ****
>
> case?    What about changes after setLocalDescription has been called?  Are
> what to expect from the other side?  ****
>
> Jim****
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Justin Uberti

---

From: Justin Uberti <[email-masked]>
Date: Fri, 10 Feb 2012 09:03:05 -0500

On Fri, Feb 10, 2012 at 6:07 AM, Adam Bergkvist <[email-masked]
> wrote:

> On 02/08/2012 09:57 PM, Justin Uberti wrote:
>
>> Now available at http://www.ietf.org/id/draft-**uberti-rtcweb-jsep-01.txt<http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt>
>>
>> the interim meeting. I think there are ways of handling this either in
>> the application or the implementation, but I wanted to get this -01 out
>> first for feedback.
>>
>
> Good to see a concrete JS example. Some comments below.
>
> I believe the example has a deadlock on the caller side:
> * hasCandidates (initially false) is set true by the ice callback
> * the ice callback can never trigger before startIce() is called
> * maybeSignal(), which calls startIce(), will return early if
> hasCandidates is false
>

You're right. startIce() should be called in start(), if |isCaller| is
true.

>
> Another thing, how are the candidates from the ice callback included in
> the offer? The candidate argument from the ice callback is never used.

As mentioned in the draft, candidates are included in the offer
automatically (if they have already been gathered). In the example, we just
wait for the IceCallback to inform us that gathering is complete, and use
that to know when to dispatch the offer.

> /Adam

---

From: Justin Uberti <[email-masked]>
Date: Fri, 10 Feb 2012 11:02:51 -0500

Updated sample below. Changes (move of startIce) are in *bold*.

      var signalingChannel = createSignalingChannel();
   var pc = null;
   var hasCandidates = false;

   function start(isCaller) {
     // create a PeerConnection and hook up the IceCallback
     pc = new webkitPeerConnection(
            "", function (candidate, moreToFollow) {
       if (!moreToFollow) {
         hasCandidates = true;
         maybeSignal(isCaller);
       }
     });

     // get the local stream and show it in the local video element
     navigator.webkitGetUserMedia(
           {"audio": true, "video": true}, function (localStream) {
       selfView.src = webkitURL.createObjectURL(localStream);
       pc.addStream(localStream);
       maybeSignal(isCaller);
     }

     // once remote stream arrives, show it in the remote video element
     pc.onaddstream = function(evt) {
       remoteView.src = webkitURL.createObjectURL(evt.stream);
     };

    * // if we're the caller, create and install our offer,*
*     // and start candidate generation*
*     if (isCaller) {*
*       offer = pc.createOffer(null);*
*       pc.setLocalDescription(SDP_OFFER, offer);*
*       pc.startIce();*
*     }*
   }

   function maybeSignal(isCaller) {
     // only signal once we have a local stream and local candidates
     if (localStreams.size() == 0 || !hasCandidates) return;
     if (isCaller) {
   *    offer = pc.localDescription;*
       signalingChannel.send(
           JSON.stringify({ "type": "offer", "sdp": offer }));
     } else {
       // if we're the callee, generate, apply, and send the answer
       answer = pc.createAnswer(pc.remoteDescription, null);
       pc.setLocalDescription(SDP_ANSWER, answer);
       signalingChannel.send(
           JSON.stringify({ "type": "answer", "sdp": answer }));
     }
   }

   signalingChannel.onmessage = function(evt) {
     var msg = JSON.parse(evt.data);
     if (msg.type == "offer") {
       // create the PeerConnection
       start(false);
       // feed the received offer into the PeerConnection and
       // start candidate generation
       pc.setRemoteDescription(PeerConnection.SDP_OFFER, msg.sdp);
       pc.startIce();
     } else if (msg.type == "answer") {
       // feed the answer into the PeerConnection to complete setup
       pc.setRemoteDescription(PeerConnection.SDP_ANSWER, msg.sdp);
     }

On Fri, Feb 10, 2012 at 9:03 AM, Justin Uberti <[email-masked]> wrote:

>
>
> On Fri, Feb 10, 2012 at 6:07 AM, Adam Bergkvist <
> [email-masked]> wrote:
>
>>> Now available at http://www.ietf.org/id/draft-**
>>> uberti-rtcweb-jsep-01.txt<http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt>
>>>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Feb 2012 08:18:52 -0700

I think a good way to indicate what could be changed in the SDP would be a table where for each part of SDP, we listed being something that can be changed, or can not be changed, or unknown and it might work on some browsers and not on others. This allows the browser vendors to have a set of stuff they clearly know will not be changed, and the JS implementers to have a list of changes they know will work. 

I'll start a separate thread asking what needs to be changeable.

On Feb 9, 2012, at 2:52 PM, Justin Uberti wrote:

> I agree we should provide guidance here on what can be changed, and fail any edits that are disallowed. We can do this while nailing down exactly what parts of SDP all implementations must support.
> 
> On Thu, Feb 9, 2012 at 4:47 PM, Jim Barnett <[email-masked]> wrote:

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 13 Feb 2012 18:36:28 +0000

Hi Justin,

In the draft, it is not spelled out explicitly what is the expected behavior in offerer browser in case multiple answer is received for single offer. Offer/answer exchange in offerer is as follows:

OffererJS->OffererUA: var offer = pc.createOffer(null);
OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer);

OffererJS->OffererUA:  pc.setRemoteDescription(SDP_ANSWER, answer1);

OffererUA->Answerer1UA: <media>

OffererJS->OffererUA:  pc.setRemoteDescription(SDP_ANSWER, answer2);

OffererUA->Answerer?UA: <media>?

My understanding is that “answer2” will update “answer1” in browser and starting sending/receiving media towards answer2 media IP and port. Could you please explain the expected behavior in offerer browser whether it updates the media stream based on the last answer or mixes both answerer.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Thursday, February 09, 2012 2:27 AM
To: [email-masked]; [email-masked]
Subject: [rtcweb] New JSEP draft posted

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 14 Feb 2012 06:24:49 +0000

Hi Justin,

Adding to my earlier mail, In case answer2 SDP is updated in offerer1 browser without notifying answerer1, then answer1 will continue to transmit RTP which may not be desired behavior. IMO, we need to define this behavior clearly in offerer side. Some of the possible solutions are

1)      offerer1 has to send atleast RTCP BYE packets towards answerer1 while accepting the answerer2 SDP.

2)      Throw callback to clear answer1 SDP towards offererJS.

Please let me know your opinion here.

Thanks
Partha

From: Ravindran, Parthasarathi
Sent: Tuesday, February 14, 2012 12:07 AM
To: 'Justin Uberti'; [email-masked]; [email-masked]
Subject: Single offer with multiple answer handling in JSEP [was RE: [rtcweb] New JSEP draft posted]

Hi Justin,

Thanks
Partha

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Thursday, February 09, 2012 2:27 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] New JSEP draft posted

---

From: Justin Uberti <[email-masked]>
Date: Tue, 14 Feb 2012 08:59:01 -0500

Regarding your previous mail, an ANSWER after an ANSWER would either fail
(if we wanted to simplify), or replace the previous ANSWER (essentially the
same as if you had done setLocalDescription(OFFER, localDescription)
followed by setRemoteDescription(ANSWER, answer2).

In no case would it mix the descriptions/media from both answers.

Other comments inline below.

On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi <
[email-masked]> wrote:

>  Hi Justin,****
>
> ** **
>
> Adding to my earlier mail, In case answer2 SDP is updated in offerer1
> browser without notifying answerer1, then answer1 will continue to transmit
> RTP which may not be desired behavior. IMO, we need to define this behavior
> clearly in offerer side. Some of the possible solutions are****
>
>
>
**
>
> **1)      **offerer1 has to send atleast RTCP BYE packets towards
> answerer1 while accepting the answerer2 SDP.  ****
>
> **2)      **Throw callback to clear answer1 SDP towards offererJS.
>

The application which called setRemoteDescription twice should have the
best idea about what is going on, and therefore is responsible for
notifying answerer1 that its answer has been discarded, if it makes sense
to do so. No callback should be needed here.

>
> ****
>
> Please let me know your opinion here.****
>
> ** **
>
> Thanks****
>
> Partha ****
>
> ** **
>
> *From:* Ravindran, Parthasarathi
> *Sent:* Tuesday, February 14, 2012 12:07 AM
> *To:* 'Justin Uberti'; [email-masked]; [email-masked]
> *Subject:* Single offer with multiple answer handling in JSEP [was RE:
> [rtcweb] New JSEP draft posted]****
>
> ** **
>
> Hi Justin,****
>
> ** **
>
> In the draft, it is not spelled out explicitly what is the expected
> behavior in offerer browser in case multiple answer is received for single
> offer. Offer/answer exchange in offerer is as follows:****
>
> ** **
>
> OffererJS->OffererUA: var offer = pc.createOffer(null);****
>
> OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer);****
>
> OffererJS->OffererUA:  pc.setRemoteDescription(SDP_ANSWER, answer1);****
>
> OffererUA->Answerer1UA: <media>****
>
> OffererJS->OffererUA:  pc.setRemoteDescription(SDP_ANSWER, answer2);****
>
> OffererUA->Answerer?UA: <media>?****
>
> ** **
>
> My understanding is that “answer2” will update “answer1” in browser and
> starting sending/receiving media towards answer2 media IP and port. Could
> you please explain the expected behavior in offerer browser whether it
> updates the media stream based on the last answer or mixes both answerer.*
> ***
>
> ** **
>
> Thanks****
>
> Partha****
>
> ** **
>
> *Sent:* Thursday, February 09, 2012 2:27 AM

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 14 Feb 2012 14:39:44 +0000

Hi Justin,

It will be good to mention in the JSEP draft  that multiple answers for single offer will not lead to RTP Mixing and WebRTC client acts as RTP Endpoint.

Failing the second Answer will be limiting the provision in RFC 3264 offer/answer itself as RFC 3264 supports single offer with multiple answer. Also, it is better to define the behavior in API rather than putting this scenario in the browser implementation specific. In simple scenarios (like alerting with one answer, connect with second answer), replacing the previous ANSWER will be expected behavior. This may not be desired behavior in case two connect responses from different WebRTC clients received with different answers  but there is no other alternative solution possible without mixing.

IMO, it is better to define it explicitly in JSEP that “latest ANSWER to the offer will replace the existing answer is the expected behavior ”. Also, Please mentioned that JS application is responsible for discarding (terminating) previous ANSWER notification.   Please let me your opinion on this closure.

Thanks
Partha

From: Justin Uberti [mailto:[email-masked]]
Sent: Tuesday, February 14, 2012 7:29 PM
To: Ravindran, Parthasarathi
Cc: [email-masked]; [email-masked]
Subject: Re: Single offer with multiple answer handling in JSEP [was RE: [rtcweb] New JSEP draft posted]

Regarding your previous mail, an ANSWER after an ANSWER would either fail (if we wanted to simplify), or replace the previous ANSWER (essentially the same as if you had done setLocalDescription(OFFER, localDescription) followed by setRemoteDescription(ANSWER, answer2).

Other comments inline below.
On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Justin,

The application which called setRemoteDescription twice should have the best idea about what is going on, and therefore is responsible for notifying answerer1 that its answer has been discarded, if it makes sense to do so. No callback should be needed here.

Thanks
Partha

From: Ravindran, Parthasarathi
Sent: Tuesday, February 14, 2012 12:07 AM
To: 'Justin Uberti'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Single offer with multiple answer handling in JSEP [was RE: [rtcweb] New JSEP draft posted]

Hi Justin,

Thanks
Partha

---

From: Justin Uberti <[email-masked]>
Date: Tue, 14 Feb 2012 08:17:14 -0800

On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi <
[email-masked]> wrote:

>  Hi Justin,****
>
> ** **
>
> It will be good to mention in the JSEP draft  that multiple answers for
> single offer will not lead to RTP Mixing and WebRTC client acts as RTP
> Endpoint. ****
>
> ** **
>
> Failing the second Answer will be limiting the provision in RFC 3264
> offer/answer itself as RFC 3264 supports single offer with multiple answer.
> Also, it is better to define the behavior in API rather than putting this
> scenario in the browser implementation specific. In simple scenarios (like
> alerting with one answer, connect with second answer), replacing the
> previous ANSWER will be expected behavior. This may not be desired behavior
> in case two connect responses from different WebRTC clients received with
> different answers  but there is no other alternative solution possible
> without mixing.
>

Do you need to support 2 final answers, or would the provisional answer
support provided via SDP_PRANSWER work for you?

> ****
>
> ** **
>
> IMO, it is better to define it explicitly in JSEP that “latest ANSWER to
> the offer will replace the existing answer is the expected behavior ”.
> Also, Please mentioned that JS application is responsible for discarding
> (terminating) previous ANSWER notification.   Please let me your opinion on
> this closure.****
>
> ** **
>
> Thanks****
>
> Partha****
>
> ** **
>
> *From:* Justin Uberti [mailto:[email-masked]]
> *Sent:* Tuesday, February 14, 2012 7:29 PM
> *To:* Ravindran, Parthasarathi
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: Single offer with multiple answer handling in JSEP [was
> RE: [rtcweb] New JSEP draft posted]****
>
> ** **
>
> followed by setRemoteDescription(ANSWER, answer2).****
>
> ** **
>
> In no case would it mix the descriptions/media from both answers.****
>
> ** **
>
> Other comments inline below.****
>
> [email-masked]> wrote:****
>
> Hi Justin,****
>
>  ****
>
>  1)      offerer1 has to send atleast RTCP BYE packets towards answerer1
> while accepting the answerer2 SDP.  ****
>
> 2)      Throw callback to clear answer1 SDP towards offererJS.****
>
>  ** **
>
> to do so. No callback should be needed here. ****
>
>  ** **
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 14 Feb 2012 17:17:12 +0000

Hi Justin,

In this mail thread, Let us define the behavior of multiple (atleast two) answers for the single offer in WebRTC browser.  Now, Please let me know your opinion for my below mail.

Thanks
Partha

Sent: Tuesday, February 14, 2012 9:47 PM

On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Justin,

Do you need to support 2 final answers, or would the provisional answer support provided via SDP_PRANSWER work for you?

Thanks
Partha

From: Justin Uberti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, February 14, 2012 7:29 PM
To: Ravindran, Parthasarathi
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Single offer with multiple answer handling in JSEP [was RE: [rtcweb] New JSEP draft posted]

Thanks
Partha

Hi Justin,

Thanks
Partha

---

From: Justin Uberti <[email-masked]>
Date: Tue, 14 Feb 2012 13:05:35 -0500

Partha,

I need more information about the use case to provide an accurate response.
As mentioned in my earlier mail, are both answers 2xx responses?

On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi <
[email-masked]> wrote:

>  Hi Justin,****
>
> ** **
>
> In this mail thread, Let us define the behavior of multiple (atleast two)
> answers for the single offer in WebRTC browser.  Now, Please let me know
> your opinion for my below mail.****
>
> ** **
>
> Thanks****
>
> Partha****
>
> ** **
>
> *Sent:* Tuesday, February 14, 2012 9:47 PM
>
> without mixing.****
> support provided via SDP_PRANSWER work for you?****
>
>   ****
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 14 Feb 2012 19:24:34 +0000

Justin,

Some of the usecases could be

1)      The same user of a website signed-in in the multiples devices and acts as answerer,  the session establishment request to the identity will alert all the signed-in devices and it is possible that multiple devices answer to the session. Here, user may move from one device (mobile) to another device (desktop) within the session and wishes to continue the session with the last answer. Please note that website is flexible to provide this service.

2)      RFC 3261 SIP UA offer/answer handling w.r.t INVITE with SDP to multiple 2xx with SDP handling scenario using JSEP

3)      Another SIP usecase could be multiple 18x responses with SDP for INVITE with SDP and multiple 2xx responses without SDP but order within 18x and 200 are not same. Say 2xx of the second 18x is received as the first 2xx. Here, we need to know how second 18x is handled and also, the subsequent 2xx is handled.

Of course, it is possible to build more usecases around this area. As we made signaling outside the scope of WebRTC, it is upto JS application to decide the order in which offer/answer happens. I’m not relating offer/answer FSM with session establishment state like 18x, 2xx but I’m interested in knowing browser media plane behavior in different state of offer/answer handling by which JS application behaves consistently in all browsers.

Thanks
Partha

Sent: Tuesday, February 14, 2012 11:36 PM

Partha,

I need more information about the use case to provide an accurate response. As mentioned in my earlier mail, are both answers 2xx responses?
On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Justin,

Thanks
Partha

Thanks
Partha

Thanks
Partha

Hi Justin,

Thanks
Partha

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 15 Feb 2012 00:01:05 -0800

I'm a bit lost on use case in SIP context - assuming that the UAC did not fork but that a proxy or B2BUA did the forking, it seems like the UAC should never receive more than one final response. 

In the case of moving from desktop to mobile, it seems like that is updating the stream and would use a call flow more like update examples in the draft instead of trying to reuse some old answer. 

On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote:

> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi <[email-masked]> wrote:
> Hi Justin,
>  
> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi <[email-masked]> wrote:
> Hi Justin,
>  
> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi <[email-masked]> wrote:
> Hi Justin,
>  
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 15 Feb 2012 09:13:31 +0000

Cullen,

RFC3261 references for receiving multiple 2xx in UAC which does not fork INVITE are as follows:

<RFC quote>
Sec 13.1 Para 3:

Therefore, when multiple 2xx responses are received from different remote UAs (because the INVITE forked), each 2xx establishes a different dialog.  All these dialogs are part of the same call.

Sec 13.2.2.4 2xx Responses

   Multiple 2xx responses may arrive at the UAC for a single INVITE
   request due to a forking proxy.  Each response is distinguished by
   the tag parameter in the To header field, and each represents a
   distinct dialog, with a distinct dialog identifier.

   If, after acknowledging any 2xx response to an INVITE, the UAC does
   not want to continue with that dialog, then the UAC MUST terminate
   the dialog by sending a BYE request as described in Section 15.
</RFC quote> 

As per the last statements, it is upto the SIP application to decide which one of the final 2xx response has to be included within the call. The usecase 3 is based on RFC3262 (PRACK) support wherein it is possible to receive multiple forked 18x with SDP followed by 2xx with or without SDP and SIP 2xx response is not tied to offer/answer exchange. 

I have provided mobile to desktop as an example to justify the last answer may be used in the offer in some JS application. As I mentioned below, there is no need to restrict updating latest answer for an offer in terms of API and protocol. 

Thanks
Partha

>-----Original Message-----
>From: Cullen Jennings [mailto:[email-masked]]
>Sent: Wednesday, February 15, 2012 1:31 PM
>Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP
>[was RE: New JSEP draft posted]
>
>
>I'm a bit lost on use case in SIP context - assuming that the UAC did
>not fork but that a proxy or B2BUA did the forking, it seems like the
>UAC should never receive more than one final response.
>
>In the case of moving from desktop to mobile, it seems like that is
>updating the stream and would use a call flow more like update examples
>in the draft instead of trying to reuse some old answer.
>
>
>> 1)      The same user of a website signed-in in the multiples devices
>and acts as answerer,  the session establishment request to the identity
>will alert all the signed-in devices and it is possible that multiple
>devices answer to the session. Here, user may move from one device
>(mobile) to another device (desktop) within the session and wishes to
>continue the session with the last answer. Please note that website is
>flexible to provide this service.
>> 2)      RFC 3261 SIP UA offer/answer handling w.r.t INVITE with SDP to
>multiple 2xx with SDP handling scenario using JSEP
>> 3)      Another SIP usecase could be multiple 18x responses with SDP
>for INVITE with SDP and multiple 2xx responses without SDP but order
>within 18x and 200 are not same. Say 2xx of the second 18x is received
>as the first 2xx. Here, we need to know how second 18x is handled and
>also, the subsequent 2xx is handled.
>>
>> Of course, it is possible to build more usecases around this area. As
>we made signaling outside the scope of WebRTC, it is upto JS application
>to decide the order in which offer/answer happens. I'm not relating
>offer/answer FSM with session establishment state like 18x, 2xx but I'm
>interested in knowing browser media plane behavior in different state of
>offer/answer handling by which JS application behaves consistently in
>all browsers.
>>
>> Thanks
>> Partha
>>
>>
>> I need more information about the use case to provide an accurate
>response. As mentioned in my earlier mail, are both answers 2xx
>responses?
>>
>> In this mail thread, Let us define the behavior of multiple (atleast
>two) answers for the single offer in WebRTC browser.  Now, Please let me
>know your opinion for my below mail.
>>
>> Thanks
>> Partha
>>
>> It will be good to mention in the JSEP draft  that multiple answers
>for single offer will not lead to RTP Mixing and WebRTC client acts as
>RTP Endpoint.
>>
>offer/answer itself as RFC 3264 supports single offer with multiple
>answer. Also, it is better to define the behavior in API rather than
>putting this scenario in the browser implementation specific. In simple
>scenarios (like alerting with one answer, connect with second answer),
>replacing the previous ANSWER will be expected behavior. This may not be
>desired behavior in case two connect responses from different WebRTC
>clients received with different answers  but there is no other
>alternative solution possible without mixing.
>>
>> Do you need to support 2 final answers, or would the provisional
>answer support provided via SDP_PRANSWER work for you?
>>
>> IMO, it is better to define it explicitly in JSEP that "latest ANSWER
>to the offer will replace the existing answer is the expected behavior
>". Also, Please mentioned that JS application is responsible for
>discarding (terminating) previous ANSWER notification.   Please let me
>your opinion on this closure.
>>
>> Thanks
>> Partha
>>
>> Regarding your previous mail, an ANSWER after an ANSWER would either
>fail (if we wanted to simplify), or replace the previous ANSWER
>(essentially the same as if you had done setLocalDescription(OFFER,
>localDescription) followed by setRemoteDescription(ANSWER, answer2).
>>
>browser without notifying answerer1, then answer1 will continue to
>transmit RTP which may not be desired behavior. IMO, we need to define
>this behavior clearly in offerer side. Some of the possible solutions
>are
>>
>> 1)      offerer1 has to send atleast RTCP BYE packets towards
>answerer1 while accepting the answerer2 SDP.
>>
>> The application which called setRemoteDescription twice should have
>the best idea about what is going on, and therefore is responsible for
>notifying answerer1 that its answer has been discarded, if it makes
>sense to do so. No callback should be needed here.
>>
>>
>behavior in offerer browser in case multiple answer is received for
>single offer. Offer/answer exchange in offerer is as follows:
>>
>> My understanding is that "answer2" will update "answer1" in browser
>and starting sending/receiving media towards answer2 media IP and port.
>Could you please explain the expected behavior in offerer browser
>whether it updates the media stream based on the last answer or mixes
>both answerer.
>>
>> Thanks
>> Partha
>>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 15 Feb 2012 23:09:59 -0800

Oh I see what you mean now - I was missing the different dialogs. Thanks

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 16 Feb 2012 07:11:05 +0000

Cullen/Justin,

Single offer with multiple answer open item is not addressed in -02 version of JSEP draft. Hope you first agree this as an open item in JSEP.

Thanks
Partha

>Sent: Wednesday, February 15, 2012 2:43 PM
>To: 'Cullen Jennings'
>Subject: RE: [rtcweb] Single offer with multiple answer handling in JSEP
>Therefore, when multiple 2xx responses are received from different
>remote UAs (because the INVITE forked), each 2xx establishes a different
>dialog.  All these dialogs are part of the same call.
>
>As per the last statements, it is upto the SIP application to decide
>which one of the final 2xx response has to be included within the call.
>The usecase 3 is based on RFC3262 (PRACK) support wherein it is possible
>to receive multiple forked 18x with SDP followed by 2xx with or without
>SDP and SIP 2xx response is not tied to offer/answer exchange.
>
>I have provided mobile to desktop as an example to justify the last
>answer may be used in the offer in some JS application. As I mentioned
>below, there is no need to restrict updating latest answer for an offer
>in terms of API and protocol.
>
>Thanks
>Partha
>
>>Subject: Re: [rtcweb] Single offer with multiple answer handling in
>>JSEP [was RE: New JSEP draft posted]
>>
>>
>>and acts as answerer,  the session establishment request to the
>>identity will alert all the signed-in devices and it is possible that
>>multiple devices answer to the session. Here, user may move from one
>>device
>>we made signaling outside the scope of WebRTC, it is upto JS
>>application to decide the order in which offer/answer happens. I'm not
>>relating offer/answer FSM with session establishment state like 18x,
>>2xx but I'm interested in knowing browser media plane behavior in
>>different state of offer/answer handling by which JS application
>>behaves consistently in all browsers.
>>>
>>> Thanks
>>> Partha
>>>
>>>
>>two) answers for the single offer in WebRTC browser.  Now, Please let
>>me know your opinion for my below mail.
>>>
>>> Thanks
>>> Partha
>>>
>>replacing the previous ANSWER will be expected behavior. This may not
>>be desired behavior in case two connect responses from different WebRTC

---

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

Agree it has not been addressed. I'm having some trouble understanding the
exact flows that we need to address here (multiple 2xx, multiple 18x
followed by 2xx, multiple 18x followed by multiple 2xx) but if I understand
correctly your suggestion was:

1) allow a setRemoteDesc(SDP_ANSWER) to follow a setRemoteDesc(SDP_ANSWER)
2) document that in this case (multiple 2xx), the JS is responsible for
sending BYE to the previous answerer.

which sounds totally reasonable to me.

If this sounds good to you, would you mind sketching out a call flow that I
could include in the examples section?

On Thu, Feb 16, 2012 at 2:11 AM, Ravindran, Parthasarathi <
[email-masked]> wrote:

> Cullen/Justin,
>
> Single offer with multiple answer open item is not addressed in -02
> version of JSEP draft. Hope you first agree this as an open item in JSEP.
>
> Thanks
> Partha
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 17 Feb 2012 13:24:20 +0000

Hi Justin,

This sounds good to me. I’ll send the example callflow ASAP.

Thanks
Partha

From: Justin Uberti [mailto:[email-masked]]
Sent: Friday, February 17, 2012 8:06 AM
To: Ravindran, Parthasarathi
Cc: Cullen Jennings; [email-masked]; [email-masked]
Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted]

Agree it has not been addressed. I'm having some trouble understanding the exact flows that we need to address here (multiple 2xx, multiple 18x followed by 2xx, multiple 18x followed by multiple 2xx) but if I understand correctly your suggestion was:

1) allow a setRemoteDesc(SDP_ANSWER) to follow a setRemoteDesc(SDP_ANSWER)
2) document that in this case (multiple 2xx), the JS is responsible for sending BYE to the previous answerer.

If this sounds good to you, would you mind sketching out a call flow that I could include in the examples section?

On Thu, Feb 16, 2012 at 2:11 AM, Ravindran, Parthasarathi <[email-masked]<mailto:[email-masked]>> wrote:
Cullen/Justin,

Thanks
Partha

>Cc: Justin Uberti; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>From: Cullen Jennings [mailto:[email-masked]<mailto:[email-masked]>]
>>Cc: Justin Uberti; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi
>><[email-masked]<mailto:[email-masked]>> wrote:
>>> Hi Justin,
>>>
>>> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi
>><[email-masked]<mailto:[email-masked]>> wrote:
>>> Hi Justin,
>>>
>>> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi
>><[email-masked]<mailto:[email-masked]>> wrote:
>>> Hi Justin,
>>>
>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>>Behalf Of Justin Uberti
>>> [email-masked]<mailto:[email-masked]>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 17 Feb 2012 14:21:19 -0700

I'm most interested in real world use cases which if they were being done with SIP would result in multiple 200 being processed by the browser. I have not got my head around why this would be needed yet and without the use cases I'm having a hard time deciding if there is a problem or not. 

On Feb 16, 2012, at 7:35 PM, Justin Uberti wrote:

> On Thu, Feb 16, 2012 at 2:11 AM, Ravindran, Parthasarathi <[email-masked]> wrote:
> Cullen/Justin,
> 
> >><[email-masked]> wrote:
> >>> Hi Justin,
> >>>
> >><[email-masked]> wrote:
> >>> Hi Justin,
> >>>
> >><[email-masked]> wrote:
> >>> Hi Justin,
> >>>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 17 Feb 2012 16:42:58 -0500

Cullen,

Real case would be anything which implements small group calling with
caller side mixing.

One example, which is typically used, is a sports team contact. There is a
SIP URL which is associated with an entire team. A person places a call to
the team's SIP URL. Call gets forked to all the members of the team. Some
members answer the call. Multiple simultaneous calls are established, with
mixing done in the caller user agent. All the team members who answered and
the caller are talking to each other.

Another example is shared line appearance. SIP URL which belongs to boss
calls both bosses and secretary phones. If both peak up, both are placed in
a conference (once again with mixing done in the client user agent). This
simulates two analog phones connected to the same line.

Before anybody starts saying that those examples are limited to traditional
telephony and have only a limited applicability, I would suggest to look at
GroupMe or a number of other group calling start ups that showed up and
managed to create quite a substantial following recently.

Two workaround exist to implement small group calling with no forking.

One option is to call through a conferencing server. Downside, apart from a
need for a conferencing server, is media hair-pin and extra delay on audio
path.

Another option is to send an invitation for a call to all potential
participants, get offers from each participant that is joining the call,
create new channel for each offer and send the answer back. Downside of
this approach is an extra half a round trip.

Both of those options become especially costly if most of the calls are to
one party only and only a small portion of calls result in group call.
_____________
Roman Shpount

On Fri, Feb 17, 2012 at 4:21 PM, Cullen Jennings <[email-masked]> wrote:

>
> I'm most interested in real world use cases which if they were being done
> with SIP would result in multiple 200 being processed by the browser. I
> have not got my head around why this would be needed yet and without the
> use cases I'm having a hard time deciding if there is a problem or not.
>
>
> > Agree it has not been addressed. I'm having some trouble understanding
> the exact flows that we need to address here (multiple 2xx, multiple 18x
> > If this sounds good to you, would you mind sketching out a call flow
> that I could include in the examples section?
> >

---

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

Hi,

I can of course only speak for myself, but in all my years of working with SIP systems I have never encountered a use case where multiple 200 responses would have to be accepted. In most cases the first 2xx will be accepted, and any subsequent 2xx will be ACKed+ BYEed.

However, from a browser perspective I don't think it matters whether the answers are received in 18x responses or 2xx responses. The fact is that multiple answers may be received, and the browser needs to be able to handle that. 

And, it seems like people agree that a new answer would replace the old one, as also suggested by Justin below.

And, IF someone wants to establish simultanous dialogs with multiple remote entities, in my opinion it would then be better to e.g. create multiple PeerConnections (one for each remote entity), or something like that.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Cullen Jennings [[email-masked]]
Sent: Friday, February 17, 2012 11:21 PM
To: Justin Uberti
Cc: [email-masked]; [email-masked]
Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP        [was RE: New JSEP draft posted]

---

From: Justin Uberti <[email-masked]>
Date: Fri, 17 Feb 2012 17:59:40 -0500

On Fri, Feb 17, 2012 at 5:36 PM, Christer Holmberg <
[email-masked]> wrote:

>
> Hi,
>
> I can of course only speak for myself, but in all my years of working with
> SIP systems I have never encountered a use case where multiple 200
> responses would have to be accepted. In most cases the first 2xx will be
> accepted, and any subsequent 2xx will be ACKed+ BYEed.
>
> However, from a browser perspective I don't think it matters whether the
> answers are received in 18x responses or 2xx responses. The fact is that
> multiple answers may be received, and the browser needs to be able to
> handle that.
>

To be clear, the JS can either decide that first one wins, or last one
wins, or whatever it wants. At setRemoteDescription level though, whatever
you supply (if you do it at all) will replace the previous description.

>
> And, IF someone wants to establish simultanous dialogs with multiple
> remote entities, in my opinion it would then be better to e.g. create
> multiple PeerConnections (one for each remote entity), or something like
> that.
>

Agree.

---

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

Cullen,

As I mentioned below, the problem statement is for multiple answer and multiple 200 is one of the IETF SIP (RFC 3261) defined multiple answer usecase. Deployed (real) SIP world usecase for multiple answer exists in form of 18x with answer1 and 2xx with answer2 for INVITE offer. I worked/interoped with multiple well deployed implementation which supports "receiving" multiple answer with slight different variance (and no UPDATE [RFC 3311] in the middle) and I'm sure more implementation exists. The reason for allowing "receiving" multiple answer is leniency while receiving the SIP message which is generally accepted in Product development. Even though some of the deployed implementation violates RFC 3264 for the noble reason of reducing the number of SIP messages (no UPDATE Offer/answer transaction after 18x) for the basic call, it is possible to make those implementation SIP RFC compliance by changing 18x To-Tag, Please look into "18x with SDP and 2xx with different SDP & To Tag" attachment for more details. 

Also, 18x with SDP and 2xx without SDP is the another set implementation exists as mentioned in "18x with SDP and 2xx without SDP" attachment. In case these details are not enough, I'll add Multiple 18x with different 2xx callflow later.

Keeping aside SIP deployment, I'm still not convinced why browser MUST be restricted from multiple answer as I didn't see the technical reason for restricting. As I mentioned, Fixed-Mobile application is possible to implement using this mechanism and WebRTC shall provide the building block for it.  The callflow is shown in "Single Offer Multiple Answer callflow" example.

AFAIK, offer results in RTP port allocation in the resource manager and SRTP key generation. In case first answer is received, those resources are required irrespective of multiple answer will receive or not. In case your argument is about pre-allocated (RSVP kind of) bandwidth for offer, those specific WebRTC applications are free to reject the second answer onwards and consider first answer as the final answer, so this proposal in not limiting those applications.  Could you please clarify any other list of resources lock/leak in your mind due to offer for my understanding. I'm asking this query as I get the feeling from other mail threads that resource lock/leak is one of the reason for requesting final answer by you.

Justin,

I have added 3 callflow as a starting point for the discussion which shall be added later in case consensus is reached. I'll provide multiple 18x with different order 2xx later.

Thanks
Partha

>Sent: Saturday, February 18, 2012 2:51 AM
>To: Justin Uberti
>Cc: Ravindran, Parthasarathi; [email-masked]; [email-masked]
>I'm most interested in real world use cases which if they were being
>done with SIP would result in multiple 200 being processed by the
>browser. I have not got my head around why this would be needed yet and
>without the use cases I'm having a hard time deciding if there is a
>problem or not.
>
>
>followed by 2xx, multiple 18x followed by multiple 2xx) but if I
>understand correctly your suggestion was:
>>
>> 2) document that in this case (multiple 2xx), the JS is responsible
>for sending BYE to the previous answerer.
>>
>> >Subject: RE: [rtcweb] Single offer with multiple answer handling in
>> >remote UAs (because the INVITE forked), each 2xx establishes a
>> >different dialog.  All these dialogs are part of the same call.
>> >
>> >The usecase 3 is based on RFC3262 (PRACK) support wherein it is
>> >possible to receive multiple forked 18x with SDP followed by 2xx with
>> >or without SDP and SIP 2xx response is not tied to offer/answer
>exchange.
>> >
>> >answer may be used in the offer in some JS application. As I
>> >mentioned below, there is no need to restrict updating latest answer
>> >for an offer in terms of API and protocol.
>> >
>> >Thanks
>> >Partha
>> >
>> >>I'm a bit lost on use case in SIP context - assuming that the UAC
>> >>did not fork but that a proxy or B2BUA did the forking, it seems
>> >>like the UAC should never receive more than one final response.
>> >>
>> >>updating the stream and would use a call flow more like update
>> >>examples in the draft instead of trying to reuse some old answer.
>> >>
>> >>
>> >>identity will alert all the signed-in devices and it is possible
>> >>that multiple devices answer to the session. Here, user may move
>> >>from one device
>> >>(mobile) to another device (desktop) within the session and wishes
>> >>to continue the session with the last answer. Please note that
>> >>website is flexible to provide this service.
>> >>> 2)      RFC 3261 SIP UA offer/answer handling w.r.t INVITE with
>SDP
>> >to
>> >>within 18x and 200 are not same. Say 2xx of the second 18x is
>> >>received as the first 2xx. Here, we need to know how second 18x is
>> >>handled and also, the subsequent 2xx is handled.
>> >>>
>> >>application to decide the order in which offer/answer happens. I'm
>> >>not relating offer/answer FSM with session establishment state like
>> >>18x, 2xx but I'm interested in knowing browser media plane behavior
>> >>in different state of offer/answer handling by which JS application
>> >>> Subject: Re: Single offer with multiple answer handling in JSEP
>> >>> [was
>> >>RE: [rtcweb] New JSEP draft posted]
>> >>>
>> >>> Partha,
>> >>>
>> >>two) answers for the single offer in WebRTC browser.  Now, Please
>> >>let me know your opinion for my below mail.
>> >>>
>> >>> Thanks
>> >>> Partha
>> >>>
>> >>> Subject: Re: Single offer with multiple answer handling in JSEP
>> >>> [was
>> >>RE: [rtcweb] New JSEP draft posted]
>> >>>
>> >>>
>> >>>
>> >>for single offer will not lead to RTP Mixing and WebRTC client acts
>> >>as RTP Endpoint.
>> >>>
>> >>putting this scenario in the browser implementation specific. In
>> >>simple scenarios (like alerting with one answer, connect with second
>> >>answer), replacing the previous ANSWER will be expected behavior.
>> >>This may not be desired behavior in case two connect responses from
>> >>different WebRTC clients received with different answers  but there
>> >>is no other alternative solution possible without mixing.
>> >>>
>> >>to the offer will replace the existing answer is the expected
>> >>behavior ". Also, Please mentioned that JS application is
>responsible for
>> >>> Subject: Re: Single offer with multiple answer handling in JSEP
>> >>> [was
>> >>RE: [rtcweb] New JSEP draft posted]
>> >>>
>> >>transmit RTP which may not be desired behavior. IMO, we need to
>> >>define this behavior clearly in offerer side. Some of the possible
>> >>solutions are
>> >>>
>> >>the best idea about what is going on, and therefore is responsible
>> >>for notifying answerer1 that its answer has been discarded, if it
>> >>makes sense to do so. No callback should be needed here.
>> >>>
>> >>>
>> >>> Subject: Single offer with multiple answer handling in JSEP [was
>RE:
>> >>[rtcweb] New JSEP draft posted]
>> >>>
>> >>> Hi Justin,
>> >>>
>> >>> OffererJS->OffererUA:  pc.setRemoteDescription(SDP_ANSWER,
>> >>> OffererJS->answer1);
>> >>> OffererJS->OffererUA:  pc.setRemoteDescription(SDP_ANSWER,
>> >>> OffererJS->answer2);
>> >>whether it updates the media stream based on the last answer or
>> >>mixes both answerer.
>> >>>
>> >>> Thanks
>> >>> Partha
>> >>>
>> >>in the interim meeting. I think there are ways of handling this
>> >>either in the application or the implementation, but I wanted to get
>> >>this -01 out first for feedback.
>> >>>
>> >>>
>> >>>

---

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

Partha,

Thanks for these example flows. I'm out on vacation this week but will try
to distill and incorporate the consensus on this topic when I return.

Regards,
--justin

On Sun, Feb 19, 2012 at 2:25 PM, Ravindran, Parthasarathi <
[email-masked]> wrote:

> Cullen,
>
> As I mentioned below, the problem statement is for multiple answer and
> multiple 200 is one of the IETF SIP (RFC 3261) defined multiple answer
> usecase. Deployed (real) SIP world usecase for multiple answer exists in
> form of 18x with answer1 and 2xx with answer2 for INVITE offer. I
> worked/interoped with multiple well deployed implementation which supports
> "receiving" multiple answer with slight different variance (and no UPDATE
> [RFC 3311] in the middle) and I'm sure more implementation exists. The
> reason for allowing "receiving" multiple answer is leniency while receiving
> the SIP message which is generally accepted in Product development. Even
> though some of the deployed implementation violates RFC 3264 for the noble
> reason of reducing the number of SIP messages (no UPDATE Offer/answer
> transaction after 18x) for the basic call, it is possible to make those
> implementation SIP RFC compliance by changing 18x To-Tag, Please look into
> "18x with SDP and 2xx with different SDP & To Tag" attachment for more
> details.
>
> Also, 18x with SDP and 2xx without SDP is the another set implementation
> exists as mentioned in "18x with SDP and 2xx without SDP" attachment. In
> case these details are not enough, I'll add Multiple 18x with different 2xx
> callflow later.
>
> Keeping aside SIP deployment, I'm still not convinced why browser MUST be
> restricted from multiple answer as I didn't see the technical reason for
> restricting. As I mentioned, Fixed-Mobile application is possible to
> implement using this mechanism and WebRTC shall provide the building block
> for it.  The callflow is shown in "Single Offer Multiple Answer callflow"
> example.
>
> AFAIK, offer results in RTP port allocation in the resource manager and
> SRTP key generation. In case first answer is received, those resources are
> required irrespective of multiple answer will receive or not. In case your
> argument is about pre-allocated (RSVP kind of) bandwidth for offer, those
> specific WebRTC applications are free to reject the second answer onwards
> and consider first answer as the final answer, so this proposal in not
> limiting those applications.  Could you please clarify any other list of
> resources lock/leak in your mind due to offer for my understanding. I'm
> asking this query as I get the feeling from other mail threads that
> resource lock/leak is one of the reason for requesting final answer by you.
>
> Justin,
>
> I have added 3 callflow as a starting point for the discussion which shall
> be added later in case consensus is reached. I'll provide multiple 18x with
> different order 2xx later.
>
> Thanks
> Partha
>