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

From: Eric Burger <[email-masked]>
Date: Fri, 4 Mar 2005 18:11:02 -0500

I used to subscribe to this point of view.  For that matter, Brooktrout has
a product that addresses such IAD problems (DTMF<->RFC2833 transcoding).

However, silicon economics still makes the "right architecture" better than
the "expedient architecture."

Why?  Because today's IAD costs less than $10 to produce.  Go to your local
office supply store, and you can pick one up for under $40.

I would offer that declaring a handful of IADs obsolete, or at least won't
work with your obsolete NAT, is infinitely better than declaring the
Internet dead and recreating the PTT with packets.

For that matter, NATs are literally free.  In the U.S., Staples often has
rebates equal to the purchase price with no strings attached.

So, no, I do not see any reason to officially sanction a hack to correct a
bad implementation.  All we will do is make it that much harder to get back
to the Internet architecture.

Does this mean it would be "illegal" to deploy something like an SBC to
"fix" a bad implementation?  Of course not.  A B2BUA is a B2BUA.  So long as
it conforms to RFC3261, and the service provider or IT department doesn't
mind being locked out of offering Internet services, then go for it.  One
would hope that over time economics will force the issue one way or the
other.  It just happens that economics does NOT always favor the SBC
approach.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Bharrat, Shaun
> Sent: Friday, February 18, 2005 10:49 AM
> To: Marc Petit-Huguenin
> Cc: sipping
> Subject: RE: [Sipping] Draft: Functions of Current SBCs
> 
> 
> 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
> 

_______________________________________________
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: "Medhavi Bhatia" <[email-masked]>
Date: Wed, 9 Mar 2005 22:29:43 -0500

> other.  It just happens that economics does NOT always favor the SBC

I am pretty convinced that interoperability is *NOT* an SBC function per se.
It is merely an overload. You can always extract it out and put that in
another element in the network. Security *IS* going to be the single most
driver for these boxes and the requirements they claim to solve. I did
mention (in another email) the resemblance between some of the IDSs which
claim to do almost everything which SBCs do today (with certain limitations
- like the inability to handle encrypted sessions). I forsee these two boxes
will probably combine/integrate.

-Medhavi.