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

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

Let me go a step further.  If you market something called an SBC that never
re-writes SDP or other "untouchable" data element, you have a Proxy.  Call
it what you want.

If you market something called an SBC that terminates a SIP Dialog (a.k.a.
UAS) and originates a new SIP Dialog (a.k.a. UAC), you have a B2BUA.

THERE ARE ABSOLUTELY NO RESTRICTIONS ON WHAT A B2BUA IS ALLOWED TO DO, SO
LONG AS EACH DIALOG OBSERVES RFC3261 et al.

As Henry keeps pointing out, if you buy SIP-less service from a service
provider, you are free to find another service provider.  Of course, you are
SOL if you have only a single supplier of IP connectivity.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Drage, Keith (Keith)
Sent: Tuesday, March 01, 2005 8:05 AM
To: 'Medhavi Bhatia'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

I don't think we can go in this direction.

There is currently 2 core SIP entities defined, UA and proxy. They have
rigorous definitions with state machines and defined handling of various
header and message bodies. 

If your entity is conformant to RFC 3261 UA functionality, then call it a UA
(or a B2BUA).

If your entity is conformant to RFC 3261 proxy functionality, then call it a
proxy.

If your entity is neither, then do not call it a UA or a proxy, or even
nearly a UA a proxy. Further, if you need it to be standardised, it needs
the same rigorous definitions that are already given in RFC 3261 to UA and
proxy. Additionally, in defining such a new role (Paul's "neither fish nor
foul" entity), the impact on backward compatibility with the existing RFC
3261 entities needs to be fully investigated. You cannot avoid these issues
just be calling it "nearly a proxy".

We still however seem to be getting bogged down in discussions of how we
implement these things, rather than the discussion proceeding in identifying
the functions that need to be supported, and why existing SIP roles cannot
perform these functions. We need that discussion to have completed before
someone can start inventing a new SIP role.

regards

Keith
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Medhavi Bhatia
Sent: 28 February 2005 03:20
To: 'Roy, Radhika'; 'Christer Holmberg (JO/LMF)'; [email-masked];
'Brian Rosen'; 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Radhika,
 
What about entities which are not UAs (or B2BUAs) which modify SDP ? (like
ALGs). Guess they fall through the terminology trap door ;) I'd still call
them proxies (trusted or malicious) according to Section 26.1.3 in rfc 3261.
 
-Medhavi. 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Roy, Radhika
Sent: Sunday, February 27, 2005 5:49 PM
To: Medhavi Bhatia; Christer Holmberg (JO/LMF); [email-masked]; Brian
Rosen; Richard Fogel; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs
 
One thing that we need to make sure that we must follow the terminologies
used in SIP RFCs. For example, a SIP Proxy must NOT modify SDP. However, a
SIP UA can modify SDP. That is why, the term B2BUA is used in the context of
Transcoder, 3rd party Call Controller, etc.
 
If anyone wants to violate the above definition of SIP Proxy, it will create
a whole lot of confusions in SIP standards, products, and industry as a
whole.
 
Let us not "twist" the fundamental aspects of SIP standards.
 
Keeping the above thing in our mind, let us see what we call this entity
(e.g., SBC).
 
Best regards,
Radhika
 
PS: By the way, some vendors have used the term as "SIP Signaling Proxy." It
is the SIP Proxy that modifies the SDP, where needed based on some
predefined service logic, but does NOT receive or send RTP/media. There are
so many "tricks" are being played in development of the products in the
industry. Let us not follow those non-standard terms because it will defeat
the main purpose of standardization. 

From: Medhavi Bhatia [mailto:[email-masked]]
Sent: Sun 2/27/2005 3:58 PM
To: Roy, Radhika; 'Christer Holmberg (JO/LMF)'; [email-masked]; 'Brian
Rosen'; 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs
If NAT ALG is the only function the SBC is providing, it doesn't need to be
a B2BUA. In the case of transcoding too, I don't see why the SBC needs to be
a B2BUA. I think the same can be done using a proxy (though the role of
modifying SDP would violate RFC 3261). Going forward, things like topology
hiding and interworking may become more specialized applications reducing
the need for SBCs to be B2BUAs. 
 
I think of the SBC as more like a set of requirements, for example security
related, dos attacks, spam etc. The implementations today have become more
of an issue since they are not compliant with SIP. I think the markets
and/or technology will evolve to be a better fit in near future.
 
-Medhavi.

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Roy, Radhika
Sent: Sunday, February 27, 2005 3:24 PM
To: Christer Holmberg (JO/LMF); [email-masked]; Medhavi Bhatia; Brian
Rosen; Richard Fogel; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs
 
Yes, they are all B2BUAs (e.g., Transcoder, 3rd Party Call Controller,
etc.). However, all of them have specific names based on the services that
are being provided by each one of them among the SIP UAs.
 
So, this one (e.g., SBC) should also need to have a name, I believe.
 
Best regards,
 
Radhika R. Roy
SAIC

From: [email-masked] on behalf of Christer Holmberg (JO/LMF)
Sent: Sun 2/27/2005 1:35 PM
To: [email-masked]'; 'Medhavi Bhatia'; 'Brian Rosen'; 'Richard Fogel';
[email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs
If we can't call them SBCs, I'll give my hum for calling them B2BUAs...
 
Regards,
 
Christer Holmberg
Ericsson Finland
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: 24. helmikuuta 2005 23:23
To: 'Medhavi Bhatia'; 'Brian Rosen'; 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs
We have now a good agenda item for the SIPPING WG: Humming on various name
proposals  :-)
 
Henry

From: Medhavi Bhatia [mailto:[email-masked]] 
Sent: Thursday, February 24, 2005 2:39 PM
To: [email-masked]; 'Brian Rosen'; 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs
I'd still vote for something like P-SBC and N-SBC. We already know these are
kinds of SBCs. The word customer premise needs to be captured, so P-SBC
should be "Premises-SBC". I can't get the same understanding just by the
word perimeter.

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

.
> LONG AS EACH DIALOG OBSERVES RFC3261 et al.

True. However we all want trust and end-to-end encryption to work. B2BUAs (I
would include application servers, SBCs, PoC servers etc) all break that w/o
breaking anything in RFC 3261 per se. I guess what I am trying to say is
that we need to somehow either invent or modify the current mechanisms.

-Medhavi.