Subject: [MMUSIC] Interworking ICE/SBC

From: [email-masked]
Date: Tue, 10 Oct 2006 12:22:56 +0200

Hello all,

We identified technical issues related to the deployment of SIP services 
within NATed networks when ICE and SBC are used simultaneously for NAT 
traversal. Thus, we would like to have the opinion from the MMUSIC/SIP 
community about the subject and the best way to solve these issues?

Here is the point:
We consider that users (and their SIP terminals) are using a NATed IP 
address.
The SIP Service Provider of the users may be different from the ISP of 
the users.
Two approaches for NAT traversal are deployed :
On one side, ICE is deployed partly on some UAs.
On the other side, a Session Border Controller (SBC) deployed as the 
proxy for NAT traversal.

For instance, the service provider have a SBC already deployed and it 
wants to introduce new terminals with ICE (for inst: to avoid some media 
flows to go through its network).
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. Depending on the 
SBC implementation, the call may be rejected, accepted with no working 
media, or even accepted with media streams being relayed on multiple 
successive media relays. In both cases, the result is less optimal than 
for a single solution (ICE or SBC).
This is why we would like to discuss the best way to make ICE actually 
work, even if a SBC is on the path.
Please note that this point also applies with 2 users located in 
different domains.
Your opinion is welcome.

Sincerely,

Thomas LEVY & Thomas FROMENT

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

---

From: <[email-masked]>
Date: Tue, 10 Oct 2006 14:03:46 +0200 (CEST)

Hi,

>  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

---

From: [email-masked]
Date: Tue, 10 Oct 2006 17:18:18 +0200

Hi Franz,

I agree that it is mainly the responsability for the SBC to determine 
that for instance it should not modify ICE processing.
However,  for the moment, SBCs are simply not aware of  ICE!!!
Thus, we could imagine a mechanism that allows SBC to detect that a 
terminal uses ICE (even if the sdp is encrypted ;-) )

Thomas

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 10 Oct 2006 10:57:35 -0700

Could you please clarify what you mean by SBC in this case. Do you  
mean a B2BUA with a media relay?

On Oct 10, 2006, at 3:22 AM, [email-masked] wrote:

> Hello all,
>
> We identified technical issues related to the deployment of SIP  
> services within NATed networks when ICE and SBC are used  
> simultaneously for NAT traversal. Thus, we would like to have the  
> opinion from the MMUSIC/SIP community about the subject and the  
> best way to solve these issues?
>
> Here is the point:
> We consider that users (and their SIP terminals) are using a NATed  
> IP address.
> The SIP Service Provider of the users may be different from the ISP  
> of the users.
> On the other side, a Session Border Controller (SBC) deployed as  
> the proxy for NAT traversal.
>
> For instance, the service provider have a SBC already deployed and  
> it wants to introduce new terminals with ICE (for inst: to avoid  
> some media flows to go through its network).
> 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. Depending on the SBC implementation, the call may be  
> rejected, accepted with no working media, or even accepted with  
> media streams being relayed on multiple successive media relays. In  
> both cases, the result is less optimal than for a single solution  
> (ICE or SBC).
> This is why we would like to discuss the best way to make ICE  
> actually work, even if a SBC is on the path.

---

From: [email-masked]
Date: Wed, 11 Oct 2006 11:44:20 +0200

> mean a B2BUA with a media relay?

Yes a B2BUA used to relay the media flows for NAT traversal.
In this case, the SBC is used for (hosted) NAT traversal but not for 
Access Control.

Thomas

>> opinion from the MMUSIC/SIP community about the subject and the  best 
>> way to solve these issues?
>>
>> Here is the point:
>> SIP messages (in particular the SDP) for NAT traversal. But, for  the 
>> Depending on the SBC implementation, the call may be  rejected, 
>> accepted with no working media, or even accepted with  media streams 
>> being relayed on multiple successive media relays. In  both cases, 
>> the result is less optimal than for a single solution  (ICE or SBC).

---

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

> fallback to normal (non-ICE) behaviour.

So, this is what happens in ICE-10. If there is an intermediate SBC the 
UA falls back to normal non-ICE behavior. The issue that was raised (and 
its a good one), is that this will typically result in three or even 
four media relays on the call - the originating TURN server, originating 
SBC, terminating TURN server, terminating SBC. This is because 'normal' 
non-ICE processing would be to use the m/c-line which contains a TURN relay.

Per my other note, this is fixed by my proposal, which would end up 
using only the SBC relays in these cases.

-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