Subject: Re: [MMUSIC] ICE-12, SBCs and hotel ALGs

From: Cullen Jennings <[email-masked]>
Date: Thu, 2 Nov 2006 21:43:09 -0800

On Oct 26, 2006, at 2:39 PM, Jonathan Rosenberg wrote:

> My main rationale on the first piece of this (if m/c-line doesnt  
> match a candidate, abort) is that we dont know what SBCs will or  
> won't do. Their behaviors are not specified, and they are highly  
> variable. If the purpose of ICE is to make voip *reliable*, then  
> the most reliable thing is to abort ICE processing and go with the  
> relays.

I'm not really commenting on the topic of if I personal like the way  
ICE is here or think it should be different, but I do think we need  
to keep in mind a general principle here that has the potential to  
impact the design of all future SIP specifications.

I disagree that SBC are not well defined - I think it is clear that  
in a B2BUA, each side has to  act as a valid UA. That provides a lot  
of definition - I know that is still might leave something open but I  
suspect that it closes all the issues that are relevant here. I  
understand new specifications might bring to light bugs in existing  
UAs - however, in most cases these bugs can be fixed long before the  
new specification achieves any significant rollout.

The next thing is the idea that we need to design to work with for  
SIP devices that are in the signaling, and have behavior that is not  
specified, we don't know what it is , and that behavior is highly  
variable. This is clearly impossible. I don't think that we as a  
standards organization can function with this constraint. There will  
be no way to decide what may be a reasonable bug to try and  
interoperate with (say sending a BYE when you should have a CANCEL)  
and what would be ridiculous (headers translated form ascii to  
ebcdic). I think we need to design to be compatible (and hopefully  
backwards compatible) with compliant SIP UAs.

On the topic of ICE, this argument cuts both ways and applies towards  
broken hotel ALGs too.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Nov 2006 20:44:03 -0500

Well if the behavior of a b2bua is truly two back-to-back UAs (though 
its really not), then ICE would clearly not run, since it only runs only 
when both sides support it.

But I disagree that its well-defined as two back-to-back UAs, since they 
also mimick some of the proxy behaviors of passing parameters through 
that they don't understand. No UA that doesn't support ICE would ever 
emit an SDP with candidate lines, yet an SBC that doesn't understand ICE 
will.

-Jonathan R.

Cullen Jennings wrote:

>> variable. If the purpose of ICE is to make voip *reliable*, then  the 
>> most reliable thing is to abort ICE processing and go with the  relays.
> 
> 
> ICE is here or think it should be different, but I do think we need  to 
> keep in mind a general principle here that has the potential to  impact 
> the design of all future SIP specifications.
> 
> I disagree that SBC are not well defined - I think it is clear that  in 
> a B2BUA, each side has to  act as a valid UA. That provides a lot  of 
> definition - I know that is still might leave something open but I  
> understand new specifications might bring to light bugs in existing  UAs 
> - however, in most cases these bugs can be fixed long before the  new 
> specification achieves any significant rollout.
> 
> The next thing is the idea that we need to design to work with for  SIP 
> devices that are in the signaling, and have behavior that is not  
> standards organization can function with this constraint. There will  be 
> no way to decide what may be a reasonable bug to try and  interoperate 
> with (say sending a BYE when you should have a CANCEL)  and what would 
> be ridiculous (headers translated form ascii to  ebcdic). I think we 
> need to design to be compatible (and hopefully  backwards compatible) 
> with compliant SIP UAs.
> 

-- 
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: "Hadriel Kaplan" <[email-masked]>
Date: Sat, 4 Nov 2006 12:36:41 -0500

What it really is, is a question of what ICE should do when the other UA is
not following ICE correctly.  A UAC sent an offer with ICE candidates, the
UAS responded in a non-ICE way.  Do you keep doing ICE procedures as if the
other side was acting normal, or do you believe that it's not doing ICE
right and go back to pre-ICE-age (Eemian era?).

-hadriel

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, November 03, 2006 8:44 PM
> To: Cullen Jennings
> Cc: IETF MMUSIC WG
> Subject: Re: [MMUSIC] ICE-12, SBCs and hotel ALGs
>