Subject: [MMUSIC] ICE updated offer

From: Ari Keränen <[email-masked]>
Date: Tue, 14 Oct 2014 11:15:12 +0300

Hi all,

At the Toronto meeting we discussed whether we should change the 
behavior with ICE updated offer. Currently, based on RFC 5245, when ICE 
has finished, there is a new offer/answer with the selected candidate, 
*if* they are different from the "default candidates", i.e., the ones in 
original o/a m- and c-lines.

Based on the discussion there was strong desire to have an option of not 
doing the updated o/a at all by indicating this in the original o/a. On 
the other hand, for some, the updated o/a was seen as a requirement for 
getting correct behavior from the network in certain scenarios (e.g., 
with SIP-aware middle boxes).

I would like to hear from people, who have issues making the updated o/a 
optional, how bad the change would be and is there a way we could make 
this work also in those scenarios?

Cheers,
Ari

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Oct 2014 08:44:00 +0000

Hi,

ISSUES:
----------

I think not doing the updated o/a (in case the SDP is not aligned with the selected candidates) would cause serious problems in environments where you have intermediaries etc that depend on correct SDP information, e.g. to open gates etc.

SOLUTION SUGGESTION:
---------------------------------

I DO understand that there are cases where the second o/a is not needed, even if the SDP is not aligned with the selected candidates (as the endpoints will get the information about selected candidates from the STUN messages). However, I don't think we can assume that the offerer knows when that is the case. 

So, if people don't want to keep the current rules, one alternative would to indicate in the ANSWER whether the second offer is needed or not. 

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Ari Keränen
Sent: 14. lokakuuta 2014 11:15
To: mmusic
Subject: [MMUSIC] ICE updated offer

Hi all,

At the Toronto meeting we discussed whether we should change the behavior with ICE updated offer. Currently, based on RFC 5245, when ICE has finished, there is a new offer/answer with the selected candidate,
*if* they are different from the "default candidates", i.e., the ones in original o/a m- and c-lines.

Based on the discussion there was strong desire to have an option of not doing the updated o/a at all by indicating this in the original o/a. On the other hand, for some, the updated o/a was seen as a requirement for getting correct behavior from the network in certain scenarios (e.g., with SIP-aware middle boxes).

I would like to hear from people, who have issues making the updated o/a optional, how bad the change would be and is there a way we could make this work also in those scenarios?

Cheers,
Ari

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Emil Ivov <[email-masked]>
Date: Tue, 14 Oct 2014 16:32:58 +0200

On 14.10.14, 10:44, Christer Holmberg wrote:
> Hi,
>
> ISSUES: ----------
>
> I think not doing the updated o/a (in case the SDP is not aligned
> with the selected candidates) would cause serious problems in
> environments where you have intermediaries etc that depend on correct
> SDP information, e.g. to open gates etc.

Opening gates needs to happen from the first O/A though. Right? 
Otherwise ICE checks are not going to succeed.

> SOLUTION SUGGESTION: ---------------------------------
>
> I DO understand that there are cases where the second o/a is not
> needed, even if the SDP is not aligned with the selected candidates
> (as the endpoints will get the information about selected candidates
> from the STUN messages). However, I don't think we can assume that
> the offerer knows when that is the case.
>
> So, if people don't want to keep the current rules, one alternative
> would to indicate in the ANSWER whether the second offer is needed or
> not.

I don't really mind this (especially if the default is: don't send an 
update) ... but, I'd also like to understand the exact use case where 
this is necessary. The only one I can think of is a middle box that 
introduces relayed candidates. I don't find this to be a compelling 
arguments since that relay can simply timeout if necessary.

I must be missing something obviously so ... looking forward to hearing 
examples

Emil

>
> Regards,
>
> Christer
>
>
>
> -----Original Message----- From: mmusic
> [mailto:[email-masked]] On Behalf Of Ari Keränen Sent: 14.
> lokakuuta 2014 11:15 To: mmusic Subject: [MMUSIC] ICE updated offer
>
> Hi all,
>
> behavior with ICE updated offer. Currently, based on RFC 5245, when
> ICE has finished, there is a new offer/answer with the selected
> candidate, *if* they are different from the "default candidates",
> i.e., the ones in original o/a m- and c-lines.
>
> Based on the discussion there was strong desire to have an option of
> not doing the updated o/a at all by indicating this in the original
> o/a. On the other hand, for some, the updated o/a was seen as a
> requirement for getting correct behavior from the network in certain
> scenarios (e.g., with SIP-aware middle boxes).
>
> I would like to hear from people, who have issues making the updated
> o/a optional, how bad the change would be and is there a way we could
> make this work also in those scenarios?
>
>
> Cheers, Ari
>
> _______________________________________________ mmusic mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________ mmusic mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
https://jitsi.org

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 14 Oct 2014 08:19:11 -0700

just trying to understand :

What happens in the cases where the network interface has totally changed ,
say going from WiFi only to 3G only or something ..
Don't we need to initiate new ICE checks and thus an update ..

Thanks
Suhas

On Tue, Oct 14, 2014 at 7:32 AM, Emil Ivov <[email-masked]> wrote:

> Opening gates needs to happen from the first O/A though. Right? Otherwise
> ICE checks are not going to succeed.
>
> update) ... but, I'd also like to understand the exact use case where this
> is necessary. The only one I can think of is a middle box that introduces
> relayed candidates. I don't find this to be a compelling arguments since
> that relay can simply timeout if necessary.
>

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 14 Oct 2014 15:24:01 +0000

Ari, 

although you haven't asked for issues _due_ to the ICE updated offer.
There is an old, expired draft that elaborates on that:
https://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-02 

It shows that e.g. certain 3PCC-based calls flows, that are used quite frequently in enterprise deployments, just don't work together with the ICE updated offer.
That's another reason for the desire for not doing the update.

A possible, but admittedly ugly remedy for those that need it for their middle boxes: 
If the offerer indicates that it doesn't perform the ICE updated offer, the middle box can send a trigger that starts the ICE updated offer once the dialog is confirmed. This triggers could e.g. be an offerless INVITE since it results in a new SDP offer/answer exchange.
Unfortunately, RFC5245 requires an ICE restart in this case and, of course, this behaviour needs to be maintained.
Now, in order to let the middle box learn the actually used transport addresses, the restart would need to be suppressed, e.g. via a flag in that offerless INVITE, which then triggers the ICE agent to perform procedures for ICE updated offers instead.

Regards
Thomas

> Sent: Dienstag, 14. Oktober 2014 10:15
> To: mmusic

---

From: Emil Ivov <[email-masked]>
Date: Tue, 14 Oct 2014 17:24:05 +0200

On 14.10.14, 17:19, Suhas Nandakumar wrote:
> What happens in the cases where the network interface has totally
> changed , say going from WiFi only to 3G only or something ..

Sure. This would be an ICE restart. But what we are discussing here is 
the mandatory Offer/Answer update that occurs at the end of ICE 
processing when ICE has resulted in using a pair that is different from 
the one that was originally default.

Emil

> Thanks
> Suhas
>
> On Tue, Oct 14, 2014 at 7:32 AM, Emil Ivov <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>         SOLUTION SUGGESTION: ------------------------------__---
>
>     I don't really mind this (especially if the default is: don't send
>     an update) ... but, I'd also like to understand the exact use case
>     where this is necessary. The only one I can think of is a middle box
>     that introduces relayed candidates. I don't find this to be a
>     compelling arguments since that relay can simply timeout if necessary.
>
>     I must be missing something obviously so ... looking forward to
>     hearing examples
>
>     Emil
>
>
>
>         Regards,
>
>         Christer
>
>
>
>         [mailto:[email-masked]
>         <mailto:[email-masked]>] On Behalf Of Ari Keränen Sent: 14.
>         _________________________________________________ mmusic mailing
>         list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/mmusic
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>
>         _________________________________________________ mmusic mailing
>         list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/mmusic
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>
>
>     --
>     https://jitsi.org
>
>
>     _________________________________________________
>     mmusic mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>

-- 
https://jitsi.org

---

From: Varun Singh <[email-masked]>
Date: Tue, 14 Oct 2014 18:24:53 +0300

On 14 Oct 2014 18:19, "Suhas Nandakumar" <[email-masked]> wrote:
> What happens in the cases where the network interface has totally changed
, say going from WiFi only to 3G only or something ..
> Don't we need to initiate new ICE checks and thus an update ..
I suppose it depends on when the interfaces become available:

I think the endpoint would trickle the candidates if the ice is ongoing. If
ice has frozen its candidates, then it would require an ice restart?

examples

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Oct 2014 15:27:37 +0000

Hi,

>> ISSUES: 
>> ----------
>>
>> I think not doing the updated o/a (in case the SDP is not aligned with 
>> the selected candidates) would cause serious problems in environments 
>> where you have intermediaries etc that depend on correct SDP 
>> information, e.g. to open gates etc.
>

Correct. Depending on policy, you may open gates in order to allow STUN requests associated with all candidates to pass, perhaps with limited bandwidth.

>> from the STUN messages). However, I don't think we can assume that the 
>> offerer knows when that is the case.
>>
> update) ... but, I'd also like to understand the exact use case where this is 
> necessary. The only one I can think of is a middle box that introduces 
> relayed candidates. I don't find this to be a compelling arguments since that > relay can simply timeout if necessary.

Perhaps there could be some timeout logic (and for some functions there are), but that is not how much of the existing deployments work today. They rely on the controller setting the gates, bandwidth, etc, based on SDP information.

Regards,

Christer

--
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Oct 2014 15:28:39 +0000

>Sure. This would be an ICE restart. But what we are discussing here is the >mandatory Offer/Answer update that occurs at the end of ICE processing >when ICE has resulted in using a pair that is different from the one that was >originally default.

Correct.

Regards,

Christer

--
https://jitsi.org

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 14 Oct 2014 15:36:09 +0000

Christer,

> From: mmusic [mailto:[email-masked]] On Behalf Of Christer
> Holmberg
> Sent: Dienstag, 14. Oktober 2014 10:44
> To: Ari Keränen; mmusic
> Subject: Re: [MMUSIC] ICE updated offer
> 
> Hi,
> 
> ISSUES:
> ----------
> 
> I think not doing the updated o/a (in case the SDP is not aligned with the
> selected candidates) would cause serious problems in environments where you
> have intermediaries etc that depend on correct SDP information, e.g. to
> open gates etc.
> 
> 
> SOLUTION SUGGESTION:
> I DO understand that there are cases where the second o/a is not needed,
> even if the SDP is not aligned with the selected candidates (as the
> endpoints will get the information about selected candidates from the STUN
> messages). However, I don't think we can assume that the offerer knows when
> that is the case.
> 
> So, if people don't want to keep the current rules, one alternative would
> to indicate in the ANSWER whether the second offer is needed or not.
How would the answerer know that, if the offerer didn't?
If later on the call is established in the other direction, the roles are just reversed.
Regards
Thomas

> At the Toronto meeting we discussed whether we should change the behavior
> with ICE updated offer. Currently, based on RFC 5245, when ICE has
> finished, there is a new offer/answer with the selected candidate,
> doing the updated o/a at all by indicating this in the original o/a. On the
> other hand, for some, the updated o/a was seen as a requirement for getting
> correct behavior from the network in certain scenarios (e.g., with SIP-
> aware middle boxes).
> 
> optional, how bad the change would be and is there a way we could make this
> work also in those scenarios?
> 
> 
> Cheers,
> Ari
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Oct 2014 15:46:24 +0000

Hi,

>How would the answerer know that, if the offerer didn't?

The answerer, and/or the intermediaries. The point is that whoever needs the second offer is given a chance to indicate so to the offerer.

Regards,

Christer

> candidate,
> scenarios (e.g., with SIP- aware middle boxes).
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 14 Oct 2014 18:19:17 +0200

> I think not doing the updated o/a (in case the SDP is not aligned with the selected candidates) would cause serious problems in environments where you have intermediaries etc that depend on correct…

Once the PC is connected, inspect the selected candidates via
RTCStats, mangle your funny SDP with your custom JS code, and send
your needed SDP re-offer to your server.
No need to bore the native WebRTC API with that stuff.

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

---

From: Emil Ivov <[email-masked]>
Date: Tue, 14 Oct 2014 19:09:02 +0200

On 14.10.14, 17:27, Christer Holmberg wrote:
>>> environments where you have intermediaries etc that depend on
>>> correct SDP information, e.g. to open gates etc.
>>
> Correct. Depending on policy, you may open gates in order to allow
> STUN requests associated with all candidates to pass, perhaps with
> limited bandwidth.

According to 5245 pacing interval has to be calculated to match the 
bitrate of the intended media session so limiting the bandwidth doesn't 
sound like a good thing to do here.
>>> needed, even if the SDP is not aligned with the selected
>>> candidates (as the endpoints will get the information about
>>> selected candidates from the STUN messages). However, I don't
>>> think we can assume that the offerer knows when that is the
>>> case.
>>>
>>> So, if people don't want to keep the current rules, one
>>> alternative would to indicate in the ANSWER whether the second
>>> offer is needed or not.
>>
>> where this is necessary. The only one I can think of is a middle
>> box that introduces relayed candidates. I don't find this to be a
>> compelling arguments since that > relay can simply timeout if
>> necessary.
>
> Perhaps there could be some timeout logic (and for some functions
> there are), but that is not how much of the existing deployments work
> today. They rely on the controller setting the gates, bandwidth, etc,
> based on SDP information.

I might be off but I don't think the plan is to impose this condition on 
the past (although I don't think many implementations actually do this). 
I suppose we are trying to decide whether future implementations would 
need to treat this as mandatory.

If an implementation declares itself as not supporting 5245bis, or one 
of its specific features, then yes, I would assume the O/A update would 
still have to happen.

Emil

>> [mailto:[email-masked]] On Behalf Of Ari Keränen Sent:
>> 14. lokakuuta 2014 11:15 To: mmusic Subject: [MMUSIC] ICE updated
>> offer
>>
>> Hi all,
>>
>> behavior with ICE updated offer. Currently, based on RFC 5245,
>> when ICE has finished, there is a new offer/answer with the
>> selected candidate, *if* they are different from the "default
>> candidates", i.e., the ones in original o/a m- and c-lines.
>>
>> Based on the discussion there was strong desire to have an option
>> of not doing the updated o/a at all by indicating this in the
>> original o/a. On the other hand, for some, the updated o/a was seen
>> as a requirement for getting correct behavior from the network in
>> certain scenarios (e.g., with SIP-aware middle boxes).
>>
>> I would like to hear from people, who have issues making the
>> updated o/a optional, how bad the change would be and is there a
>> way we could make this work also in those scenarios?
>>
>>
>> Cheers, Ari
>>
>> _______________________________________________ mmusic mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>>
>> _______________________________________________ mmusic mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> -- https://jitsi.org
>

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Oct 2014 17:26:14 +0000

Hi,

>> I think not doing the updated o/a (in case the SDP is not aligned with the selected 
>> candidates) would cause serious problems in environments where you have intermediaries >> etc that depend on correct SDP information, e.g. to open gates etc.
>
> Once the PC is connected, inspect the selected candidates via RTCStats, mangle your funny > SDP with your custom JS code, and send your needed SDP re-offer to your server.

ICE is also used elsewhere than in WebRTC. 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Oct 2014 17:32:10 +0000

Hi,

>According to 5245 pacing interval has to be calculated to match the bitrate of the intended >media session so limiting the bandwidth doesn't sound like a good thing to do here.

It is nowhere said that you have to do that, but it is what people sometimes do.

>>>> would to indicate in the ANSWER whether the second offer is needed 
>>>> or not.
>>>
>>> arguments since that > relay can simply timeout if necessary.
>>
> I might be off but I don't think the plan is to impose this condition on the past (although I 
> don't think many implementations actually do this). 
> I suppose we are trying to decide whether future implementations would need to treat this > as mandatory.
>
> If an implementation declares itself as not supporting 5245bis, or one of its specific features, > then yes, I would assume the O/A update would still have to happen.

Again, I am perfectly fine by not mandating the O/A update, as long as it is possible to trigger it if needed.

Regards,

Christer

--
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Tue, 14 Oct 2014 20:22:32 +0200

> It is nowhere said that you have to do that, but it is what people sometimes do.

Have a look at 5245, 16.1:

    These formulas are aimed at causing STUN transactions to be paced at
    the same rate as media.  This ensures that ICE will work properly
    under the same network conditions needed to support the media as
    well.

and then 5245, B.1

    The definition of a "reasonable" rate is that STUN should not use
    more bandwidth than the RTP itself will use, once media starts
    flowing.  The formula for Ta is designed so that, if a STUN packet
    were sent every Ta seconds, it would consume the same amount of
    bandwidth as RTP packets, summed across all media streams.

> Again, I am perfectly fine by not mandating the O/A update, as long as it is possible to trigger it if needed.

I seem to remember that this is pretty much the consensus we reached in 
Toronto.

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Oct 2014 18:31:09 +0000

Hi,

...

> I seem to remember that this is pretty much the consensus we reached in Toronto.

My understanding is that the consensus was to allow the offerer to indicate whether it is going to send a second offer or not, without the answerer (or an intermediary) being able to impact that decision. I am asking for a way for the answerer (or an intermediary) to tell the offerer whether the second offer is needed.

Regards,

Christer

>>> o/a optional, how bad the change would be and is there a way we 
>>> could make this work also in those scenarios?
>>>
>>>
>>> Cheers, Ari
>>>

--
https://jitsi.org

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 15 Oct 2014 04:50:21 +0530

+1

Adding further, SDP handling (signaling) entity and media handling entities
for the given session shall be different physical device in the answerer
side. By not updating SDP information, the resource allocated by signaling
entity would not freed or used properly. STUN only based signaling mechanism
in the middle of the session leads to the issue in those architecture as SDP
handling entity will not aware of the conclusion.

Please note that SDP handling (signaling) entity and media handling entity
as a different device in the answerer side is not defined in IETF RTCWeb so
far. 

> Sent: Tuesday, October 14, 2014 2:14 PM
> To: Ari Keränen; mmusic
> needed, even if the SDP is not aligned with the selected candidates (as
> the endpoints will get the information about selected candidates from
> the STUN messages). However, I don't think we can assume that the

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Oct 2014 12:16:16 +0200

2014-10-15 1:20 GMT+02:00 Parthasarathi R <[email-masked]>:
> STUN only based signaling mechanism

If the SDP handling "entity" is not aware of the media/STUN stuff then
you have a big problem.

> as a different device in the answerer side is not defined in IETF RTCWeb so

Of course. And what?
Both "entities" are supposed to be the same, or to inter-communicate
somehow one to each other.

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

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 15 Oct 2014 21:41:48 +0530

<snip> > If the SDP handling "entity" is not aware of the media/STUN stuff then
> you have a big problem. </snip>

IOW, the second offer/answer is required to solve the problem. 

Please note that single offer/answer may be suitable in couple of deployments but it is not generic enough to accept as a single solution.

> From: Iñaki Baz Castillo [mailto:[email-masked]]
> Sent: Wednesday, October 15, 2014 3:46 PM
> To: Parthasarathi R
> Cc: Christer Holmberg; Ari Keränen; mmusic

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Oct 2014 18:37:15 +0200

> Please note that single offer/answer may be suitable in couple of deployments but it is not generic enough to accept as a single solution.

Nothing prevents you from performing a second and a third O/A round trip.

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

---

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 16 Oct 2014 05:58:04 +0000

> IOW, the second offer/answer is required to solve the problem.
[TS] It might solve that problem, but causes other problems
> 
> Please note that single offer/answer may be suitable in couple of
> deployments but it is not generic enough to accept as a single solution.
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Oct 2014 06:25:58 +0000

Hi,

> Nothing prevents you from performing a second and a third O/A round trip.

The whole purpose is to, in the ICE spec, specify that that second offer must be sent, so that people implementing applications (JavaScript or native) do it.

But, again, I do realize there are cases where the second offer is not needed, and that is why I as a compromise suggested that it should be possible to signal whether it's needed or not.

Regards,

Christer

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 17 Oct 2014 09:19:31 +0000

All,

I don't have the impression Ari's question was aimed to challenge 
the consensus for option #3 from IETF#90.
However, it seems that now the arguments in favor or against 
the ICE updated offer are going around in circles 
without addressing Ari's initial question anymore.

----------------------------------
I would like to hear from people, who have issues making the updated o/a 
optional, how bad the change would be and is there a way we could make 
this work also in those scenarios?
----------------------------------

Trying make progress on that here is what I think are the 3 proposed remedies:

Proposal A: Indicate in the ANSWER whether the second offer is needed or not. 
Proposal B: If you need the update, send an offerless re-INVITE with a flag 
            that suppresses an ICE restart, 
            but triggers the ICE updated offer instead.
Proposal C: The signaling entity should inform the media entity about 
            the candidates. The media entity can then learn through the 
            STUN checks which address is eventually used for media.

Are there additional proposals or do we want to choose from these?

I might be biased, but Proposal A looks more like a 
4th option - challenging the IETF90 result -  than a remedy for option 3.

Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Oct 2014 10:01:21 +0000

Hi,

Whatever decisions are made at the meetings must (or, at least that seem to be de facto practise) be confirmed on the mailing list. So, it is ok to challenge them (luckily that doesn't happen too often, though - at least not within the groups where I participate).

>            but triggers the ICE updated offer instead.

Using SIP terminology (as this mechanism could only be used with SIP anyway), the second offer will almost always be send during an early dialog, while the initial INVITE transaction is still ongoing. You cannot send a re-INVITE during that time, so it wouldn't work. Sending the re-INVITE once the call has been established could prevent early media, and any other information transported on the media plane during the early dialog phase. 

>           STUN checks which address is eventually used for media.

That might work if the media entity is STUN aware (and if the interface/protocol used to control the media entity supports transporting that kind of information). Often they are not. They are simply used to e.g. enforce bandwidth (and other network resources) and gating. 

> Are there additional proposals or do we want to choose from these?

One is to keep everything as it is today, as nothing is broken. Nobody has indicated that as a preference, though.

Regards,

Christer

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 17 Oct 2014 10:58:24 +0000

> 
> Hi,
> 
> Whatever decisions are made at the meetings must (or, at least that seem to
> be de facto practise) be confirmed on the mailing list. 
You're right I also haven't seen an explicit consensus call on the list. 
But there also wasn't objection against the minutes and they say:
"Chair calls consensus on option 3."
Maybe the chairs can help where we are wrt to consensus or not consensus.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Oct 2014 11:08:58 +0000

Hi,

There was a consensus call for 3, so the minutes are correct.

I apologize if I should have challenged the minutes, rather than waiting for an explicit verification call from the chairs.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Stach, Thomas<mailto:[email-masked]>
Sent: ‎17/‎10/‎2014 13:58
To: Christer Holmberg<mailto:[email-masked]>; Ari Keränen<mailto:[email-masked]>; mmusic<mailto:[email-masked]>
Subject: RE: [MMUSIC]  ICE updated offer - Back to the initial question

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 20 Oct 2014 14:32:50 +0000

Christer,

I'm trying to understand ... 
... and disagree with your last point

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Freitag, 17. Oktober 2014 12:01
> To: Stach, Thomas; Ari Keränen; mmusic
> be de facto practise) be confirmed on the mailing list. So, it is ok to
> challenge them (luckily that doesn't happen too often, though - at least
> not within the groups where I participate).
> 
> Using SIP terminology (as this mechanism could only be used with SIP
> anyway), the second offer will almost always be send during an early
> dialog, while the initial INVITE transaction is still ongoing. 
[TS] You seem to assume support for PRACK here. 
Of course, the offerless re-INVITE could not be used as a trigger for the new offer in this case.
You would need "something else" in such an environment. 
The offerless INVITE, nevertheless, sounds attractive to me for other environments, since it only requires basic RFC3261 functionality. 
> You cannot send a re-INVITE during that time, so it wouldn't work. 
[TS] If PRACK is not supported, you also couldn't send that second offer during the early dialog. 
> Sending the re-
> INVITE once the call has been established could prevent early media, 
[TS] So, if the offerer does support ICE but not PRACK, it wouldn't get early media, even if the connectivity checks were successful?
Do you assume support for preconditions in addition to PRACK?
> and
> any other information transported on the media plane during the early
> dialog phase.
> 
> That might work if the media entity is STUN aware (and if the
> interface/protocol used to control the media entity supports transporting
> that kind of information). Often they are not. They are simply used to e.g.
> enforce bandwidth (and other network resources) and gating.
> 
> One is to keep everything as it is today, as nothing is broken. 
[TS] I beg to disagree here. I repeatedly mentioned that certain 3PCC call flows break _due_ to the updated offer.
Regards
Thomas
> Nobody has indicated that as a preference, though.
> 
> Regards,
> 
> Christer
> 
> 
>

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 21 Oct 2014 05:53:40 +0530

Hi Thomas,

Could you please mention the exact 3PCC callflow which breaks because of the
ICE second offer. Of course ideally, it should have covered in ICE (RFC
5245). 

Early dialog will not work without PRACK (RFC 3264) in the single
offer/answer itself. In case you assume that 18x is reliable without PRACK
then it has lot of caveat as the intermediate SIP entities may use UDP as a
transport wherein UAS has no control over. I assume that you intent to say
that UPDATE (RFC 3311) is mandated in case of RFC 5245 second offer.

Thanks
Partha

> From: mmusic [mailto:[email-masked]] On Behalf Of Stach,
> Thomas
> Sent: Monday, October 20, 2014 8:03 PM
> To: Christer Holmberg; Ari Keränen; mmusic
> Subject: Re: [MMUSIC] ICE updated offer - Back to the initial question
> 
> Christer,
> 
> > >Proposal A: Indicate in the ANSWER whether the second offer is
> needed or
> > not.
> > >Proposal B: If you need the update, send an offerless re-INVITE with
> a
> > flag
> The offerless INVITE, nevertheless, sounds attractive to me for other
> environments, since it only requires basic RFC3261 functionality.
> [TS] So, if the offerer does support ICE but not PRACK, it wouldn't get
> early media, even if the connectivity checks were successful?
> [TS] I beg to disagree here. I repeatedly mentioned that certain 3PCC
> call flows break _due_ to the updated offer.
> Regards
> Thomas
> > > *if* they are different from the "default candidates", i.e., the
> ones
> > > in original o/a m- and c-lines.
> > >
> of
> updated

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 21 Oct 2014 07:53:02 +0000

Partha,

> 
> Hi Thomas,
> 
> Could you please mention the exact 3PCC callflow which breaks because of
> the ICE second offer. 
You might want to look into
http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-02#section-3.1

> Of course ideally, it should have covered in ICE (RFC
> 5245).
We could cover this in ICEbis though.
> transport wherein UAS has no control over. 
RC5245 has already covered this
Regards
Thomas
> I assume that you intent to say

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Oct 2014 10:18:26 +0000

Hi,

>> Could you please mention the exact 3PCC callflow which breaks because 
>> of the ICE second offer.

The text in that draft says:

	"The B2BUA cannot pass that request on until the INVITE transaction 
	with UA2 has completed."

This is only true if PRACK is not supported.

In 5245 we did a hack, allowing to send the "answer" in unreliable 18x. The justification was that "people don't implement PRACK". Perhaps, as part of the bis work, we should check whether that justification is still valid. 

Regards,

Christer

> Of course ideally, it should have covered in ICE (RFC 5245).
> offer/answer itself. In case you assume that 18x is reliable without 
> PRACK then it has lot of caveat as the intermediate SIP entities may 
> use UDP as a transport wherein UAS has no control over.
> > > Whatever decisions are made at the meetings must (or, at least 
> > > that
> > seem to
> > > be de facto practise) be confirmed on the mailing list. So, it is 
> > > ok
> > to
> > > Using SIP terminology (as this mechanism could only be used with 
> > > SIP anyway), the second offer will almost always be send during an 
> > > early dialog, while the initial INVITE transaction is still ongoing.
> > The offerless INVITE, nevertheless, sounds attractive to me for 
> > other environments, since it only requires basic RFC3261 functionality.
> > [TS] So, if the offerer does support ICE but not PRACK, it wouldn't 
> > get early media, even if the connectivity checks were successful?
> > > any other information transported on the media plane during the 
> > > early dialog phase.
> > >
> > > >            the candidates. The media entity can then learn 
> > > > through
> > the
> > > that kind of information). Often they are not. They are simply 
> > > used
> > to e.g.
> > [TS] I beg to disagree here. I repeatedly mentioned that certain 
> > 3PCC call flows break _due_ to the updated offer.
> > Regards
> > Thomas
> > > > selected candidate,
> > > > not doing the updated o/a at all by indicating this in the 
> > > > original o/a. On the other hand, for some, the updated o/a was 
> > > > seen as a requirement for getting correct behavior from the 
> > > > network in
> > certain

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 23 Oct 2014 01:35:57 -0400

In terms of consensus call, we had pretty strong consensus in the 
meeting for option #3 (see under 
http://www.ietf.org/proceedings/90/minutes/minutes-90-mmusic#h.1yc63e74pbhi). 
To recap, the options and consensus outcome were:

<quote>

3 options

1. Current 5245 behavior (only if change from default candidate)

2. MUST always do updated O/A (whether change or not)

3. "Ekr's" proposal: you do it or don't do it, but you indicate in the 
o/a if you're going to do it. Basically want to have option to never do 
the updated O/A exchange, with an indication in the signaling that you 
will not be doing it. Of course can always initiate a new O/A exchange 
whenever you want to.

Consensus call by chair (Flemming):

0 for option 1

3 for option 2

15 for option 3
</quote>

Since then, Ari started a thread to find out if option 3 was causing 
major problems for people, and if so, if there were a (better ?) way of 
addressing those. This is essentialy what this whole "ICE updated offer" 
thread has been about.

 From a chair point of view, I think it's fair to say that we have heard 
additional points of view and proposals as part of this thread, but that 
we also only heard from a subset of the people involved in the 
discussion at IETF 90. What I would suggest is that the author (Ari) 
actively engages the people that expressed an opinion at IETF 90 in this 
discussion to get their points of view. We can then discuss at IETF 91 
again and take another consensus call based on all the information 
available. We will make sure to also take that consensus call to the 
mailing list subsequently to hopefully agree on the way forward (or at 
least get explicit consensus).

Thanks

-- Flemming (as MMUSIC co-chair).

On 10/17/14, 7:08 AM, Christer Holmberg wrote:
> I apologize if I should have challenged the minutes, rather than 
> waiting for an explicit verification call from the chairs.
>
> Regards,
>
> Christer
>
> ------------------------------------------------------------------------
> From: Stach, Thomas <mailto:[email-masked]>
> Sent: ?17/?10/?2014 13:58
> To: Christer Holmberg <mailto:[email-masked]>; Ari 
> Keränen <mailto:[email-masked]>; mmusic <mailto:[email-masked]>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 23 Oct 2014 08:04:08 +0000

Why are you playing around with SDP?
Getting SDP offer/answer to work is difficult as it is.
Not being able to rely on SDP information to begin with is the wrong way forward, and it will have big impacts on existing SIP based deployments.
Interoperability with existing SIP deployments is very important.

Regards,

Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Standards and Industry Alliances
[email-masked]<mailto:[email-masked]>
+1-609-903-3360

From: mmusic [mailto:[email-masked]] On Behalf Of Flemming Andreasen
Sent: Thursday, October 23, 2014 1:36 AM
To: Christer Holmberg; Stach, Thomas; Ari Keränen; mmusic
Subject: [MMUSIC] Revisit consensus ? [Re: ICE updated offer - Back to the initial question]

In terms of consensus call, we had pretty strong consensus in the meeting for option #3 (see under http://www.ietf.org/proceedings/90/minutes/minutes-90-mmusic#h.1yc63e74pbhi). To recap, the options and consensus outcome were:

<quote>

3 options

3. "Ekr's" proposal: you do it or don’t do it, but you indicate in the o/a if you’re going to do it. Basically want to have option to never do the updated O/A exchange, with an indication in the signaling that you will not be doing it. Of course can always initiate a new O/A exchange whenever you want to.

0 for option 1

3 for option 2

15 for option 3
</quote>

Since then, Ari started a thread to find out if option 3 was causing major problems for people, and if so, if there were a (better ?) way of addressing those. This is essentialy what this whole "ICE updated offer" thread has been about.

From a chair point of view, I think it's fair to say that we have heard additional points of view and proposals as part of this thread, but that we also only heard from a subset of the people involved in the discussion at IETF 90. What I would suggest is that the author (Ari) actively engages the people that expressed an opinion at IETF 90 in this discussion to get their points of view. We can then discuss at IETF 91 again and take another consensus call based on all the information available. We will make sure to also take that consensus call to the mailing list subsequently to hopefully agree on the way forward (or at least get explicit consensus).

Thanks

Regards,

Christer

mmusic mailing list

[email-masked]<mailto:[email-masked]>

---

From: Ari Keränen <[email-masked]>
Date: Thu, 23 Oct 2014 21:38:00 +0000

Ekr, Jonathan, et al,

We are now discussing the need for ICE updated offer (see below and the related threads on the MMUSIC list). As Flemming mentioned below, we have not yet heard opinions from everyone participating at the discussion at the previous meeting.

I tried to summarize the discussions so far also here:
https://mailarchive.ietf.org/arch/msg/mmusic/n1qOI7To4LuZRO41WGu4g702TvU

Could you please comment with your views so that we have the latest opinions from all sides.

Thanks,
Ari (as individual)

On Oct 23, 2014, at 8:35 AM, Flemming Andreasen wrote:

>> From: Stach, Thomas

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 24 Oct 2014 13:41:13 +0000

I participated in the discussed during IETF90 and have read through the latest thread.

During the meeting I was in favor of option 3 (Ekr's proposal: you do it or don’t do it, but you indicate in the o/a if you’re going to do it) and I have not seen any new arguments so I am still of the same opinion.

Regards
Andy

> Sent: 23 October 2014 22:38
> To: Eric Rescorla; Jonathan Lennox
> Cc: Flemming Andreasen; mmusic; Christer Holmberg
> Subject: Re: [MMUSIC] Revisit consensus ? [Re: ICE updated offer - Back
> to the initial question]
> 
> Ekr, Jonathan, et al,
> 
> We are now discussing the need for ICE updated offer (see below and the
> related threads on the MMUSIC list). As Flemming mentioned below, we
> have not yet heard opinions from everyone participating at the
> discussion at the previous meeting.
> 
> http://www.ietf.org/proceedings/90/minutes/minutes-90-
> mmusic#h.1yc63e74pbhi). To recap, the options and consensus outcome
> were:
> >
> > <quote>
> > 3 options
> > 3. "Ekr's" proposal: you do it or don’t do it, but you indicate in
> the o/a if you’re going to do it. Basically want to have option to
> never do the updated O/A exchange, with an indication in the signaling
> that you will not be doing it. Of course can always initiate a new O/A
> exchange whenever you want to.
> >
> addressing those. This is essentialy what this whole "ICE updated
> offer" thread has been about.
> >
> > From a chair point of view, I think it's fair to say that we have
> heard additional points of view and proposals as part of this thread,
> but that we also only heard from a subset of the people involved in the
> actively engages the people that expressed an opinion at IETF 90 in
> this discussion to get their points of view. We can then discuss at
> IETF 91 again and take another consensus call based on all the
> information available. We will make sure to also take that consensus
> call to the mailing list subsequently to hopefully agree on the way
> forward (or at least get explicit consensus).
> >
> > Thanks
> >
> that seem to

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 25 Oct 2014 14:33:47 +0000

Hi,

I am ok indicating in the ANSWER whether it shall be sent or not.

Regards,

Christer

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: 24 October 2014 16:41
To: Ari Keränen; Eric Rescorla; Jonathan Lennox
Cc: Flemming Andreasen; mmusic; Christer Holmberg
Subject: RE: [MMUSIC] Revisit consensus ? [Re: ICE updated offer - Back to the initial question]

Regards
Andy

> Subject: Re: [MMUSIC] Revisit consensus ? [Re: ICE updated offer - 
> Back to the initial question]
> 
> Ekr, Jonathan, et al,
> 
> We are now discussing the need for ICE updated offer (see below and 
> the related threads on the MMUSIC list). As Flemming mentioned below, 
> we have not yet heard opinions from everyone participating at the 
> https://mailarchive.ietf.org/arch/msg/mmusic/n1qOI7To4LuZRO41WGu4g702T
> v
> U
> 
> > 1. Current 5245 behavior (only if change from default candidate) 2. 
> > MUST always do updated O/A (whether change or not) 3. "Ekr's" 
> > proposal: you do it or don’t do it, but you indicate in
> major problems for people, and if so, if there were a (better ?) way 
> of addressing those. This is essentialy what this whole "ICE updated 
> but that we also only heard from a subset of the people involved in 
> the discussion at IETF 90. What I would suggest is that the author 
> (Ari) actively engages the people that expressed an opinion at IETF 90 
> in this discussion to get their points of view. We can then discuss at