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

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 1 Mar 2005 11:19:27 -0500

I don't think the SBC is any "SIP entity". SBC is just a marketing term,
providing mostly security functions at this point. 

Consider an entity deployed at the security border doing just SPAM
detection/prevention, DoS attack prevention etc. These are SBC functions,
but they can be done using a SIP Proxy. 

If this entity is performing some NAT functions or transcoding like SDP
rewriting, then we need a B2B UA (there are non-compliant SIP ALGs which
perform SDP re-writing, but lets consider those as a separate problem). For
transcoding, the SBC may make the transcoding decision and send the call to
a transcoder. In this case, the SBC could be a SIP Proxy and the transcoder
a B2BUA. Similarly for QoS borders, SDP inspection may be required rather
than rewrites at the SBC. This could be done using a SIP Proxy as well, but
requires SDP inspection. 

If the SBC is generating new messages on behalf of either endpoints, it
needs to be a B2BUA.

-Medhavi.

  _____  

From: Drage, Keith (Keith) [mailto:[email-masked]] 
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

_______________________________________________
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: [email-masked]
Date: Tue, 01 Mar 2005 12:13:27 -0500 (EST)

I think you're absolutely right. I don't understand why the current discussion
is getting bogged down in taxonomy questions about B2BUAs, Proxies etc. Let's
first decide that a new architectural piece is needed to solve problems like
NAT, spam, SIP DoS, etc. and then decide what to call it (I've called it an Edge
Proxy, but that's subject to change).

---

From: [email-masked]
Date: Tue, 1 Mar 2005 12:39:48 -0500

>Let's first decide that a new architectural piece is needed to solve
problems like NAT, spam, SIP DoS, etc.

You all know the IETF solutions for each. If there is interest, we can
assemble the list of relevant IETF RFCs and Internet Drafts.

If we do, please state exactly what is missing in the current documents for
SIP NAT, SIP spam and SIP DOS. Unless you want to support legacy UAs that
don't have ICE, in which case user edge boxes, colocated as CPE, would be
OK, since they can be part of the NAT/FW and don't worsen the media
performance.

So please state what is missing in the current IETF work, item by item.

Thanks, Henry 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Tuesday, March 01, 2005 12:13 PM
To: [email-masked]
Cc: 'Drage, Keith (Keith)'
Subject: RE: [Sipping] Draft: Functions of Current SBCs

I think you're absolutely right. I don't understand why the current
discussion is getting bogged down in taxonomy questions about B2BUAs,
Proxies etc. Let's first decide that a new architectural piece is needed to
solve problems like NAT, spam, SIP DoS, etc. and then decide what to call it
(I've called it an Edge Proxy, but that's subject to change).
> 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
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Mar 2005 12:45:41 -0500

Medhavi Bhatia wrote:
> I don’t think the SBC is any “SIP entity”. SBC is just a marketing term, 

I don't think you really mean that it isn't *any* sip entity - but 
rather that no single currently defined sip entity covers all the 
functions that it might perform. You seem to be suggesting that it is 
context sensitive. We already have many compliant examples of this:

- UAC and UAS are separately defined, but I doubt if you can find
   a device that is one without also being the other.

- its quite common for a single device to usually be a proxy, but
   to sometimes send a 3xx. When it does it is acting as a UAS.

- it is quite common for a device to act as both a proxy and a
   registrar (which is a special form of UAS).

None of these cases bother anyone. I think the cases that bother people 
are when a device acts in multiple conflicting roles in a single 
context. A good example is a device that acts as a proxy until it 
redeclares itself as a B2BUA and sends a BYE. This is in violation of 
the expectations of the other parties regarding what the roles are in 
the dialog(s).

	Paul

> detection/prevention, DoS attack prevention etc. These are SBC 
> functions, but they can be done using a SIP Proxy.
> 
> perform SDP re-writing, but lets consider those as a separate problem). 
> For transcoding, the SBC may make the transcoding decision and send the 
> call to a transcoder. In this case, the SBC could be a SIP Proxy and the 
> transcoder a B2BUA. Similarly for QoS borders, SDP inspection may be 
> required rather than rewrites at the SBC. This could be done using a SIP 
> Proxy as well, but requires SDP inspection.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Mar 2005 04:26:05 -0500

One of the problems we have in this thread (and there are many) is that 
there is a misconception about the difference between a logical and a 
physical role.

In SIP, we have tried quite hard to specify things in terms of logical 
roles. These are behaviors that a physical entity can follow. Indeed, in 
order to provide flexibility, these logical roles are ideally defined on 
a fairly fine grained basis as component roles, so that a physical 
device can be composed of many such logical roles. All of this is 
spelled out in:

http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-sip-arch-00.txt

We in the IETF have not specified the physical components that people 
have to build. Indeed, we have tried to leave lots of room for 
flexibility even on how these various roles behave. We don't specify 
what kind of routing logic a proxy uses, or how it makes authorization 
decisions, and so on. The result of this is that vendors can build 
products that contain certain logical roles behaving in certain ways, 
and still be compliant to the specs.

As an exmaple, considering even vanilla proxies, there are different 
types of proxies that folks talk about - home proxies, route proxies, 
edge proxies, and so on. The various CSCF flavors of proxy/b2bua are 
another example of this.

Applying this to the SBC discussion, SBC has become a marketing term for 
a box that provides a set of functions. I don't think it is the job of 
IETF to specify what has to be inside of an SBC, anymore than it is our 
job to specify what goes inside of something a vendor calls a "home 
proxy" or "application server". However, it is our job to make sure that 
the component functions that vendors are looking to put inside of that 
box can be implemented using standards based techniques.

As a result, I think there is a natural progression in the set of 
activities we need to do here:

1. document what various vendors and providers think these boxes are 
doing (in terms of addressing problems) today. This gives us a big set 
of problems to start with. I don't know that these documents ever need 
to become RFCs; they serve as fodder for subsequent work. Gonzalo's 
draft is a reasonable starting point here.

2. from these list of functions, we extract orthogonal sets of problems, 
each of which (1) can be considered in isolation, and (2) we believe 
represents a problem for which there is no solution based on existing 
standards, and for which we feel development of a solution is 
reasonable. Each of those things results in a requirements document.

3. from there, we follow our normal sip process

4. it might be handy to have an "examples" document, akin to nat 
scenarios and service examples, which shows the various solutions we 
come up with being used in concert, to give folks a sense of how there 
is a coherent solution that combines these things together.

Another thing we've discussed in this thread was whether some of the 
problems being solved by SBCs were ones for which there were already 
standards track alternative solutions. An example of this is NAT 
traversal, of course. SBCs list this as a primary function, yet we 
already have a solution based on STUn/TURN/ICE. So, do we do anything 
here? In these cases, I think we need to look at the reason why the 
standard solutions are not being used. I can think of a few reasons:

1. the standards solutions are missing some kind of important feature

2. the standards solutions require support in endpoints, proxies or 
other places, and it is easier to deploy a "single box" solution that 
allows a problem to be addressed by inserting a single box without 
having to change anything else in the network

If we conclude that the problem being addressed is in category (2), that 
is something I do not think we need to do any further work on here in 
IETF. These reasons eventually evaporate once the standard solutions get 
implemented. A problem in category (1) is more problematic, and we 
should consider those to determine whether or not we believe there are 
new requirements not already considered in our solutions.

HTH,
Jonathan R.

Paul Kyzivat wrote:

> 
> 
> Medhavi Bhatia wrote:
> 
>> I don’t think the SBC is any “SIP entity”. SBC is just a marketing 
>> term, providing mostly security functions at this point.
> 
> 
>> If this entity is performing some NAT functions or transcoding like 
>> SDP rewriting, then we need a B2B UA (there are non-compliant SIP ALGs 
>> which perform SDP re-writing, but lets consider those as a separate 
>> problem). For transcoding, the SBC may make the transcoding decision 
>> and send the call to a transcoder. In this case, the SBC could be a 
>> SIP Proxy and the transcoder a B2BUA. Similarly for QoS borders, SDP 
>> inspection may be required rather than rewrites at the SBC. This could 
>> be done using a SIP Proxy as well, but requires SDP inspection.
>>
>> If the SBC is generating new messages on behalf of either endpoints, 
>> it needs to be a B2BUA.
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 1 Mar 2005 13:05:05 -0000

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 3 Mar 2005 08:02:32 -0600

Completely agree with Keith.

How can we make this happen?

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

  regards

  Keith

---

From: [email-masked]
Date: Thu, 3 Mar 2005 18:59:25 -0500

Also complete agreement with Keith and Spencer.
 
Thanks, Henry

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Spencer Dawkins
Sent: Thursday, March 03, 2005 9:03 AM
To: [email-masked]
Subject: Re: [Sipping] Draft: Functions of Current SBCs

 
Spencer

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

 

 
 
regards
 
Keith