Subject: [Sipping] Draft: Functions of Current SBCs

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 15 Feb 2005 14:42:29 +0200

Folks,

in the ad-hoc on SBCs we organized  in DC, we agreed to put together a 
small team to write document describing the functions performed by 
current SBCs and the SIP principles that were broken by these SBCs. This 
list of functions was to be taken by the IETF as input to decide whether 
new mechanisms are needed to implement those functions in a more 
architecturally friendly way.

We have tried to avoid talking about requirements, because this term was 
confusing a lot of people. Taking these functions as input, the IETF may 
develop requirements to work on different solutions (e.g., adding 
requirements to session policies), but the functions themselves are not 
requirements at this point.

Until it appears in the archives, you can fetch the draft from:

http://users.piuha.net/gonzalo/temp/draft-camarillo-sipping-sbc-funcs-00.txt

There have already been discussions on some of these issues in the 
mailing list in the last weeks, but discussions would be appreciated.

Comments are welcome,

Gonzalo

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Feb 2005 10:23:26 -0500

A couple of clarifying questions:

- Topology hiding:

There are certain instances of addresses that are always mentioned when 
discussing topology hiding. (Record-Route, Via, Contact, as well as the 
media address(es)). But there are many other well known and not so well 
known places where addresses may appear. Well known ones would include 
Refer-To, To, From, Alert-Info, Error-Info, and perhaps the e= field in 
sdp. Less well known ones would include sip extension headers in the 
message, as well as addressed embedded in body parts, such as sipfrags.

How much of this does topology hiding typically deal with? In 
particular, are SBCs stripping extension headers unknown to them on the 
chance that they might contain an address that should be hid?

- Deployment Scenarios

In scenarios such as 4.1, *how* is the SBC being involved in the call? 
Is this a matter of provisioned configuration in the peer, the use of 
SRV records, or what?

	Thanks,
	Paul

---

From: Arjun Roychowdhury <[email-masked]>
Date: Tue, 15 Feb 2005 10:54:55 -0500

Gonzalo,
Thanks for posting.

For the 'SBC-Challenged' folks, is this effort related to medhavi's
requirement document (a pre-cursor, maybe ?). Also, based on the
discussions that followed the requirement document, some other
functionalities surfaced related to common SBC usage, one of which was
transcoding . The other was the use of SBCs for privacy of identities
(not sure if that can be lumped into THIG)

I don't see that mentioned in the functionality of this draft. I may
have missed others.

In addition, there was a large debate in the previous thread on where
exactly is THIG applicable and what it encapsulates/means. I dont
think there is any discussion on that too.

I am not sure if your aim is to clarify functionality as well as scope
of the functionality (which is missing in parts) in this document.

Since both of the drafts were posted with the statement that this was
an outcome of the DC meeting, I would like to know which forms the
base for the other or whether the two efforts will not converge for a
while (shudder)

A quick typo:
page 9, last para: s/Figure Figure/Figure/

regds
arjun

-- 
Arjun Roychowdhury

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 15 Feb 2005 19:45:38 +0200

Hi,

in the DC meeting, it was agreed to document the SBC functions. We 
gathered some volunteers, and put together this document. I was not 
aware of the other draft until it was announced on the mailing list. 
Otherwise, we would, of course, have worked all together on a single 
document and we all would have saved some time.

In any case, the idea now will be to produce a single document using all 
the available inputs (i.e., both of these drafts and the discussions on 
the mailing list and in the upcoming face-to-face meeting).

Regards,

Gonzalo

Arjun Roychowdhury wrote:

>>current SBCs and the SIP principles that were broken by these SBCs.
> 
> This
> 
>>list of functions was to be taken by the IETF as input to decide
> 
> whether
> 
>>We have tried to avoid talking about requirements, because this term
> 
> was
> 
>>confusing a lot of people. Taking these functions as input, the IETF
> 
> may
> 
>>requirements to session policies), but the functions themselves are
> 
> not
> 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 15 Feb 2005 15:29:26 -0500

inline
----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>

> There are certain instances of addresses that are
> always mentioned when discussing topology hiding.
> (Record-Route, Via, Contact, as well as the media
> address(es)). But there are many other well known
> and not so well known places where addresses may
> appear. Well known ones would include Refer-To, To,
> From, Alert-Info, Error-Info, and perhaps the
> e= field in sdp. Less well known ones would include
> sip extension headers in the message, as well as
> addressed embedded in body parts, such as sipfrags.
>
> How much of this does topology hiding typically deal
> with? In particular, are SBCs stripping extension
> headers unknown to them on the chance that they might
> contain an address that should be hid?

The SBC I know about has configuration to indicate which SIP headers need to
be examined. While things like Record-Route and Via can be stripped, for
other headers it is common to replace the address in the SIP header with
that of the SBC.

>
> - Deployment Scenarios
>
> In scenarios such as 4.1, *how* is the SBC being involved
> in the call? Is this a matter of provisioned configuration
> in the peer, the use of SRV records, or what?

It could be configuration, SRV, or any other mechanism the local operator
used to route requests to the SBC to reach its peer operator. Refering to
figure 2 on page 9, Typically, the gateway (GW-A1) would have sent the
INVITE to the softswitch (SSA) in operator A's network and it would redirect
the INVITE to the SBC because it was the preferred route for that session.
In any event, operator A determines which calls are sent to the SBC. The
text probably should have said that.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Feb 2005 17:25:48 -0500

> other headers it is common to replace the address in the SIP header with

I'm worried that there might be an SBC that is so paranoid that it 
removes anything it doesn't understand on the off chance that otherwise 
somebody might sneak through an address that would expose the topology. 
That could break anything the SBC didn't know about.

If you think topology hiding is worthwhile, you probably would be that 
paranoid. I have yet to see an argument for topology hiding that makes 
any sense to me.

	Paul

---

From: [email-masked]
Date: Tue, 15 Feb 2005 19:56:08 -0600

>SIP principles that were broken by these SBCs.

This draft when read in isolation all by itself is misleading and confusing,
since the usefulness of SBCs are presented only, without any discussions
about the pros/cons, alternative approaches, security, blocking of
applications the SBC does not understand, extra delay, bandwidth, etc., etc.

Some statements, such as the lack of alternatives are actually completely
misleading, since no well known options are discussed. At the least, the
IETF work on NAT traversal must be mentioned and discussed (STUN, TURN, ICE,
symmetric RTP, etc.).

As such, this I-D is not yet acceptable for discussion and should be
resubmitted when it will be more than just a promotion for SBCs.

Let's only hope this I-D will not produce confusion under the banner of the
IETF.

Thanks, Henry 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Gonzalo Camarillo
Sent: Tuesday, February 15, 2005 6:42 AM
To: sipping
Cc: Bob Penfield; Alan Hawrylyshen; Jani Hautakorpi (JO/LMF)
Subject: [Sipping] Draft: Functions of Current SBCs

Folks,

in the ad-hoc on SBCs we organized  in DC, we agreed to put together a small
team to write document describing the functions performed by current SBCs
and the SIP principles that were broken by these SBCs. This list of
functions was to be taken by the IETF as input to decide whether new
mechanisms are needed to implement those functions in a more architecturally
friendly way.

There have already been discussions on some of these issues in the mailing
list in the last weeks, but discussions would be appreciated.

Comments are welcome,

Gonzalo

_______________________________________________
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: Arjun Roychowdhury <[email-masked]>
Date: Tue, 15 Feb 2005 21:52:46 -0500

Actually, I think this draft is a good start put in context of its
objectives. The authors state that this draft is only to describe
common functionalities that are observed in SBCs today - not really to
debate whether they are right or wrong.
The role of SBCs is rather complex and a good start is for people to
understand what they accomplish in deployment today.

The first draft that was released in the group went into detailed
requirements assuming many things were necessary while this draft
starts with what SBCs do today. Hopefully these two drafts will result
in an in-between I-D that will help us better understand if at-all an
SBC can be characterized successfully within this group (reminds me of
the funny comment I read in some threads before about the SBC being a
floor wax and a dessert topping :-)

regds
arjun

-- 
Arjun Roychowdhury

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 16 Feb 2005 09:24:07 +0200

Hi Henry,

the purpose of this draft, as stated in its abstract, is to document 
functions currently provided by SBCs.

    The purpose of
    this document is to help the IETF community understand what
    functionality existing SBCs provide so that the appropriate working
    groups can decide whether or not new standard solutions need to be
    developed to provide such functionality (or a subset of it) in a
    standard way.

Once we understand what current SBCs do, we will be able to come up with 
"friendly" solutions to those problems (e.g., session policies).

The purpose of this draft is not, of course, to promote SBCs as 
currently implemented and, as you suggest, we will need to make sure 
that the scope and purpose of this draft is clearer in future versions.

Thanks for the comments,

Gonzalo

[email-masked] wrote:

> small
> mailing

---

From: "Shai Mohaban" <[email-masked]>
Date: Wed, 16 Feb 2005 12:06:53 -0800

Gonzalo,

This seems like a good start for educating people on why SBCs are being
deployed today. However, there are quite a few other things SBCs are
being used for and rather than submitting yet another draft it would
probably be best to integrate all these together. Here is a quick list
of some things I think should be added:

- Session Admission Control - Limiting the number of sessions or
bandwidth consumed by sessions by various parameters and group
aggregates. Carriers can use this to limit the number of sessions or
bandwidth that get routed into a peer network, into a given IP "trunk",
over an enterprise WAN link, etc.

- Call gapping - Some SBCs are designed so they can process very high
number of call attempts per second, especially when compared with the
capacity of typical SIP proxies or media gateways. They can therefore be
used to make sure such a SIP proxy or gateway is not hit e.g. with so
many INVITEs per second that it can not handle.

- DoS protection - Similarly the SBC can ensure session sources do not
generate unacceptable signaling/media both in terms of compliance with
the standards and message rate. The SBC can put a misbehaving entity
(e.g. an endpoint which repeatedly and continuously send out INVITEs or
REGISTERs) into a "black-list" and alert the operator.

- VPN aggregation - Many carriers use network based VPNs e.g. based on
RFC 2547. They are using SBCs to enable providing hosted VoIP services
to multiple such VPNs from a single shared network resource. The
alternative is either to use some sort of CPE gear per VPN or build a
separate infrastructure for each VPN customer.

- QoS monitoring - it is mentioned in section 3.3 but I think one
important notion is that measuring at the border e.g. between two
peering carriers often enables understanding of the quality not only
end-to-end but also separately on each leg (in the "internal" network
and the "external" network), which could be useful in order to determine
the source of quality issues, enable routing sessions to networks with
better (transient) quality, etc.

- TLS offloading - SBCs can be implemented at the entry point to a
CO/data center in front of the call control servers similarly to how TLS
offloaders are implemented today in front of WEB server farms. They can
incorporate hardware accelerators as needed.

- Load balancing - in a similar way the SBC can load balance between
call control servers and other entities.

- Transcoding - since SBCs often play an active role in a session and
are also required to be part of the media communication, multiple
carriers have expressed interest in the SBC also performing a
transcoding function at the border.

Some of the functions above suggest a third scenario in addition to the
two described in section 4 - that of an SBC fronting a data center/CO.
Some carriers use such a function in tandem with a "regular" data
firewall, while in some cases the SBC is the main security device (in
which case it processes also the "other" data traffic).

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: Tuesday, February 15, 2005 4:42 AM
> To: sipping

---

From: David R Oran <[email-masked]>
Date: Thu, 17 Feb 2005 13:11:34 -0500

I think we're still having scope problems. If an SBC happens to order 
lunch for me because it notices that I tried to call the deli and it 
was busy, should we list that as a "function of current SBCs"?

If an SBC happens to do something that a proxy or is perfectly allowed 
to do under RFC 3261 do we list that as a "function of current SBCs"? 
Note that I believe some of your examples below fall into this 
category.

I think a document listing the things people use SBCs for is 
potentially valuable, but not if it turns into a catalog of marketing 
literature. We should clearly scope this to things that SBCs do that:
(a) is prohibited one way or another from the scope of another 
SIP-compliant entity, such as a proxy or redirect server
(b) breaks end-to-end transparency
(c) operates without the explicit consent of one of the parties.
(d) breaks the URL-interpretation rules, for redirection/retargeting
...and perhaps other criteria.

Additional comments embedded.

> of some things I think should be added:
I'm not sure I agree with this. Part of our difficulty with this whole 
space is in not understanding what these things actually *do* coupled 
to *why* as opposed to just the marketing assertion around why some 
feature is in some box. Trying to figure out all the ways they may have 
been marketed and documenting those will only contribute to the 
confusion.

> over an enterprise WAN link, etc.
Yes. I think this one is relatively well understood.

> many INVITEs per second that it can not handle.
Any proxy can be enhanced do this. If I have a lame proxy or UAS and 
need to put a proxy in front to play 503 retry-after games, I can do 
that. It does not require an SBC.

> the standards and message rate.
I think we need to separate the signaling and media here. In the case 
of signaling, this couples closely with the mechanisms for controlling 
congestion. I'll note that its easy to protect yourself in the case of 
TCP by just slowing down your receive socket calls. In the case of 
media we need to think about whether this ought to be specified at the 
L7 relaying layer at all. Adequate mechanisms generally exist at L3, 
although they are not always turned on.

> The SBC can put a misbehaving entity
So can a proxy.

> separate infrastructure for each VPN customer.
Don't understand this one. Is this simply how to implement virtual 
multi-hosting similar to what  Apache and other web servers can do? If 
so I don't see where the SBC angle comes in.

> better (transient) quality, etc.
I'm afraid this one will be a bit of a rat hole since it stomps on 
things like NETflow, RAQMon, etc. I also think we need to separate the 
instrumentation issues from the dynamic measurement-based routing 
issues.

> incorporate hardware accelerators as needed.
So can any proxy.

> call control servers and other entities.
So can any proxy.

> transcoding function at the border.
I think that transcoding needs to be looked at in its own right, which 
we are in fact doing in the transcoding framework. The issue that 
arises is the whole consent question, and the intersection with session 
policies.

> which case it processes also the "other" data traffic).
Well, I don't think we can or should get into product packaging 
questions. If I happen to implement other firewall functions in the 
same box, that appears to be entirely outside the scope of this effort 
to characterize SBC functions.

>> mailing list in the last weeks, but discussions would be appreciated.
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "Shai Mohaban" <[email-masked]>
Date: Thu, 17 Feb 2005 17:37:36 -0800

Dave,

I think in the last IETF meeting it was agreed to try and better
understand why SBCs are used today and then try and fix whatever might
get broken (in order not to have the "son of BEHAVE" a few years down
the road, as Jonathan put it).

If people think we should not include here things that can potentially
be handled by other entities such as SIP proxies then so be it. BTW, who
said SBCs are not SIP proxies themselves (or include SIP proxies) to
start with?? It could even be the case (and many of us would hope) that
with some new SIP extensions future SBCs can indeed be pure SIP proxies
and still provide all the required functions.
But on the other hand you see arguments that SBCs are redundant or evil,
etc, and maybe exactly because there is such confusion it would be
worthwhile to describe why carriers are using these devices today in
general...

Another note - it could probably be argued that many of the reasons SBCs
are used today are indeed commercial rather than
technological/architectural and would not at all fall into the scope of
the IETF. That again shouldn't mean that these devices are redundant or
not needed or whatever. I think a relevant analogy can be drawn from
functions like firewalls, WEB load balancers and TLS offloaders. None of
these are required by the protocols/architectures and potentially you
can embed all these functions e.g. into routers/switches but yet these
devices still get deployed by the millions... 

> From: David R Oran [mailto:[email-masked]] 
> Sent: Thursday, February 17, 2005 10:12 AM
> To: Shai Mohaban
> Cc: 'Jani Hautakorpi (JO/LMF)'; 'Bob Penfield'; 'Gonzalo 
> Camarillo'; 'sipping'; 'Alan Hawrylyshen'
> Subject: Re: [Sipping] Draft: Functions of Current SBCs
> 
> 
> > capacity of typical SIP proxies or media gateways. They can 
> therefore 
> > be
> > CO/data center in front of the call control servers 
> similarly to how 
> > TLS
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >> This list 
> is for NEW development of the application of SIP

---

From: [email-masked]
Date: Thu, 17 Feb 2005 21:53:22 -0600

Shai,

>Another note - it could probably be argued that many of the reasons 
>SBCs are used today are indeed commercial rather than
technological/architectural 

You are right. Many service providers prefer central control out of the
central office and buying a box that does some stuff (too complex to
explain).

>would not at all fall into the scope of the IETF

The IETF can explain some pros and cons since people are looking for
guidance. The mission of the IETF is to develop open standards that make the
Internet work for all applications, on a global scale.

We have to figure out and articulate if SBCs are or are not in conflict with
the way the Internet works.

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Shai Mohaban
Sent: Thursday, February 17, 2005 7:38 PM
To: 'David R Oran'
Cc: 'Bob Penfield'; 'Alan Hawrylyshen'; 'Jani Hautakorpi (JO/LMF)';
'sipping'; 'Gonzalo Camarillo'
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Dave,

I think in the last IETF meeting it was agreed to try and better understand
why SBCs are used today and then try and fix whatever might get broken (in
order not to have the "son of BEHAVE" a few years down the road, as Jonathan
put it).

If people think we should not include here things that can potentially be
handled by other entities such as SIP proxies then so be it. BTW, who said
SBCs are not SIP proxies themselves (or include SIP proxies) to start with??
It could even be the case (and many of us would hope) that with some new SIP
extensions future SBCs can indeed be pure SIP proxies and still provide all
the required functions.
But on the other hand you see arguments that SBCs are redundant or evil,
etc, and maybe exactly because there is such confusion it would be
worthwhile to describe why carriers are using these devices today in
general...

Another note - it could probably be argued that many of the reasons SBCs are
used today are indeed commercial rather than technological/architectural and
would not at all fall into the scope of the IETF. That again shouldn't mean
that these devices are redundant or not needed or whatever. I think a
relevant analogy can be drawn from functions like firewalls, WEB load
balancers and TLS offloaders. None of these are required by the
protocols/architectures and potentially you can embed all these functions
e.g. into routers/switches but yet these devices still get deployed by the
millions... 

> Cc: 'Jani Hautakorpi (JO/LMF)'; 'Bob Penfield'; 'Gonzalo Camarillo'; 
> 'sipping'; 'Alan Hawrylyshen'
> feature is in some box. Trying to figure out all the ways they may 
> have been marketed and documenting those will only contribute to the 
> confusion.
> 
> > The SBC can put a misbehaving entity (e.g. an endpoint which 
> > repeatedly and continuously send
> out INVITEs or
> > and the "external" network), which could be useful in order to 
> > determine the source of quality issues, enable routing sessions to
> networks with
> arises is the whole consent question, and the intersection with 
> session policies.
> 
> >> in the ad-hoc on SBCs we organized  in DC, we agreed to put 
> >> together a small team to write document describing the functions 
> >> performed by current SBCs and the SIP principles that were broken 
> >> by these SBCs. This list of functions was to be taken by the IETF 
> >> as input to decide whether new mechanisms are needed to implement 
> >> those functions in a more architecturally friendly way.
> >>
> >> We have tried to avoid talking about requirements, because this 
> >> term was confusing a lot of people. Taking these functions as 
> >> input, the IETF may develop requirements to work on different 
> >> solutions (e.g., adding requirements to session policies), but the 
> >> functions themselves are not requirements at this point.
> >>

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 17 Feb 2005 23:16:33 -0500

Defining scope is right thing. An SBC can be defined for almost any protocol
I can think of (SIP, HTTP, RTSP ...). Since the primary application is NAT,
DoS is the most obvious thing. Some non traditional applications are on a
router, QoS border etc. I suggest we just focus on SIP to keep the problem
bound.

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of David R
> Oran
> Sent: Thursday, February 17, 2005 1:12 PM
> To: Shai Mohaban
'sipping'; 'Gonzalo
> Camarillo'
> > determine
> >> together a

---

From: Jani Hautakorpi <[email-masked]>
Date: Fri, 18 Feb 2005 10:39:13 +0200

David,

I agree with you that we're having scope problems. In this draft, we 
have tried to list only the most common functions of current SBCs. Of 
course, there can be additions to these functions in the future, since 
this list isn't by any means extensive.

However, I also thing that we shouldn't list all the imaginable 
functions as an SBC function, but we should instead use common sense on 
which function is really relevant.

-- 
Regards,
Jani Hautakorpi

David R Oran wrote:
>>This seems like a good start for educating people on why SBCs are
> 
> being
> 
>>bandwidth that get routed into a peer network, into a given IP
> 
> "trunk",
> 
>>(e.g. an endpoint which repeatedly and continuously send out INVITEs
> 
> or
> 
>>offloaders are implemented today in front of WEB server farms. They
> 
> can
> 
>>Some of the functions above suggest a third scenario in addition to
> 
> the
>

---

From: Arjun Roychowdhury <[email-masked]>
Date: Fri, 18 Feb 2005 08:14:06 -0500

On Fri, 18 Feb 2005 10:39:13 +0200, Jani Hautakorpi 
> which function is really relevant.

The way I see it, unless we really get to see everything that an SBC
does, it would be impossible to understand what breaks SIP guidelines
and what does not. Once we do have a list of all the sins of the SBC,
one can work into what needs to be architecturally seperated.

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.

So my preference would be to support this draft, and get all the
features that are  bundled today. Lets not argue on what really should
be done right now, but rather what is being done in the industry for
the scope of this draft.

regds
arjun

-- 
Arjun Roychowdhury

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 18 Feb 2005 07:58:31 -0600

Let me start by saying that I agree with this theory, in theory, but

> one can work into what needs to be architecturally seperated.

It was fairly obvious during the SBC "informal meeting" that SBC 
vendors started by doing "something", but have been adding 
functionality that might or might not be related to that "something" 
because, once installed, an SBC is a platform at a network edge - and, 
in at least one quote from my meeting notes* (sorry I don't have an 
attribution):

"We're talking about excuses, not problems. The problem is that the 
carrier wants to control everything. That's the problem SBCs are 
solving. When we solve the stated "problems", people will come up with 
new justifying problems."

Or, from Ben:

"Sometimes this is political - service management departments that 
won't talk to firewall departments. We're talking about a political 
perimeter."

IIUC, Ben's point was that SBCs may be controlled by voice services 
groups that don't control IP routing and firewall infrastructure, so 
the SBC is their platform at the network edge to do "whatever" without 
having to rely on the networking groups that do control this 
infrastructure.

This may explain some of our inability to characterize "whatever" :-)

Yes, we are having feature creep. Some of the feature creep in our 
scope matches SBC feature creep in the market. Some of the feature 
creep in the market seems to be at customer request (and not just 
random attempts at differentiation).

Yes, I would like to limit scope.

One possible definition from the meeting was "anything" (that does 
SIP, I assume, and) "that isn't a UA and isn't a SIP proxy".

Does this help?

Spencer

(*) Notes at 
http://www.softarmor.com/sipping/meets/ietf61/notes/notes-ietf61-sbc-ad-hoc-spencer.html

---

From: Arjun Roychowdhury <[email-masked]>
Date: Fri, 18 Feb 2005 09:28:11 -0500

> SIP, I assume, and) "that isn't a UA and isn't a SIP proxy".

That isn't a UA means taking away functionality like topology
hiding,Protocol repair,Profile Interworking,media encryption and
transcoding.

Not being a proxy I could argue affects access control. There isn't
very much left in the list of functions I see in Gonzalo's draft
beyond this.

> Does this help?
see above :-)

regds
arjun

-- 
Arjun Roychowdhury

---

From: [email-masked]
Date: Fri, 18 Feb 2005 08:34:52 -0600

>an SBC is a platform at a network edge

This is a point worth debating as well. You don't mean SBC is CPE?

Thanks, Henry 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Spencer Dawkins
Sent: Friday, February 18, 2005 7:59 AM
To: sipping
Subject: Re: [Sipping] Draft: Functions of Current SBCs

> one can work into what needs to be architecturally seperated.

It was fairly obvious during the SBC "informal meeting" that SBC vendors
started by doing "something", but have been adding functionality that might
or might not be related to that "something" 
because, once installed, an SBC is a platform at a network edge - and, in at
least one quote from my meeting notes* (sorry I don't have an
attribution):

"We're talking about excuses, not problems. The problem is that the carrier
wants to control everything. That's the problem SBCs are solving. When we
solve the stated "problems", people will come up with new justifying
problems."

Or, from Ben:

"Sometimes this is political - service management departments that won't
talk to firewall departments. We're talking about a political perimeter."

IIUC, Ben's point was that SBCs may be controlled by voice services groups
that don't control IP routing and firewall infrastructure, so the SBC is
their platform at the network edge to do "whatever" without having to rely
on the networking groups that do control this infrastructure.

Yes, we are having feature creep. Some of the feature creep in our scope
matches SBC feature creep in the market. Some of the feature creep in the
market seems to be at customer request (and not just random attempts at
differentiation).

One possible definition from the meeting was "anything" (that does SIP, I
assume, and) "that isn't a UA and isn't a SIP proxy".

Does this help?

Spencer

(*) Notes at
http://www.softarmor.com/sipping/meets/ietf61/notes/notes-ietf61-sbc-ad-hoc-
spencer.html

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Fri, 18 Feb 2005 10:01:59 -0500

Really. I did not know that. I think you mean the first hop of NAT (like
getting out of the enterprise network or home). I'd have the locate the STUN
server "strategically" which means that multiple SPs would have to cooperate
on where to put it so that the user can get the right IP address.

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Arjun
> Roychowdhury
> Sent: Friday, February 18, 2005 8:14 AM
> To: Jani Hautakorpi
> Cc: sipping

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Fri, 18 Feb 2005 10:04:38 -0500

I think this brings us back to what is the definition of the SBC ? I think
it has enough synergies with NATs. So CPE, Provider Edge all would make
sense. I think the definition can be generalized to any border, be it
security (NAT), QoS (Diffserv border element) etc. All of these require the
same kind of treatment to SIP messages and create the same set of problems.

-Medhavi.

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> [email-masked]
> Sent: Friday, February 18, 2005 9:35 AM
> To: 'Spencer Dawkins'; 'sipping'
carrier

---

From: Arjun Roychowdhury <[email-masked]>
Date: Fri, 18 Feb 2005 10:29:04 -0500

Fair enough, Medhavi. Before I get beaten up by all the SBC vendors,
I'll admit that my point was not well worded :^). I was just trying to
highlight that NAT is an accepted function of an SBC and a good amount
of work has been done in the IETF regarding NAT traversal. The
situation does become complex with multiple hops and heterogenous
environments as you correctly state.

To keep to the point, which my original mail digressed from:
The past few weeks , the debate we have had in this thread and the one
post your I-D has been to do with what else goes into an SBC and what
is right/wrong.

I just feel its a little premature for that right now. Lets atleast
have a document that highlights the current deployment situation so we
can keep referring to it as the scope is refined _after_ the draft
gets released.

regds
arjun

-- 
Arjun Roychowdhury

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 21 Feb 2005 14:11:58 +0200

Hi,

> be handled by other entities such as SIP proxies then so be it. 

Exactly. As the draft indicates in its abstract and its introduction, 
the purpose of this exercise is to identify functions that cannot be 
performed with the current SIP toolbox. Once we identify these 
functions, we will extend the toolbox appropriately.

However, if a proxy, which is part of the current toolbox, can already 
perform a particular function, we do not have any problem. We do not 
need to document what operators do with their proxy servers.

> worthwhile to describe why carriers are using these devices today in

The scope of this draft is clearly not to state whether or not SBCs are 
evil. We are only interested in functions that require SIP extensions so 
that they can be carried out without breaking the SIP architecture 
(e.g., end-to-end integrity, confidentiality and feature negotiation).

Regards,

Gonzalo

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 21 Feb 2005 20:37:42 -0600

To the author team - thank you for putting this together. It provides 
much-needed (as we proved in DC!) structure for our discussion.

There are a number of places in the draft where the authors say "X 
does/does not cause problems" - usually from an architectural 
viewpoint. It would be nice if these were collected into a summary.

This draft may not be the right place for it, but I would like to 
focus on exactly the deployment scenarios that this draft excludes - 
scenarios with multiple SBCs in the path. We discussed the "SBC at the 
enterprise edge, SBC at the access edge" scenario in DC. Multi-SBC 
scenarios are already popping up in deployments.

This still isn't chartered work for SIPPING, is it? Have there been 
proposals for next steps?

Spencer