Subject: [MMUSIC] ICE with media streams without candidates

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 22 Oct 2007 12:56:40 +0200

Hi,

Chapter 5.1 of the draft says:

"The agent will proceed with the ICE procedures defined in this
specification if, for each media stream in the SDP it received, the
default destination for each component of that media stream appears in a
candidate attribute."

Does this mean that if, for whatever reason, some of the media streams
(m= lines) do not contain any attributes ICE will NOT proceed?

Regards,

Christer

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 22 Oct 2007 14:31:08 +0300

> (m= lines) do not contain any attributes ICE will NOT proceed?

I think the next paragraph is pretty clear:

   If this condition is not met, the agent MUST process the SDP based on
   normal RFC 3264 procedures, without using any of the ICE mechanisms
   described in the remainder of this specification with the following
   exceptions:

   1.  The agent MUST follow the rules of Section 10, which describe
       keepalive procedures for all agents.

   2.  If the agent is not proceeding with ICE because there were
       a=candidate attributes, but none that matched the default
       destination of the media stream, the agent MUST include an a=ice-
       mismatch attribute in its answer.

-- 
Rémi Denis-Courmont

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 22 Oct 2007 13:46:39 +0200

Hi, 

>>default destination for each component of that media stream appears in 
>>a candidate attribute."
>>

What is the reason for having this all-or-nothing restriction? Why can't I perform ICE on other media streams, with candidates, just because some media streams do not contain candidates?

Regards,

Christer

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 22 Oct 2007 15:28:41 +0300

Le Monday 22 October 2007 14:46:39 ext Christer Holmberg, vous avez écrit :
> What is the reason for having this all-or-nothing restriction? Why can't I
> perform ICE on other media streams, with candidates, just because some
> media streams do not contain candidates?

The text says, ICE is not run if a media has no candidate matching the m= 
line. It also says agents must insert a candidate matching the m= line (which 
acts as the fallback candidate if the other endpoint does not support ICE).

Why would there be a media without a matching candidate anyway? A conforming 
agent will never emit such a SDP. If there is an Application Layer Gateway, 
then ICE would likely fail, so better fallback to pre-ICE behavior. I think 
that was the rationale beyond these instructions.

-- 
Rémi Denis-Courmont

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 22 Oct 2007 15:12:27 +0200

Hi, 

>>What is the reason for having this all-or-nothing restriction? Why 
>>can't I perform ICE on other media streams, with candidates, just 
>>because some media streams do not contain candidates?
>
>The text says, ICE is not run if a media has no candidate 
>matching the m= line.

Yes. I can understand that ICE is not run for that specific media, but why does it also mean that I can't run ICE for other medias?

Or, have I missunderstood?

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 23 Oct 2007 09:10:52 +0200

Hi, 

>matching the m= line. It also says agents must insert a 
>candidate matching the m= line (which acts as the fallback 
>candidate if the other endpoint does not support ICE).
> 
>Why would there be a media without a matching candidate 
>anyway? A conforming agent will never emit such a SDP. If 
>there is an Application Layer Gateway, then ICE would likely 
>fail, so better fallback to pre-ICE behavior. I think that 
>was the rationale beyond these instructions.

One example: 

Assume A calls B, and includes SDP with the ICE candidate attributes etc for each media stream.

In the middle there is a B2BUA application server, which wants to add a stream towards B, so it modifies the SDP by adding an extra m= line. The application server, however, does not support ICE, so it does not include any candidate attributes.

B will now receive an SDP where the m= line added by the application server does not contain candidates, so it will disable ICE also for the streams that did contain candiates.

A                                   B2BUA                                B

----- SDP ---------------------------->
      m=audio                         ------ SDP ------------------------>
	<candidates>                            m=audio
                                              <candidates>
                                              m=video

Another example:

Assume A calls B, and includes SDP with the ICE candidate attributes etc for each media stream.

In the middle there is a B2BUA application server, which realizes that transcoding is needed for one of the streams, so it modifies that part of the SDP. Again, however, the application server does not support ICE, so it does not include any candidate attributes for the transcoded media stream (it may forward the candidates it received, but that will cause an ICE mismatch anyway).

B will now receive an SDP where the m= line modified by the application server does not contain candidates (or, it does, but they cause a mismatch), so it will disable ICE also for the streams that did contain valid candiates.

A                                   B2BUA                                B

----- SDP ---------------------------->
      m=audio                         ------ SDP ------------------------>
	<candidates> 
      m=video                                m=audio
      <candidates>                           <candidates>
                                             m=video transcoded

Another example when some specific streams use some kind of relays (non-TURN) for the NAT traversal, and don't need ICE. But, I haven't thought very much of those use-cases yet.

Regards,

Christer

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 23 Oct 2007 15:28:52 +0300

Christer,

Le Tuesday 23 October 2007 10:10:52 ext Christer Holmberg, vous avez écrit :
> In the middle there is a B2BUA application server, which wants to add a
> stream towards B, so it modifies the SDP by adding an extra m= line. The
> application server, however, does not support ICE, so it does not include
> any candidate attributes.

We can probably agree that if there is something that modifies this SDP even 
though it does not terminate the SIP session, anything can happen. And 
probably nobody wants to start a SBC flame war here ;)

As a developper, I would rather it had been per-media, or better yet, a 
per-component process, because it would have been much simpler to implement 
and integrate. There are however several valid reasons why ICE is a SIP 
per-session process, as far as ICE is used with SIP.

I can think of plenty of loopholes if one media has ICE, but not another one. 
For instance, how would the UA know when to start sending media? But most 
importantly, the decision to abort ICE when some inconsistency is detected is 
all about maximizing backward compatibility with existing setups. If there is 
some middlebox modifying the SDP in a way that breaks ICE, it is safest to 
assume that ICE might not work. As such it should not be used at all. ICE was 
simply not meant to operate in such scenarios.

Also, in most scenarios where the SDP media information is modified, it is 
most probably that all medias will be modified in a way that would make them 
ineligible for ICE: probably the original medias (those NOT coming from the 
application server) would go through some kind of media proxying device 
anyway. Right?

-- 
Rémi Denis-Courmont

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 23 Oct 2007 15:10:41 +0200

Hi, 

>>In the middle there is a B2BUA application server, which wants to add 
>>a stream towards B, so it modifies the SDP by adding an extra m= line. 
>>The application server, however, does not support ICE, so it does not 
>>include any candidate attributes.
> 
>We can probably agree that if there is something that 
>modifies this SDP even though it does not terminate the SIP 
>session, anything can happen. And probably nobody wants to 
>start a SBC flame war here ;)
> 
>As a developper, I would rather it had been per-media, or 
>better yet, a per-component process, because it would have 
>been much simpler to implement and integrate. There are 
>however several valid reasons why ICE is a SIP per-session 
>process, as far as ICE is used with SIP.
>
>For instance, how would the UA know when to start sending 
>media? But most importantly, the decision to abort ICE when 
>some inconsistency is detected is all about maximizing 
>backward compatibility with existing setups. If there is some 
>middlebox modifying the SDP in a way that breaks ICE, it is 
>safest to assume that ICE might not work. As such it should 
>not be used at all. ICE was simply not meant to operate in 
>such scenarios.

I am not arguing against the mismatch rules as such, I am just wondering if there are technical reasons why they can't be done per media.

>Also, in most scenarios where the SDP media information is 
>modified, it is most probably that all medias will be 
>modified in a way that would make them ineligible for ICE: 
>probably the original medias (those NOT coming from the 
>application server) would go through some kind of media 
>proxying device anyway. Right?

Not necessarily. In my examples the media NOT generated/transcoded by the application server does not need to go through any media proxying device.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 26 Oct 2007 15:21:57 +0200

Hi, 

>>We can probably agree that if there is something that modifies this SDP 
>>even though it does not terminate the SIP session, anything can happen. 
>>And probably nobody wants to start a SBC flame war here ;)
>> 
>>per-component process, because it would have been much simpler to 
>>implement and integrate. There are however several valid reasons why 
>>ICE is a SIP per-session process, as far as ICE is used with SIP.
>>
>>For instance, how would the UA know when to start sending media? But 
>>most importantly, the decision to abort ICE when some inconsistency is 
>>detected is all about maximizing backward compatibility with existing 
>>setups. If there is some middlebox modifying the SDP in a way that 
>>breaks ICE, it is safest to assume that ICE might not work. As such it 
>>should not be used at all. ICE was simply not meant to operate in such 
>>scenarios.
> 
>I am not arguing against the mismatch rules as such, I am 
>just wondering if there are technical reasons why they can't 
>be done per media.
> 
>>Also, in most scenarios where the SDP media information is modified, it 
>>is most probably that all medias will be modified in a way that would 
>>make them ineligible for ICE: robably the original medias (those NOT coming from the application 
>>server) would go through some kind of media proxying device anyway. 
>>Right?
> 
>Not necessarily. In my examples the media NOT 
>generated/transcoded by the application server does not need 
>to go through any media proxying device.

Also, chapter 9.1.1.3 allows ICE-per-stream when a new stream is added, so I see no reason why ICE-per-stream (ICEstream :) can't be used also in the beginning of the session.

Regards,

Christer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 28 Oct 2007 17:25:15 -0400

This section does not in any way adding a new media stream that is not 
utilizing ICE. It simply says that you can add one and ICE processing 
for it begins when you do.

To answer your original question, the reason we elected to make it all 
or nothing was because of the unpredictability of ICE through SBCs. For 
example an SBC that is not ICE-aware, adds a media stream, but allows 
ICE parameters through, is actually very likely to have some kind of 
firewalling behavior associated with it, that blocks the media stream 
unless it behaves the way it expects. So in the interests of 
reliability, ICE backs off whenever it sees anything resembling a 
non-ICE aware intermediary.

This is something that was discussed quite a bit previously and I don't 
see any reason to re-evaluate our previous decision on this.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 29 Oct 2007 14:55:42 +0100

Hi Jonathan, 

>This section does not in any way adding a new media stream 
>that is not utilizing ICE. It simply says that you can add 
>one and ICE processing for it begins when you do.

Yes, that is what I meant. You do ICE per-stream.

>To answer your original question, the reason we elected to 
>make it all or nothing was because of the unpredictability of 
>ICE through SBCs. For example an SBC that is not ICE-aware, 
>adds a media stream, but allows ICE parameters through, is 
>actually very likely to have some kind of firewalling 
>behavior associated with it, that blocks the media stream 
>reliability, ICE backs off whenever it sees anything 
>resembling a non-ICE aware intermediary.

Even if the SBC does not add a media stream, it can still have such kind of firewalling behaviour.

>This is something that was discussed quite a bit previously 
>and I don't see any reason to re-evaluate our previous 
>decision on this.

I admit I am late, but I would really ask you to do that re-evalutation, if there are no technical reasons why it can't be done.

Yes, we can add some text talking about potential issues when all streams do not contain ICE candidates, but I still think we should allow such cases.

This has come up in 3GPP, where we currently are looking at ICE support when there are SBCs in the network.

Regards,

Christer

> >>>> In the middle there is a B2BUA application server, which 
> wants to 
> >>>> add a stream towards B, so it modifies the SDP by adding 
> an extra m= line.
> >>>> The application server, however, does not support ICE, 
> so it does 
> >>>> not include any candidate attributes.
> modifies this 
> >>> SDP even though it does not terminate the SIP session, 
> anything can happen.
> >>> As a developper, I would rather it had been per-media, or better 
> >>> yet, a per-component process, because it would have been much 
> >>> simpler to implement and integrate. There are however 
> several valid 
> >>> reasons why ICE is a SIP per-session process, as far as 
> ICE is used with SIP.
> >>>
> media? But 
> >>> most importantly, the decision to abort ICE when some 
> inconsistency 
> >>> is detected is all about maximizing backward compatibility with 
> >>> existing setups. If there is some middlebox modifying the 
> SDP in a 
> >>> way that breaks ICE, it is safest to assume that ICE 
> might not work. 
> >>> As such it should not be used at all. ICE was simply not meant to 
> >>> operate in such scenarios.
> >> I am not arguing against the mismatch rules as such, I am just 
> >> wondering if there are technical reasons why they can't be 
> done per 
> >> media.
> >>
> >>> Also, in most scenarios where the SDP media information 
> is modified, 
> >>> it is most probably that all medias will be modified in a 
> way that 
> >>> would make them ineligible for ICE: robably the original medias 
> >>> (those NOT coming from the application
> generated/transcoded by 
> >> the application server does not need to go through any 
> media proxying 
> >> device.
> > 
> > Also, chapter 9.1.1.3 allows ICE-per-stream when a new 
> stream is added, so I see no reason why ICE-per-stream 
> (ICEstream :) can't be used also in the beginning of the session.
> > 
> > Regards,
> > 
> > Christer
> > 
> >