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

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 30 Jun 2006 09:30:39 +0200

Hi, 

>>>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?
>>
>>For the scenario we're discussing, I am not sure we need to care about

>>WHY the c/m lines are modified. I think it's enough that we assume 
>>that media sent towards the c/m address will reach the other user 
>>(otherwise there is something wrong in the network).
>
>
>Sorry to be slow in replying.
>If I understand this, then what you are saying is the following:
>
>    If endpoint X receives an offer or answer containing one or more
>    a-candidate lines, but where the address and port in the m/c line
>    is NOT one of the candidates listed, then the endpoint should
simply
>    assume that sending media to the address in the m/c line will work.

What I am saying is that when a client receives a c/m line (even if it
has been modified by a B2BUA or not) it can generally be assumed that
media sent towards that address will reach the remote user. That has
nothing to do with ICE.

But, the question is how a client supporting ICE should interpret this.

>Question:
>Should endpoint X perform connectivity checks, or should it just assume
that the m/c line represents the most desirable path?

That's the question :)

One proposal was that the client should perform connectivity check also
on the c/m line, but I think Jonathan in one e-mail said that won't
work.

Regards,

Christer

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

---

From: Philip Matthews <[email-masked]>
Date: Fri, 30 Jun 2006 16:07:15 -0400

> on the c/m line, but I think Jonathan in one e-mail said that won't

My colleague Eric Cooper and I thought a bit about this and came up  
with the following.

Why is the box in the middle  changing the m/c lines?
In our opinion, either:
1a)  It is trying to help with NAT traversal, OR
1b)  It is trying to force the packets to flow through it.

Also, the box is either:
2a) not ICE aware, OR
2b) is ICE aware.

Consider first the combination of (1a) and (2a) -- for example,
a box trying to help with NAT traversal that is not ICE aware.
In this case, the modified m/c line provides an alternative transport  
address.
This address may work, or it may not, depending on the network  
situation.
So it seems best if ICE consider this another candidate  and try to  
validate it.
To do this, each endpoint could, for example, include "default"  
candidate ids and passwords
in the offer or  answer that would be used by the remote end if the m/ 
c line gets changed.

Now consider the  combination (1a) and (2b) -- a box trying to help with
NAT traversal that is ICE aware. Here the solution of the previous  
paragraph still
works, and Eric and I could not think of anything better that an ICE- 
aware box could do.

Next, consider the combination (1b) and (2b) - an ICE-aware box that  
is trying to
force the media to flow through it.  In this case, the box can simply  
delete all the ICE-related
lines from the SDP, and the remote end will fall back to non-ICE  
behavior,
which will cause all traffic to flow through the box.

Finally, consider the combination (1b) and (2a) - a non-ICE aware box  
that is trying
to force media to flow through it. In this case ... well ... the  
endpoints, not realizing that
the box wants to be in the media path, will try other paths. If one  
of these succeeds,
then the box will be bypassed. Otherwise, if only the modified m/c  
transport address works,
then the media will flow through the box.  If this is not the desired  
behavior, well,
just upgrade the box to an ICE-aware version!

- Philip