Subject: [MMUSIC] ICE and signalling media path

From: "Derek MacDonald" <[email-masked]>
Date: Mon, 25 Sep 2006 14:04:45 -0700

There seem to two camps in this debate:

1.) Ice should enable two endpoints to communicate; essentially determine
which media path will work with minimal offer/answer exchanges

2.) Endpoints must signal the path that media traffic will follow
(signaling), and must use this path once it is signaled.

I think if we weaken requirement two to 'should' in some conditions we have
the following requirements:

1.) Ice must enable two endpoints to communicate with one offer/answer
exchange

2.) Endpoints must signal their decision to the network to the best of their
ability

Requirement one arises from existing networks and deployments; it is not
driven by a gap in the standards.  While TLS will solve the hotel ALG
problem, we are at least a year from a widespread deployment of TLS.  All of
the solutions proposed to satisfy requirement 1 require the endpoints to
ignore the m/c line under some circumstances.  This is at odds with
requirement 2 where off-path/midcom devices require media traffic details.

I propose we limit the scope of requirement 1 to the case where the m/c line
will not match a validated ice candidate. The consequent behavior would be:

1. The endpoints will inform the network, to the best of its ability, the
media path that will be used for RTP.

2. The m/c line will not match a validated ice candidate if:

            1.) there is an ICE unaware SBC/ALG in the network

            2.) the network has been designed so that the endpoints has no
control over the media path; this includes networks that add media paths
without informing the network.

If a network does not wish endpoints to control, or *be aware of*, the media
path it does not match the endpoint-centric SIP architecture. If a device,
such as an SBC, wishes to violate this principle it must remove/manipulate
ice candidates from an SDP and appear as the originating endpoint to the
receiver of the offer.

This principle of topology-hiding is the crux if the argument.  The "m/c
line not matching a valid ICE candidate" situation cannot occur if the
network is composed of standards-compliant devices.  If and only if this
situation arises, an endpoint should fall back on information it has
acquired from the target destination, namely the ice-discovered media paths.

This approach will allow us to leverage ICE in existing problem deployments,
while allowing standards-based networks complete control. 

Thoughts?

-Derek

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Sep 2006 10:40:03 -0400

I'm not sure I agree here.

I think a lot of benefits are afforded by using the IP addresses and 
ports that are eventually signaled in the m/c-line. Its not just dealing 
with 'bad' SBCs along the signaling path that don't understand ICE (and 
none of the currently do), its also dealing with devices that install or 
negotiate QoS, devices that monitor voice quality, and so on. SIP/SDP 
has the property today that the m/c-line is the one and only place that 
indicates the IP addresses and ports for media, and lots of things rely 
on that contract being true. If we break that, and say that the m/c-line 
is ultimately not the source of truth, but rather its something else 
negotiated out of band, we change the behavior that so much of this 
other infrastructure has come to depend on.

Consequently, I believe we should stick with the design as in the 
current ICE and previous versions, where when an updated offer/answer 
comes, you use whatever is in the m/c-lines even if it differs from what 
you determined from ICE.

-Jonathan R.

Derek MacDonald wrote:

> 1.) Ice should enable two endpoints to communicate; essentially 
> determine which media path will work with minimal offer/answer exchanges
> 
> I think if we weaken requirement two to ‘should’ in some conditions we 
> have the following requirements:
> 
>  
> 
> 2.) Endpoints must signal their decision to the network to the best of 
> their ability
> 
>  
> 
> problem, we are at least a year from a widespread deployment of TLS.  
> All of the solutions proposed to satisfy requirement 1 require the 
> endpoints to ignore the m/c line under some circumstances.  This is at 
> odds with requirement 2 where off-path/midcom devices require media 
> traffic details.
> 
>  
> 
> I propose we limit the scope of requirement 1 to the case where the m/c 
> line will not match a validated ice candidate. The consequent behavior 
> would be:
> 
>  
> 
> 1. The endpoints will inform the network, to the best of its ability, 
> the media path that will be used for RTP.
> 
>  
> 
>             2.) the network has been designed so that the endpoints has 
> no control over the media path; this includes networks that add media 
> paths without informing the network.
> 
>  
> 
> If a network does not wish endpoints to control, or *be aware of*, the 
> media path it does not match the endpoint-centric SIP architecture. If a 
> device, such as an SBC, wishes to violate this principle it must 
> remove/manipulate ice candidates from an SDP and appear as the 
> originating endpoint to the receiver of the offer.
> 
>  
> 
> This approach will allow us to leverage ICE in existing problem 
> deployments, while allowing standards-based networks complete control.
> 
>  
> 
> Thoughts?
> 
>  
> 
> -Derek
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 

-- 
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: Philip Matthews <[email-masked]>
Date: Tue, 26 Sep 2006 11:47:49 -0400

Derek:

Do I understand your message correctly as meaning that you want to  
reopen the debate
on what to do in the situation when the received offer or  answer  
contains
an address in the m/c line that does not match the address of a  
candidate
in the a=candidate lines?

- Philip

On 25-Sep-06, at 17:04 , Derek MacDonald wrote:

> I think if we weaken requirement two to ‘should’ in some conditions  
> we have the following requirements:
>
>
>
> 1.) Ice must enable two endpoints to communicate with one offer/ 
> answer exchange
>
> 2.) Endpoints must signal their decision to the network to the best  
> of their ability
>
>
>
> Requirement one arises from existing networks and deployments; it  
> is not driven by a gap in the standards.  While TLS will solve the  
> hotel ALG problem, we are at least a year from a widespread  
> deployment of TLS.  All of the solutions proposed to satisfy  
> requirement 1 require the endpoints to ignore the m/c line under  
> some circumstances.  This is at odds with requirement 2 where off- 
> path/midcom devices require media traffic details.
>
>
>
> I propose we limit the scope of requirement 1 to the case where the  
> m/c line will not match a validated ice candidate. The consequent  
> behavior would be:
>
>
>
> 1. The endpoints will inform the network, to the best of its  
> ability, the media path that will be used for RTP.
>
>
>
>             2.) the network has been designed so that the endpoints  
> has no control over the media path; this includes networks that add  
> media paths without informing the network.
>
>
>
> If a network does not wish endpoints to control, or *be aware of*,  
> the media path it does not match the endpoint-centric SIP  
> architecture. If a device, such as an SBC, wishes to violate this  
> principle it must remove/manipulate ice candidates from an SDP and  
> appear as the originating endpoint to the receiver of the offer.
>
>
>
> This principle of topology-hiding is the crux if the argument.  The  
> "m/c line not matching a valid ICE candidate" situation cannot  
> occur if the network is composed of standards-compliant devices.   
> If and only if this situation arises, an endpoint should fall back  
> on information it has acquired from the target destination, namely  
> the ice-discovered media paths.
>
>
>