Subject: [MMUSIC] ICE: Client supports, but network doesn't

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 21 Jun 2006 18:59:40 +0200

Hi,

Some questions on ICE:

1.	What happens if the c/m lines does not correspond to any active
a=candidate line? This could happen e.g. if you have a SDP modifying
B2BUA (which doesn't support ICE) in the path. One option would be to
say that the connectivity check shall be performed also for the c/m
lines in that case, but then we may need a "default priority", or
something...

2.	The ICE spec says that it is allowed for no a=candiate line, but
it does not describe what would happen in that case, and what the
expected UA behavior is in that case.

Regards,

Christer

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

---

From: Philip Matthews <[email-masked]>
Date: Fri, 23 Jun 2006 14:30:26 -0400

On 21-Jun-06, at 12:59 , Christer Holmberg ((JO/LMF)) wrote:

>
> Hi,
>
> Some questions on ICE:
>
> 1.      What happens if the c/m lines does not correspond to any  
> active a=candidate line? This could happen e.g. if you have a SDP  
> modifying B2BUA (which doesn't support ICE) in the path. One option  
> would be to say that the connectivity check shall be performed also  
> for the c/m lines in that case, but then we may need a "default  
> priority", or something...
What properties would we assume of such a SDP-modifying B2BUA?
For example, would the a-candidate lines still be present? Would they  
be modified by the B2BUA?
Can you cite the  behavior of some known products that do this?

> 2.      The ICE spec says that it is allowed for no a=candiate  
> line, but it does not describe what would happen in that case, and  
> what the expected UA behavior is in that case.
The only way to know that the remote client supports ICE is by the  
presence of a-candidate lines (well, I suppose a-remote-candidate and  
a-ice-pwd lines also count). If these lines are not present, then a  
client must assume the remote client does not support ICE, and thus  
the local client must fall back to normal pre-ICE behavior.
Or am I misunderstanding your comment?

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2006 15:28:10 -0400

Philip Matthews wrote:
> For example, would the a-candidate lines still be present? Would they be 
> modified by the B2BUA?

I had the same question. Of course, the problem is that since a b2bua is 
entirely undefined its not claer what it will do. But, I think we are 
safe in assuming its one of two things:

1. it modifies the m/c-lines but leaves the a=candidate attributes
2. it modifies the m/c-lines and removes all unknonwn attributes, 
including a=candidate attributes

I suspect (2) is much more likely from SBC products, but you never known.

Lets look at what happens in each of these cases. Case 2 is the easiest. 
  Both agents will think that the other side doesn't support ICE, and 
fallback to regular non-ICE behavior. So, things work as one would expect.

In case 1, with the current specification this will break badly. Because 
the m/c-line never appears as a candidate, the agents will never send 
media to it since it never validates. The way to fix this would be to 
change ice-09 to say that, if an agent doesn't see a cndidate for the 
m/c-line, it CAN send media to it without validating (kind of makes 
sense). Agents would also need to deal with cases where they get an 
updated offer and they can't find a matching candidate pair int he right 
state.

I think its worth adding the behavior needed to do this. I'd like ICE 
and SBC's to be 'compatible' in that, if you use ICE with an ICE-unaware 
SBC at least the call works the same as if the clients hadn't used ICE. 
Otherwise, there is disincetive to put ice into endpoints.

> 
>> 2.      The ICE spec says that it is allowed for no a=candiate line, 
>> but it does not describe what would happen in that case, and what the 

Agree, this is what needs to be described.

-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 \(JO/LMF\)" <[email-masked]>
Date: Sat, 24 Jun 2006 14:44:21 +0200

Hi,

>> Can you cite the behavior of some known products that do this?

[CHH] I would assume that one could find products behaving in either way. IF the B2BUA removes the candiate attributes I guess we'll get the scenario described in my second question. 

>including a=candidate attributes

[CHH] Correct. 

>fallback to regular non-ICE behavior. So, things work as one would expect.

[CHH] As I said in my second question, ICE does allow for the case where there is no candidate attribute, and from the receivers perspective this would be such case, wouldn't it? But, if there are no candidate attributes, how does the receiver know that the sender supports ICE? Is there an option tag, or someting? Or, is it assumed that the other ICE related attributes (ice-pwd) are still present, to indicate the support of ICE?

>updated offer and they can't find a matching candidate pair int he right

[CHH] Is there a reason why the m/c-lines couldn't be used for validation - at least in the case when there is no matching candiate?
 
Regards,
 
Christer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 25 Jun 2006 21:27:11 -0400

inline.

Christer Holmberg (JO/LMF) wrote:

> Hi,
> 
> 
>>>> 1.      What happens if the c/m lines does not correspond to
>>>> any active a=candidate line? This could happen e.g. if you have
>>>> a SDP modifying B2BUA (which doesn't support ICE) in the path.
>>>> One option would be to say that the connectivity check shall be
>>>> performed also for the c/m lines in that case, but then we may
>>>> need a "default priority", or something...
>>>> 
>>> 
>>> For example, would the a-candidate lines still be present? Would
>>> they be modified by the B2BUA? Can you cite the behavior of some
>>> known products that do this?
> 
> 
> [CHH] I would assume that one could find products behaving in either
> way. IF the B2BUA removes the candiate attributes I guess we'll get
> the scenario described in my second question.
> 
> 
>> I had the same question. Of course, the problem is that since a
>> b2bua is entirely undefined its not claer what it will do. But, I
>> think we are safe in assuming its one of two things:
>> 
>> Lets look at what happens in each of these cases. Case 2 is the
>> easiest. Both agents will think that the other side doesn't support
>> ICE, and fallback to regular non-ICE behavior. So, things work as
>> one would expect.
> 
> 
> [CHH] As I said in my second question, ICE does allow for the case
> where there is no candidate attribute, and from the receivers
> perspective this would be such case, wouldn't it? 

Yes.

> But, if there are
> no candidate attributes, how does the receiver know that the sender
> supports ICE? 

It won't. This is the point. In case (2), each side will conclude that 
the other doesn't support ICE.

> Is there an option tag, or someting? Or, is it assumed
> that the other ICE related attributes (ice-pwd) are still present, to
> indicate the support of ICE?

candidate attributes are the indicator. There is no option tag. There is 
no need.

> 
> 
>> In case 1, with the current specification this will break badly.
>> Because the m/c-line never appears as a candidate, the agents will
>> never send media to it since it never validates. The way to fix
>> this would be to change ice-09 to say that, if an agent doesn't see
>> a cndidate for the m/c-line, it CAN send media to it without
>> validating (kind of makes sense). Agents would also need to deal
>> with cases where they get an updated offer and they can't find a
>> matching candidate pair int he right state.
> 
> 
> [CHH] Is there a reason why the m/c-lines couldn't be used for
> validation - at least in the case when there is no matching candiate?

Yes. There are actual use cases where an endpoint cannot mux STUN and 
RTP on the same port, in which case you could elect never to try and 
validate whats currently in use on the m/c-line.

The other problem is that you need more than an IP/port to do the stun 
validations. You need usernames, passwords, and several other 
parameters. Several (like username/password) are difficult and dangerous 
to try and derive algorithmically rather than signal.

-Jonathan R.

---

From: Philip Matthews <[email-masked]>
Date: Mon, 26 Jun 2006 14:04:18 -0400

On 25-Jun-06, at 21:27 , Jonathan Rosenberg wrote:

>>> 1. it modifies the m/c-lines but leaves the a=candidate  
>>> attributes 2. it modifies the m/c-lines and removes all unknonwn  
>>> attributes, including a=candidate attributes
>> [CHH] Correct.
> It won't. This is the point. In case (2), each side will conclude  
> that the other doesn't support ICE.
>
>
> candidate attributes are the indicator. There is no option tag.  
> There is no need.
>
> Yes. There are actual use cases where an endpoint cannot mux STUN  
> and RTP on the same port, in which case you could elect never to  
> try and validate whats currently in use on the m/c-line.
>
> The other problem is that you need more than an IP/port to do the  
> stun validations. You need usernames, passwords, and several other  
> parameters. Several (like username/password) are difficult and  
> dangerous to try and derive algorithmically rather than signal.
>

Is it really that hard? I can think of ways to handle it. (E.g.,  
require endpoints
to always provide a password for the entire media-stream, and always  
provide
a "default" candidate id which is used if the m/c line does not match  
a candidate).
In some ways, this is similar to the way ICE-08 handles peer- 
reflexive candidates.

The only thing I am not complete sure of is: Is it worth it? But  
perhaps the goal is
to try to make ICE work in as many cases as possible, in which case  
the  answer
is probably "Yes".

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Jun 2006 15:53:26 -0400

inline.

Philip Matthews wrote:

> a "default" candidate id which is used if the m/c line does not match  a 
> candidate).
> In some ways, this is similar to the way ICE-08 handles peer- reflexive 
> candidates.
> 

Generally, I agree with you. But this is a different case. This is the 
case where there is a b2bua that is stomping on the m/c-lines, because 
it wants to be in the way. I don't want to turn ICE into a protocol that 
purposefully bypasses service provider b2buas. If such a box gets in the 
way, ICE should fall back to normal usage without ICE. If the b2bua 
becomes ICE aware then the provider can do what it wants.

-Jonathan R.

---

From: Philip Matthews <[email-masked]>
Date: Mon, 26 Jun 2006 17:19:06 -0400

See below.

On 26-Jun-06, at 15:53 , Jonathan Rosenberg wrote:

>>> Yes. There are actual use cases where an endpoint cannot mux  
>>> STUN  and RTP on the same port, in which case you could elect  
>>> never to  try and validate whats currently in use on the m/c-line.
>>>
>>> The other problem is that you need more than an IP/port to do  
>>> the  stun validations. You need usernames, passwords, and several  
>>> other  parameters. Several (like username/password) are difficult  
>>> and  dangerous to try and derive algorithmically rather than signal.
>>>
>> to always provide a password for the entire media-stream, and  
>> always  provide
>> a "default" candidate id which is used if the m/c line does not  
>> match  a candidate).
>> to try to make ICE work in as many cases as possible, in which  
>> case  the  answer
>> is probably "Yes".
>
> Generally, I agree with you. But this is a different case. This is  
> the case where there is a b2bua that is stomping on the m/c-lines,  
> because it wants to be in the way. I don't want to turn ICE into a  
> protocol that purposefully bypasses service provider b2buas. If  
> such a box gets in the way, ICE should fall back to normal usage  
> without ICE. If the b2bua becomes ICE aware then the provider can  
> do what it wants.
>

Jonathan:
Are you saying that you want the media to always go via the B2BUA in  
this case (= the B2BUA acts as a form of relay server)?
Or am I misunderstanding your comment?

I guess my broader question is: Why is the box in the middle  
modifying the  m/c line?
I could postulate a number of reasons why (e.g. helping with NAT  
traversal, trying to impose policy, trying to provide some other  
service, etc).
Which ones do we think are valid and want to support?

- Philip