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

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 30 Jan 2015 10:31:10 +0000

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: Christer Holmberg <[email-masked]>
Date: Fri, 30 Jan 2015 13:45:59 +0000

Hi Thomas,

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.

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.

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.

Regards,

Christer

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

Christer,

Proposal:

What should happen here?

Regards
Thomas

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 30 Jan 2015 14:07:48 +0000

Chirster,
Let me clarify.

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

Hi Thomas,

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

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

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,

Proposal:

What should happen here?

Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Jan 2015 14:16:19 +0000

Hi,

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.

Regards,

Christer

Christer,

Proposal:

What should happen here?

Regards
Thomas

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 30 Jan 2015 14:33:30 +0000

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

      Hi,

      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

            Christer,

            Proposal:

            Regards
            Thomas

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 30 Jan 2015 17:33:59 +0000

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]
Subject: Re: [MMUSIC] Bundle-16: BAS and ICE updated offer colliding

Hi,

1.       A race condition can already happen, if the offerer needs to send a PRACK and/or UPDATE for some other reason.

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: "Stach, Thomas" <[email-masked]>
Date: Fri, 30 Jan 2015 20:17:50 +0000

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]
Subject: RE: Bundle-16: BAS and ICE updated offer colliding

         of 10 ms.

BR
Raju

Hi,

Regards
Thomas

Regards,

Christer

Christer,

Proposal:

Regards
Thomas