Subject: RE: [Sipping] Draft: Functions of Current SBCs

From: "Bharrat, Shaun" <[email-masked]>
Date: Fri, 18 Feb 2005 10:48:47 -0500

Marc:

> > SBC implementations out there currently "solve" the NAT 
> problem without
> > requiring any special support from the IAD (there are some 
> IAD requirements
> > such as symmetric signaling and RTP but leaving those out). 
> How does ICE, 
> > STUN, etc solve the NAT traversal problem in this manner -- 
> don't they all
> > require active participation on the part of the IAD?
> 
> This is supposed to be a good thing. We need better endpoints, not 
> crutches for broken endpoints.

No one is arguing against the notion that in a perfect world, we 
have "good" endpoints. Take the argument further and everything should
be fixed so that there is no need for NAT. Realistically, NAT is
going to be around for a long time, there will IADs that don't support
STUN and ICE, and customers will want to nevertheless support these
NAT'd IADs. This is one of the functions currently provided by SBCs.

Cheers,
Shaun

> -----Original Message-----
> From: Marc Petit-Huguenin [mailto:[email-masked]]
> Sent: Friday, February 18, 2005 10:31 AM
> To: Bharrat, Shaun
> Cc: Arjun Roychowdhury; Jani Hautakorpi; sipping
> Subject: Re: [Sipping] Draft: Functions of Current SBCs
> 
> 
> Bharrat, Shaun wrote:
> > Arjun:
> > 
> > Not agreeing or disagreeing about what this draft should be; just
> > have a question on the following statement...
> > 
> > 
> >>As an example, a thread above stated that the primary 
> objective of an
> >>SBC is NAT traversal. If that were true, then the work is 
> already done
> >>:-) - we have ICE, STUN and the rest of the group.
> >>
> > 
> > 
> > SBC implementations out there currently "solve" the NAT 
> problem without
> > requiring any special support from the IAD (there are some 
> IAD requirements
> > such as symmetric signaling and RTP but leaving those out). 
> How does ICE, 
> > STUN, etc solve the NAT traversal problem in this manner -- 
> don't they all
> > require active participation on the part of the IAD?
> 
> This is supposed to be a good thing. We need better endpoints, not 
> crutches for broken endpoints.
> 
> > 
> > Thanks and cheers,
> > Shaun
> > 
> > 
> > 
> 
> -- 
> Marc Petit-Huguenin
> Home: [email-masked]
> Professional: [email-masked]
> Work: [email-masked]
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: David R Oran <[email-masked]>
Date: Fri, 18 Feb 2005 12:19:48 -0500

> NAT'd IADs. This is one of the functions currently provided by SBCs.
I agree, since we are not debating what would be "better" than an SBC 
but rather what they are deployed to do *and why*. Note that the why 
and the what are equally important and it's critical to connect the two 
or we won't be able to sort through the design or requirements space 
later on. Where I got off the boat with these drafts was the implicit 
scoping to just about any function in the universe, whether or not it 
required violating one of more of the SIP "architectural rules". 
Clearly you could provide SOME kind of service by chaining together a 
bunch of B2BUAs, but we've already have a different architectural model 
for that - it's called the PSTN.

I'll issue one more plea to try to look at this in terms of things SBCs 
do that violate one or more of the precepts I mentioned in an earlier 
message (which is not by any means a complete set). We aren't debating 
whether those things happen or not, or just how bad they are, and 
whether there are better alternatives to breaking the rules at this 
stage. What I do debate is claiming as SBC functions things that normal 
SIP proxies or other SIP servers can do without breaking the rules.

Remember, we wouldn't even be having this thread if the SBCs weren't 
doing things that break the rules.

Dave.

>> crutches for broken endpoints.
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]