Subject: Re: [MMUSIC] Interworking ICE/SBC

From: <[email-masked]>
Date: Tue, 10 Oct 2006 13:44:37 +0100 (BST)

The problem here goes back to the old question of what the ICE UA chooses as it's initial "in use" candidate (i.e. puts in m/c line). If it were a relayed candidate, then if symmetric RTP is enforced, then it has to ensure it sends from this address. This means via the relay. So even if the ICE UA drops to non-UA behaviour it will have to send via it's relay, which is non optimal. Even worse, if the UA and the network device requiring to take the media (probably not a Service Providers SBC but other enterprise policy device) are co-located. Then media connectivity may fail (as media may go out of a firewall via the relay and then fail when trying to comeback in, in native form) .

If I'm correct,I believe this is where the discussions about "ICE and open Internet devices" come into play. In this case SBCs would always appear to ICE UAs as a fellow ICE client, but only advertising it's interface as the only candidate. Ensuring the only path discovered by the ICE UA will be towards the SBC and maybe the most optimal (if ICE candidate checks complete fully). This discussion also introduces the concept of a "passive" client, which reduces the implementation complexity required (SBC may only have to respond to connectivity checks and also not have to re-invite).  

Cheers,

Pete L.

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 10 October 2006 13:04
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Interworking ICE/SBC

Hi,

> In this example, when a user (with UA supporting ICE) intitiates a call,
>  the UA and the SBC on the path are attempting to change the SIP
> messages  (in particular the SDP) for NAT traversal. But, for the
> moment, it  results in an unpredictable behavior for NAT traversal.

>From my point, this  looks like a problem of the SBC. ICE is defined to be
compatible with UAs not supporting ICE. If the SBC does not have a
strategy how to cope with ICE it should ignore it. Than the UA will
fallback to normal (non-ICE) behaviour.

regards
Franz

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 11 Oct 2006 13:21:15 -0400

inline.

[email-masked] wrote:

> 
>     The problem here goes back to the old question of what the ICE UA
>     chooses as it's initial "in use" candidate (i.e. puts in m/c line).
>     If it were a relayed candidate, then if symmetric RTP is enforced,
>     then it has to ensure it sends from this address. This means via the
>     relay. So even if the ICE UA drops to non-UA behaviour it will have
>     to send via it's relay, which is non optimal. 

Whether this happens depends on the configuration of the SBC.

Consider the proposal I made on the list on how to handle SBCs (this 
whole bit about inserted candidates). If the SBC is in the 'latching' 
mode, whereby it learns the target for relaying media based on the 
source IP/port of the RTP rather than the m/c-line of the SDP, 
everything works fine. The algorithm I described will end up quickly 
validating, on each side, the pair formed by combining the host 
candidate with the addresses added by the SBC. The STUN exchanges will 
indicate that these SBC addresses are inserted. Consequently, there 
won't normally even be a re-invite; media will simply flow from the host 
candidate on each agent, to the SBC, towards the remote agent. The TURN 
servers, though their addresses appeared in the m/c-lines, never see any 
media traffic and are never used. Media operation is still symmetric as 
far as the SBC is concerned, but its symmetric because of the 'latching' 
implemented by the SBC.

If, on the other hand, the SBC is configured to insert itself into the 
media path, but otherwise honor the contents of the SDP, its more 
interesting. If the SBC requires symmetric RTP (it discards any packets 
not coming from the IP/port in the m/c-line), the STUN checks will 
proceed and the only candidate pairs that work are the ones from the 
TURN server to the SBC. This too will not require a re-invite, but will 
result in the ugly case of THREE relays (and possibly four) - the SBC 
(two SBCs if each side has one), and two TURN servers.

If the SBC doesn't require symmetric RTP and will accept media 
(including STUN) from anywhere but otherwise relay it towards what was 
provided in the m/c-line, its really interesting what happens. You'll 
end up using the SBCs and only ONE of the two TURN servers (a different 
one in each direction).

So the lesson of this is, if you have an SBC in a network with ICE 
endpoints, you need to configure the SBC to operate in latching mode (at 
least towards the ICE-capable devices). I believe most do this as the 
normal mode of operation.

>     Even worse, if the UA
>     and the network device requiring to take the media (probably not a
>     Service Providers SBC but other enterprise policy device) are
>     co-located. Then media connectivity may fail (as media may go out of
>     a firewall via the relay and then fail when trying to comeback in,
>     in native form) .

I dont follow this. Can you describe the topology in more detail?

> 
>     If I'm correct,I believe this is where the discussions about "ICE
>     and open Internet devices" come into play. In this case SBCs would
>     always appear to ICE UAs as a fellow ICE client, but only
>     advertising it's interface as the only candidate. Ensuring the only
>     path discovered by the ICE UA will be towards the SBC and maybe the
>     most optimal (if ICE candidate checks complete fully). This
>     discussion also introduces the concept of a "passive" client, which
>     reduces the implementation complexity required (SBC may only have to
>     respond to connectivity checks and also not have to re-invite). 

You are talking now about something different, which is ICE-capable 
SBCs. There are many, many ways to build such devices, and since the SBC 
is ICE aware it can be done in a way where the overall right thing 
happens. That is not the case I'm considering, which is ICE-unaware SBCs.

-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: Peter Livesey <[email-masked]>
Date: Thu, 12 Oct 2006 09:42:00 +0100 (BST)

I actually sent this mail before your new 'inserted'
candidates proposal. Posting of it to the list was
delayed due to an administrative error on my part
(posting prior to registering this mail address with
list) Doh! ;-) . 
I was trying to describe possible problems I thought
may happen, when a SBC/ALG changed the m/c line and
the ICE UAs policy on detecting this was to process
based on RFC3264 (Draft 10). Sorry for the confusion.

The scenario I depict is one where an ICE UA within an
enterprise initiates a call. It has selected
candidates including a relayed candidate. The UA picks
 the relayed candidate as being in-use. A network
device within the enterprise (maybe private side of
ALG/SBC or a Proxy running a Policy Engine), requires
to take the media. In order to do so it changes the
m/c line of the SDP. On receiving the SDP answer the
UA detects the m/c line has been changed and therefore
has to fall back to RFC 3264.

So the situation we have here is a UA inside an
enterprise trying to send media to an internal
address, via a relay. So the media is leaving the
enterprise, travelling through the relay which will
then try to forward the media onto an address back
inside the enterprise. This is highly unlikely to
succeed. 

There are ways this could have been avoided. UA
selection of 'in-use' candidate, based on some
pre-configured awareness of it's location. The network
device being ICE aware and now your new proposal
(assuming said device doesn't enforce symetric RTP
based on m/c line).

Once again sorry for the confusion.

Cheers,

Pete L.