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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 24 Feb 2005 13:53:08 -0500

Henry,
 
One of the issues is what we mean by network or perimeter.  From the
perspective of the network transport mechanisms, a SIP sending device
may be centered in the data network somewhere multiple router hops away
from the data network edge.  But, from the perspective of the SIP
application layer, the SIP sending device may be the last such device to
operate on SIP (think TLS connection) within that network before
egressing that data network to another data network.  Put another way,
it is perimeter for the ITSP, but not perimeter for the ISP, both of
which might be the same SP.  The co-location topologically of SBC with
NAT or FW begs for a picture to be drawn.  Else, we are blind men
describing an (white?) elephant.
 
Another aspect is, from the SIP application layer perspective, one type
of ITSP SIP perimeter device is used to peer with another ITSP SIP
perimeter device.  Another type of perimeter device interfaces with a
customer SIP perimeter device (e.g. IP-PBX) or simply a customer IAD or
SIP IP Phone.  Client side v. Network side sort of captures this facet,
but I am leery of the term client that slides too easily into UAC v.
UAS, v. Proxy connotations.  Hard to differentiate, when there is a
peer-to-peer aspect to this.  Because of mobility, perhaps there really
is no distinction between customer and ITSP peer interfaces.
 
The SBC concept seems to infer that there is an "inside" versus
"outside".  With mobility the devices supposedly on the "inside" may
really be on the "outside" from the data network perspective.
Ultimately, it seems a given SIP message is addressed to a particular
SIP peer and pops up out of the data network at that peer's IP/port
doorstep.  If the SIP device does not have any relationship to the
message sender, it can forward/redirect on to another device or ignore
that request.  It would seem this devolves into SIP devices ensuring
that the proper sequence of SIP devices is traversed so that SIP
functions are performed in the proper order.  Leading back to what SIP
border functions are needed.  These may depend on whether the
relationships are native or non-native.
 
Mike

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
	Sent: Thursday, February 24, 2005 12:14 PM
	To: 'Brian Rosen'; 'Medhavi Bhatia'; 'Richard Fogel';
[email-masked]
	Subject: RE: [Sipping] Draft: Functions of Current SBCs

	>How about client side and network side?
	 
	1. The intermediaries used in carrier networks (often referred
to as SBC in a confusing manner) could be called "Network based Session
Controllers" or NSC.
	 
	2. The intermediaries at the perifery of private IP networks,
colocated with the NAT/FW could be called "Perimeter Session
Controllers" or PSC.
	 
	Any other, more accurate names?
	 
	Thanks, Henry

________________________________

	From: Brian Rosen [mailto:[email-masked]] 
	Sent: Thursday, February 24, 2005 10:43 AM
	To: [email-masked]; 'Medhavi Bhatia'; 'Richard Fogel';
[email-masked]
	Subject: RE: [Sipping] Draft: Functions of Current SBCs

	Henry

	As always, you wield a sharp sword.  I think you are correct, we
need to differentiate a client side SBC from a network side SBC and we
need names.

	How about client side and network side?

	Brian

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
	Sent: Thursday, February 24, 2005 10:45 AM
	To: 'Medhavi Bhatia'; 'Richard Fogel'; [email-masked]
	Subject: RE: [Sipping] Draft: Functions of Current SBCs

	Medhavi,

	It appears the location of such intermediaries makes the
critical difference:

	1. SBC placed in the network (in the C.O.) of the carrier, or 

	2. A perimeter device (such as Borderware or SIP media Proxy -
these are product names ) that is collocated as CPE with the NAT and
Firewall. This co-location changes many security aspects (we need to
specify which) and also the media performance, as well as bandwidth
consumption. Multi-homing is an issue here, not to forget.

	I suggest we should always make this distinction. Maybe someone
proposes some definitions or names for each.

	Thanks, Henry

_______________________________________________
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: "Brian Rosen" <[email-masked]>
Date: Thu, 24 Feb 2005 14:19:25 -0500

I don't think I agree.

A carrier (ITSP) deploys an SBC to protect his network from his customers
and his peers.

An enterprise/residence/. deploys an SBC to protect his internal domain from
any caller from any external domain.

We observe that there are more similarities than differences, but there are
differences.

It is pretty unusual for an enterprise/residential network to deploy an SBC
anywhere other than the perimeter of their network.

It is pretty unusual for a carrier to deploy an SBC anywhere other than the
perimeter of the "service" (voice/video/text/.) part of their network.

In both cases, you may have some packet level boxes between the SBC and the
actual edge of the network, but logically, they are both the last box facing
the rest of the world.

Brian

  _____  

From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Thursday, February 24, 2005 1:53 PM
To: [email-masked]; Brian Rosen; Medhavi Bhatia; Richard Fogel;
[email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Henry,

One of the issues is what we mean by network or perimeter.  From the
perspective of the network transport mechanisms, a SIP sending device may be
centered in the data network somewhere multiple router hops away from the
data network edge.  But, from the perspective of the SIP application layer,
the SIP sending device may be the last such device to operate on SIP (think
TLS connection) within that network before egressing that data network to
another data network.  Put another way, it is perimeter for the ITSP, but
not perimeter for the ISP, both of which might be the same SP.  The
co-location topologically of SBC with NAT or FW begs for a picture to be
drawn.  Else, we are blind men describing an (white?) elephant.

Another aspect is, from the SIP application layer perspective, one type of
ITSP SIP perimeter device is used to peer with another ITSP SIP perimeter
device.  Another type of perimeter device interfaces with a customer SIP
perimeter device (e.g. IP-PBX) or simply a customer IAD or SIP IP Phone.
Client side v. Network side sort of captures this facet, but I am leery of
the term client that slides too easily into UAC v. UAS, v. Proxy
connotations.  Hard to differentiate, when there is a peer-to-peer aspect to
this.  Because of mobility, perhaps there really is no distinction between
customer and ITSP peer interfaces.

The SBC concept seems to infer that there is an "inside" versus "outside".
With mobility the devices supposedly on the "inside" may really be on the
"outside" from the data network perspective.  Ultimately, it seems a given
SIP message is addressed to a particular SIP peer and pops up out of the
data network at that peer's IP/port doorstep.  If the SIP device does not
have any relationship to the message sender, it can forward/redirect on to
another device or ignore that request.  It would seem this devolves into SIP
devices ensuring that the proper sequence of SIP devices is traversed so
that SIP functions are performed in the proper order.  Leading back to what
SIP border functions are needed.  These may depend on whether the
relationships are native or non-native.

Mike

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, February 24, 2005 12:14 PM
To: 'Brian Rosen'; 'Medhavi Bhatia'; 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

>How about client side and network side?

1. The intermediaries used in carrier networks (often referred to as SBC in
a confusing manner) could be called "Network based Session Controllers" or
NSC.

2. The intermediaries at the perifery of private IP networks, colocated with
the NAT/FW could be called "Perimeter Session Controllers" or PSC.

Thanks, Henry

  _____  

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, February 24, 2005 10:43 AM
To: [email-masked]; 'Medhavi Bhatia'; 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Henry

As always, you wield a sharp sword.  I think you are correct, we need to
differentiate a client side SBC from a network side SBC and we need names.

Brian

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, February 24, 2005 10:45 AM
To: 'Medhavi Bhatia'; 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Medhavi,

It appears the location of such intermediaries makes the critical
difference:

2. A perimeter device (such as Borderware or SIP media Proxy - these are
product names ) that is collocated as CPE with the NAT and Firewall. This
co-location changes many security aspects (we need to specify which) and
also the media performance, as well as bandwidth consumption. Multi-homing
is an issue here, not to forget.

I suggest we should always make this distinction. Maybe someone proposes
some definitions or names for each.

Thanks, Henry

---

From: Richard Fogel <[email-masked]>
Date: Thu, 24 Feb 2005 14:16:24 -0500

Michael, this is a very good point which cuts to the chase on this
whole matter. There is a very narrow view being expressed in the SBC
discussions, possibly due to the discussion being led by current
technology implementations rather than a desire to further and forward
the concepts and usage of SIP. If we jump up to a slightly high view of
the situation we will see that there is no real hard delineation in the
concept of SIP message flow. What is on the 'inside' and 'outside' ?
Where does the end point of the conversation reside ? As we look at the
series of UAs, UEs, Proxies, etc in a peering network message flow,
where exactly is this delineation ? This gets even more complex when we
look at the current implementation issues with using a softphone on a
laptop to talk to a softphone on a 3G or Edge device as the cellular
user is roaming ! To this end, the concept of an edge proxy may be
easily fit to these complex scenarios, the edge being where the SIP
message 'pops up out of the data network at that peer's
IP/port doorstep'. An edge proxy may reside in a small form factor on
the endpoint as easily as it resides within the POP of a service
provider. Within this non-intrusive concept, the security provided is
both at the transport and application layer allowing the Edge Proxy to
provide functionality where needed.

Richard

Michael Hammer (mhammer) wrote:

Henry,

One of the issues is what we
mean by network or perimeter.  From the perspective of the network
transport mechanisms, a SIP sending device may be centered in the data
network somewhere multiple router hops away from the data network
edge.  But, from the perspective of the SIP application layer, the SIP
sending device may be the last such device to operate on SIP (think TLS
connection) within that network before egressing that data network to
another data network.  Put another way, it is perimeter for the ITSP,
but not perimeter for the ISP, both of which might be the same SP.  The
co-location topologically of SBC with NAT or FW begs for a picture to
be drawn.  Else, we are blind men describing an (white?) elephant.

Another aspect is, from the SIP
application layer perspective, one type of ITSP SIP perimeter device is
used to peer with another ITSP SIP perimeter device.  Another type of
perimeter device interfaces with a customer SIP perimeter device (e.g.
IP-PBX) or simply a customer IAD or SIP IP Phone.  Client side v.
Network side sort of captures this facet, but I am leery of the term
client that slides too easily into UAC v. UAS, v. Proxy connotations.
Hard to differentiate, when there is a peer-to-peer aspect to this.
Because of mobility, perhaps there really is no distinction between
customer and ITSP peer interfaces.

The SBC concept seems to infer
that there is an "inside" versus "outside".  With mobility the devices
supposedly on the "inside" may really be on the "outside" from the data
network perspective.  Ultimately, it seems a given SIP message is
addressed to a particular SIP peer and pops up out of the data network
at that peer's IP/port doorstep.  If the SIP device does not have any
relationship to the message sender, it can forward/redirect on to
another device or ignore that request.  It would seem this devolves
into SIP devices ensuring that the proper sequence of SIP devices is
traversed so that SIP functions are performed in the proper order.
Leading back to what SIP border functions are needed.  These may depend
on whether the relationships are native or non-native.

Mike

From:
[email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]

>How about
client side and network side?

1. The
intermediaries used in carrier networks (often referred to as SBC in a
confusing manner) could be called "Network based Session
Controllers" or NSC.

2. The
intermediaries at the perifery of private IP networks, colocated with
the NAT/FW could be called "Perimeter Session
Controllers" or PSC.

Any other,
more accurate names?

Thanks, Henry

From: Brian
Rosen [mailto:[email-masked]]

Henry

As always,
you wield a sharp sword.  I think you are correct, we need to
differentiate a client side SBC from a network side SBC and we need
names.

How about
client side and network side?

Brian

From:
[email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]

Sent: Thursday,
February 24, 2005 10:45 AM

To: 'Medhavi
Bhatia'; 'Richard Fogel'; [email-masked]

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

Medhavi,

It appears
the location of such intermediaries makes the critical difference:

1. SBC
placed in the network (in the C.O.) of the carrier, or

2. A
perimeter device (such as Borderware or SIP media Proxy - these are
product names ) that is collocated as CPE with the NAT and Firewall.
This co-location changes many security aspects (we need to specify
which) and also the media performance, as well as bandwidth
consumption. Multi-homing is an issue here, not to forget.

I suggest we
should always make this distinction. Maybe someone proposes some
definitions or names for each.

Thanks, Henry

---

From: [email-masked]
Date: Thu, 24 Feb 2005 14:16:57 -0600

Mike,
 
We may want to look at this point at some usage scenarios. Here is one
that's quite common:
 
UA1-- Enterprise1 == ISP1 == Internet == ISP2 ==Enterprise2 -- UA2 
 
The double line == is where such intermediaries can be inserted. 
 
Besides defining here what's the perimeter and network based (two of each in
the picture), maybe people would like to comment what it would mean to do
interoperability testing and integration testing every time there is some
new service. If a new service that the intermediaries don't understand even
has any chance... Just drawing the complete call flows and testing them
between the four intermediaries in four networks seems a non-trivial task.
Whops! I just forgot the NATs :-)
 
Henry

  _____  

From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Thursday, February 24, 2005 12:53 PM
To: [email-masked]; Brian Rosen; Medhavi Bhatia; Richard Fogel;
[email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Henry,

 
 
Mike

  _____  

 

 
Thanks, Henry

  _____  

Henry

Brian

  _____  

Medhavi,

Thanks, Henry