Subject: Re: [MMUSIC] Bundle-16: BAS and ICE updated offer colliding

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 Feb 2015 15:35:42 +0000

Hi,

Section 8.4.2 currently says:

"When an offerer receives an answer, if the answer contains a BUNDLE
              group, the offerer MUST check whether the offerer BUNDLE address,
              selected by the answerer [Section 8.3.2], matches what was assigned
              to each bundled "m=" line (excluding any bundled "m=" line that was
              rejected, or moved out of the BUNDLE group, by the answerer) in the
              associated offer.  If there is a mismatch, the offerer SHOULD as soon
              as possible generate a subsequent offer, in which it assigns the
              offerer BUNDLE address to each bundled "m=" line."

Based on the comments from Thomas, I suggest to modify the last sentence to:

              If there is a mismatch, the offerer SHOULD as soon
              as possible generate a subsequent offer, in which it assigns the
              offerer BUNDLE address to each bundled "m=" line, <new>unless it
knows that such offer is not required by network entities or the
remote peer</new>.

Does anyone have any issues with such addition?

Regards,

Christer

From: Stach, Thomas [mailto:[email-masked]]
Sent: 30 January 2015 22:18
To: Makaraju, Maridi Raju (Raju); Christer Holmberg
Cc: [email-masked]
Subject: RE: Bundle-16: BAS and ICE updated offer colliding

Raju,

of course the 491 will clean things up finally, but at the cost of a delay up to 4s.
Nevertheless, collisions should remain rare.
However, in the case below chance for a collisions would be quite high, which in my opinion needs to be avoided and resolved in an interoperable way.

Regards
Thomas

From: Makaraju, Maridi Raju (Raju) [mailto:[email-masked]]
Sent: Freitag, 30. Januar 2015 18:34
To: Stach, Thomas; Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Bundle-16: BAS and ICE updated offer colliding

Such a collision race condition is not completely avoidable and may happen in general.
IMO, this particular race condition related to BAS offer and "default candidate update" offer should be handled in a general way rather than as a special case.
How an implementation handles it depends on the underlying signaling protocol used.

When SIP is used "491 (Request Pending)" procedures [1][2] can be used.

[1] http://tools.ietf.org/html/rfc3261#section-14.2

   A UAS that receives an INVITE on a dialog while an INVITE it had sent

   on that dialog is in progress MUST return a 491 (Request Pending)

   response to the received INVITE.

[2] http://tools.ietf.org/html/rfc3261#section-14.1

   If a UAC receives a 491 response to a re-INVITE, it SHOULD start a

   timer with a value T chosen as follows:

      1. If the UAC is the owner of the Call-ID of the dialog ID

         (meaning it generated the value), T has a randomly chosen value

         between 2.1 and 4 seconds in units of 10 ms.

      2. If the UAC is not the owner of the Call-ID of the dialog ID, T

         has a randomly chosen value of between 0 and 2 seconds in units

         of 10 ms.

BR
Raju

From: mmusic [mailto:[email-masked]] On Behalf Of Stach, Thomas
Sent: Friday, January 30, 2015 8:34 AM
To: Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] Bundle-16: BAS and ICE updated offer colliding

From: Christer Holmberg [mailto:[email-masked]]
Sent: Freitag, 30. Januar 2015 15:16
To: Stach, Thomas
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Bundle-16: BAS and ICE updated offer colliding

Hi,

I will go through your use-case more in detail later, but in general I would not like to start defining procedures for specific use-cases.
[TS] I didn't see that as a specific use-case, rather something that arises due to the way how the rules for the 2nd OA in -bundle and ICE are written.

A couple of initial questions/observations:

  1.  A race condition can already happen, if the offerer needs to send a PRACK and/or UPDATE for some other reason.
And, as those can be sent throughout the session establishment, I think the risk of a non-BUNDLE race condition is even bigger.
[TS] The case I was talking about is when you don't use PRACK.  The collision that I had in mind would be _less_ likely if you use PRACK,
since ICE takes a while the conclude and would give enough time to finish BAS before the ICE updated offer is to be sent.
In the end this would however result  in 3 OA cycles.

  1.  Do we expect the ICE controller to send UPDATE so fast, that it may collide with the BAS offer? The ICE controller will anyway send an answer to the initial offer, and the BAS can be sent immediately after that.
[TS] Since ICE is specifically designed to work also without PRACK, we need to consider that case as well. Without PRACK you can initiate the 2nd OA cycle only after the 200OK for the INVITE was sent.
In the case below both UAs would do that at approximately at the same time. Hence my concern about collisions.

Ok, I get it. Your concern is that, after the 200OK for the INVITE was sent, the BAS offer and the ICE update offer would be sent at the same time, causing a race condition?
[TS] Exactly. That also why I think that the draft needs to say something about the interaction.

Of course, if the initial offer would KNOW that the ICE update offer is coming, it could wait before sending the BAS offer. But, as you said, it may not come if the default candidate was selected.
[TS] Yes, that's the tricky part. The offerer would of course learn that the default candidates were selected and could eventually initiate BAS.
There might be still a theoretical(?) risk that the ICE controller sends an updated offer anyhow.
All this is getting as ugly as this Outlook formatting ;-).

Regards
Thomas

Regards,

Christer

From: Stach, Thomas [mailto:[email-masked]]
Sent: 30. tammikuuta 2015 12:31
To: Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>
Subject: Bundle-16: BAS and ICE updated offer colliding

Christer,

I just came across the following tricky corner case.
Consider an offerer supporting only ICE-lite and an answerer supporting full ICE (and being ICE controller in that case).
If both support BUNDLE, BAS would be initiated by the offerer and the ICE updated offer by the answerer.
This would easily lead to an offer/answer collision.
Maybe we would want to state a dedicated rule for that case.

Proposal:
The ICE controller starts the ICE updated offer since it needs to provide the a=remote-candidates attribute.
The ICE controller also puts the shared address in the corresponding m/c-lines.
If the controlled ICE-Agent (the previous offerer) sent the ICE updated offer, it couldn't include the a=remote-candidates attribute and yet another O/A cycle would be necessary, if my interpretation of the corresponding ICE rules is correct.

There is however one caveat.
The ICE controller does not need to the send the ICE updated offer if the default candidate was nominated.
What should happen here?

Regards
Thomas

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 9 Feb 2015 16:05:38 +0000

Christer, 

the addition is ok for me.

It does however not give a hint about the collision issue with the ICE updated offer.
If you want to instruct implementors about that, you could further add a note somewhere in 8.4.2:

"If a BUNDLE group is used together with ICE, certain scenarios exist that might lead to an increased probability of BAS offers colliding with the ICE updated offer which is sent by the ICE controlling agent. If such collision cases need to be avoided, the rules for creating the ICE updated offer SHOULD take precedence."

Would that be helpful? 

Regards
Thomas

From: Christer Holmberg [mailto:[email-masked]] 
Sent: Freitag, 6. Februar 2015 16:36
To: Stach, Thomas; Makaraju, Maridi Raju (Raju)
Cc: [email-masked]
Subject: RE: Bundle-16: BAS and ICE updated offer colliding

Hi,

Regards,

Christer

Raju,

Regards
Thomas

BR
Raju

 
Hi,

 
 
2. Do we expect the ICE controller to send UPDATE so fast, that it may collide with the BAS offer? The ICE controller will anyway send an answer to the initial offer, and the BAS can be sent immediately after that.
[TS] Since ICE is specifically designed to work also without PRACK, we need to consider that case as well. Without PRACK you can initiate the 2nd OA cycle only after the 200OK for the INVITE was sent. 
In the case below both UAs would do that at approximately at the same time. Hence my concern about collisions.

 
Regards
Thomas
 
Regards,
 
Christer

 
Christer, 

Proposal:

Regards
Thomas

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 9 Feb 2015 18:29:35 +0000

I am ok with either addition.
But wondering if Thomas's suggestion may belong to section 11 (ICE Considerations).

I have a suggestion to make Thomas's suggestion bit more explicit.
Per my understanding the BAS update may piggyback on any SDP answer sent in response to an offer from the other end (though I could not find corresponding text in the draft though). Section 8.4.2 says " the offerer SHOULD as soon as possible generate a subsequent offer". Can we modify this text to indicate that in some cases (e.g. ICE) implementations may wait for some time (1 or seconds?) for possible piggyback BAS update opportunity before sending a BAS offer. And then update section 11 for such possible glare cases.

BR
Raju

> -----Original Message-----
> Sent: Monday, February 09, 2015 10:06 AM
> To: Christer Holmberg
> Cc: [email-masked]
> "If a BUNDLE group is used together with ICE, certain scenarios exist that
> might lead to an increased probability of BAS offers colliding with the ICE
> updated offer which is sent by the ICE controlling agent. If such collision
> cases need to be avoided, the rules for creating the ICE updated offer
> SHOULD take precedence."
> 
> Would that be helpful?
> 
> Regards
> Thomas
> 
> However, in the case below chance for a collisions would be quite high,
> which in my opinion needs to be avoided and resolved in an interoperable
> way.
> 
> Regards
> Thomas
> 
> IMO, this particular race condition related to BAS offer and "default
> candidate update" offer should be handled in a general way rather than as a
> special case.
> I will go through your use-case more in detail later, but in general I would
> not like to start defining procedures for specific use-cases.
> [TS] I didn't see that as a specific use-case, rather something that arises
> due to the way how the rules for the 2nd OA in -bundle and ICE are written.
> 
> 
> And, as those can be sent throughout the session establishment, I think the
> risk of a non-BUNDLE race condition is even bigger.
> [TS] The case I was talking about is when you don't use PRACK.  The
> collision that I had in mind would be _less_ likely if you use PRACK,
> since ICE takes a while the conclude and would give enough time to finish
> BAS before the ICE updated offer is to be sent.
> 2. Do we expect the ICE controller to send UPDATE so fast, that it may
> collide with the BAS offer? The ICE controller will anyway send an answer to
> the initial offer, and the BAS can be sent immediately after that.
> [TS] Since ICE is specifically designed to work also without PRACK, we need
> to consider that case as well. Without PRACK you can initiate the 2nd OA
> cycle only after the 200OK for the INVITE was sent.
> Ok, I get it. Your concern is that, after the 200OK for the INVITE was sent,
> the BAS offer and the ICE update offer would be sent at the same time,
> causing a race condition?
> Of course, if the initial offer would KNOW that the ICE update offer is
> coming, it could wait before sending the BAS offer. But, as you said, it may
> not come if the default candidate was selected.
> [TS] Yes, that's the tricky part. The offerer would of course learn that the
> default candidates were selected and could eventually initiate BAS.
> Consider an offerer supporting only ICE-lite and an answerer supporting full
> ICE (and being ICE controller in that case).
> If the controlled ICE-Agent (the previous offerer) sent the ICE updated
> offer, it couldn't include the a=remote-candidates attribute and yet another
> O/A cycle would be necessary, if my interpretation of the corresponding ICE
> rules is correct.
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Feb 2015 18:36:23 +0000

Hi,

I really don't think we should add more text, talk about how many seconds on should wait etc.

There are many usages and applications which can cause an offer race condition - ICE is just one of them.

Regards,

Christer

-----Original Message-----
From: Makaraju, Maridi Raju (Raju) [mailto:[email-masked]] 
Sent: 09 February 2015 20:30
To: Stach, Thomas; Christer Holmberg
Cc: [email-masked]
Subject: RE: Bundle-16: BAS and ICE updated offer colliding

BR
Raju

> "If a BUNDLE group is used together with ICE, certain scenarios exist 
> that might lead to an increased probability of BAS offers colliding 
> with the ICE updated offer which is sent by the ICE controlling agent. 
> If such collision cases need to be avoided, the rules for creating the 
> ICE updated offer SHOULD take precedence."
> 
> Would that be helpful?
> 
> Regards
> Thomas
> 
> However, in the case below chance for a collisions would be quite 
> high, which in my opinion needs to be avoided and resolved in an 
> interoperable way.
> 
> Regards
> Thomas
> 
> From: Makaraju, Maridi Raju (Raju) 
> [mailto:[email-masked]]
> candidate update" offer should be handled in a general way rather than 
> as a special case.
> I will go through your use-case more in detail later, but in general I 
> would not like to start defining procedures for specific use-cases.
> [TS] I didn't see that as a specific use-case, rather something that 
> arises due to the way how the rules for the 2nd OA in -bundle and ICE are written.
> 
> 
> 1. A race condition can already happen, if the offerer needs to send a 
> PRACK and/or UPDATE for some other reason.
> And, as those can be sent throughout the session establishment, I 
> think the risk of a non-BUNDLE race condition is even bigger.
> since ICE takes a while the conclude and would give enough time to 
> finish BAS before the ICE updated offer is to be sent.
> collide with the BAS offer? The ICE controller will anyway send an 
> answer to the initial offer, and the BAS can be sent immediately after that.
> [TS] Since ICE is specifically designed to work also without PRACK, we 
> need to consider that case as well. Without PRACK you can initiate the 
> 2nd OA cycle only after the 200OK for the INVITE was sent.
> Ok, I get it. Your concern is that, after the 200OK for the INVITE was 
> sent, the BAS offer and the ICE update offer would be sent at the same 
> time, causing a race condition?
> Of course, if the initial offer would KNOW that the ICE update offer 
> is coming, it could wait before sending the BAS offer. But, as you 
> said, it may not come if the default candidate was selected.
> [TS] Yes, that's the tricky part. The offerer would of course learn 
> that the default candidates were selected and could eventually initiate BAS.
> Consider an offerer supporting only ICE-lite and an answerer 
> supporting full ICE (and being ICE controller in that case).
> The ICE controller starts the ICE updated offer since it needs to 
> provide the a=remote-candidates attribute.
> The ICE controller also puts the shared address in the corresponding 
> m/c- lines.
> If the controlled ICE-Agent (the previous offerer) sent the ICE 
> updated offer, it couldn't include the a=remote-candidates attribute 
> and yet another O/A cycle would be necessary, if my interpretation of 
> the corresponding ICE rules is correct.
>

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 10 Feb 2015 09:28:46 +0000

I agree with Christer on this one

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Montag, 9. Februar 2015 19:36
To: Makaraju, Maridi Raju (Raju); Stach, Thomas
Cc: [email-masked]
Subject: RE: Bundle-16: BAS and ICE updated offer colliding

Hi,

Regards,

Christer

-----Original Message-----
From: Makaraju, Maridi Raju (Raju) [mailto:[email-masked]] 
Sent: 09 February 2015 20:30
To: Stach, Thomas; Christer Holmberg
Cc: [email-masked]
Subject: RE: Bundle-16: BAS and ICE updated offer colliding

BR
Raju

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 10 Feb 2015 11:42:18 +0000

I am ok with that.

Hi Christer,

> Per my understanding the BAS update may piggyback on any SDP answer sent in
> response to an offer from the other end (though I could not find
> corresponding text in the draft though).
[Raju] I believe BAS update must be reflected in the next SDP, not just offer but any answer as well, sent by this entity.
Am I missing related text in the draft? or such text does not yet exist?

Thanks
Raju

> Sent: Tuesday, February 10, 2015 3:29 AM
> To: Christer Holmberg; Makaraju, Maridi Raju (Raju)
> Cc: [email-masked]
> Per my understanding the BAS update may piggyback on any SDP answer sent in
> response to an offer from the other end (though I could not find
> corresponding text in the draft though). Section 8.4.2 says " the offerer
> SHOULD as soon as possible generate a subsequent offer". Can we modify this
> text to indicate that in some cases (e.g. ICE) implementations may wait for
> some time (1 or seconds?) for possible piggyback BAS update opportunity
> before sending a BAS offer. And then update section 11 for such possible
> glare cases.
> 
> BR
> Raju
> 
> > In the case below both UAs would do that at approximately at the same
> time.
> > Hence my concern about collisions.
> >

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Feb 2015 13:31:14 +0000

Hi,

I am not sure what you mean by "BAS update must be reflected in any answer". Could you please clarify?

Regards,

Christer

-----Original Message-----
From: Makaraju, Maridi Raju (Raju) [mailto:[email-masked]] 
Sent: 10. helmikuuta 2015 13:42
To: Stach, Thomas; Christer Holmberg
Cc: [email-masked]
Subject: RE: Bundle-16: BAS and ICE updated offer colliding

I am ok with that.

Hi Christer,

> Per my understanding the BAS update may piggyback on any SDP answer 
> sent in response to an offer from the other end (though I could not 
> find corresponding text in the draft though).

Thanks
Raju

> Per my understanding the BAS update may piggyback on any SDP answer 
> sent in response to an offer from the other end (though I could not 
> find corresponding text in the draft though). Section 8.4.2 says " the 
> offerer SHOULD as soon as possible generate a subsequent offer". Can 
> we modify this text to indicate that in some cases (e.g. ICE) 
> implementations may wait for some time (1 or seconds?) for possible 
> piggyback BAS update opportunity before sending a BAS offer. And then 
> update section 11 for such possible glare cases.
> 
> BR
> Raju
> 
> > "If a BUNDLE group is used together with ICE, certain scenarios 
> > exist that might lead to an increased probability of BAS offers 
> > colliding with the ICE updated offer which is sent by the ICE controlling agent.
> > If such collision cases need to be avoided, the rules for creating 
> > the ICE updated offer SHOULD take precedence."
> >
> > Would that be helpful?
> >
> > Regards
> > Thomas
> >
> > Based on the comments from Thomas, I suggest to modify the last 
> > sentence
> to:
> >
> > IMO, this particular race condition related to BAS offer and 
> > "default candidate update" offer should be handled in a general way 
> > rather than as a special case.
> > I will go through your use-case more in detail later, but in general 
> > I would not like to start defining procedures for specific use-cases.
> > arises due to the way how the rules for the 2nd OA in -bundle and 
> > ICE are
> written.
> >
> >
> > 1. A race condition can already happen, if the offerer needs to send 
> > a PRACK and/or UPDATE for some other reason.
> > collision that I had in mind would be _less_ likely if you use 
> > PRACK, since ICE takes a while the conclude and would give enough 
> > time to finish BAS before the ICE updated offer is to be sent.
> > 2. Do we expect the ICE controller to send UPDATE so fast, that it 
> > may collide with the BAS offer? The ICE controller will anyway send 
> > an answer to the initial offer, and the BAS can be sent immediately 
> > after
> that.
> > [TS] Since ICE is specifically designed to work also without PRACK, 
> > we need to consider that case as well. Without PRACK you can 
> > initiate the 2nd OA cycle only after the 200OK for the INVITE was sent.
> > Ok, I get it. Your concern is that, after the 200OK for the INVITE 
> > was sent, the BAS offer and the ICE update offer would be sent at 
> > the same time, causing a race condition?
> > that the default candidates were selected and could eventually 
> > initiate
> BAS.
> > and yet another O/A cycle would be necessary, if my interpretation 
> > of the corresponding ICE rules is correct.
> >

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 10 Feb 2015 16:37:46 +0000

> Could you please clarify?

[Raju] Sorry for not being clear.
Scenario:
a. Client A does SDP offer/answer with B using BUNDLE.
b. Before A sends BAS offer, it received SDP offer from B.
   A sends SDP answer.
   Won't the SDP answer here include BAS updates? I think so, which also 
   avoids subsequent dedicated BAS offer.

BR
Raju

> [Raju] I believe BAS update must be reflected in the next SDP, not just
> offer but any answer as well, sent by this entity.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Feb 2015 08:56:44 +0000

Hi,

>   avoids subsequent dedicated BAS offer.

Ok, now I get it.

True, if A sends an answer before it sends the BAS offer, there will be no need for a BAS offer. Because, an answer must always contain the negotiated BUNDLE address.

I need to think a little about text. I don't think we should talk about piggybacking.

Regards,

Christer

> [Raju] I believe BAS update must be reflected in the next SDP, not 
> just offer but any answer as well, sent by this entity.
> > find corresponding text in the draft though). Section 8.4.2 says " 
> > the offerer SHOULD as soon as possible generate a subsequent offer". 
> > Can we modify this text to indicate that in some cases (e.g. ICE) 
> > piggyback BAS update opportunity before sending a BAS offer. And 
> > then update section 11 for such possible glare cases.
> >
> > BR
> > Raju
> >
> > > "default candidate update" offer should be handled in a general 
> > > way rather than as a special case.
> > > I will go through your use-case more in detail later, but in 
> > > general I would not like to start defining procedures for specific use-cases.
> > > [TS] I didn't see that as a specific use-case, rather something 
> > > that arises due to the way how the rules for the 2nd OA in -bundle 
> > > and ICE are
> > written.
> > >
> > >
> > > 1. A race condition can already happen, if the offerer needs to 
> > > send a PRACK and/or UPDATE for some other reason.
> > > [TS] The case I was talking about is when you don't use PRACK.  
> > > The collision that I had in mind would be _less_ likely if you use 
> > > may collide with the BAS offer? The ICE controller will anyway 
> > > send an answer to the initial offer, and the BAS can be sent 
> > > immediately after
> > that.
> > > [TS] Since ICE is specifically designed to work also without 
> > > PRACK, we need to consider that case as well. Without PRACK you 
> > > can initiate the 2nd OA cycle only after the 200OK for the INVITE was sent.
> > > Of course, if the initial offer would KNOW that the ICE update 
> > > offer is coming, it could wait before sending the BAS offer. But, 
> > > as you said, it may not come if the default candidate was selected.
> > > [TS] Yes, that's the tricky part. The offerer would of course 
> > > learn that the default candidates were selected and could 
> > > eventually initiate
> > BAS.
> > > updated offer, it couldn't include the a=remote-candidates 
> > > attribute and yet another O/A cycle would be necessary, if my 
> > > interpretation of the corresponding ICE rules is correct.
> > >