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

From: "Parolkar, Satish" <[email-masked]>
Date: Thu, 17 Feb 2005 12:11:30 -0600

Shai,

Need few clarifications...
See enquiries in-line [SP]....

Satish

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

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.

[SP] Why Session Admission Control? I presume Session Admission Control
is suggested to avoid congestion on the Enterprise WAN links or on
Carrier Core Networks. But, there will be other traffic on those links,
Video Streams, E-mail, FTP. How will Session Admission Control help
protect against latency and jitter issues that result due to congestion
on Enterprise links?

- 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.

[SP] How would the Session Border Controller know the processing
capacities of the SIP Proxies?

- 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.

[SP] Will there be a standardization of policies handled by Session
Border Controllers? Is there a need to identify what policies are
handled by SIP Proxy and which by Session Border Controllers? Just an
example...What if a source floods a network domain with perfectly
acceptable SIP INVITES but requests an unsupported Codec in the SDP? Who
will be responsible to block such requests?  

- 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.

[SP] How can a Session Border Controller (measure) identify the latency.
Isn't RTP timestamp generated at the source and destination. The Session
Border Controller will not be able to determine end-to-end latency which
is of importance to understand end-to-end quality.

- 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.

[SP] Which Carrier's? Is it better to negotiate Codecs between
end-points or to transcode? EndPoints support multiple Codecs.

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).

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: Tuesday, February 15, 2005 4: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.
> 
> 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-sb
> c-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
> 

_______________________________________________
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: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 17 Feb 2005 18:45:25 -0500

This raises the question of whether the assumptions underlying the SBC
is fully fleshed out.  

For example, does an SBC assume that the data interconnections between
networks support only voice connections?

There may be other operating assumptions.

Mike 

>[mailto:[email-masked]] On Behalf Of Parolkar, Satish
>Sent: Thursday, February 17, 2005 1:12 PM
>To: Shai Mohaban; Gonzalo Camarillo; sipping
>[mailto:[email-masked]] On Behalf Of Shai Mohaban
>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.
>
>[SP] Why Session Admission Control? I presume Session 
>Admission Control is suggested to avoid congestion on the 
>Enterprise WAN links or on Carrier Core Networks. But, there 
>will be other traffic on those links, Video Streams, E-mail, 
>FTP. How will Session Admission Control help protect against 
>latency and jitter issues that result due to congestion on 
>Enterprise links?
>
>- 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.
>
>[SP] How would the Session Border Controller know the 
>processing capacities of the SIP Proxies?
>
>- 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
>[SP] Will there be a standardization of policies handled by 
>Session Border Controllers? Is there a need to identify what 
>policies are handled by SIP Proxy and which by Session Border 
>Controllers? Just an example...What if a source floods a 
>network domain with perfectly acceptable SIP INVITES but 
>requests an unsupported Codec in the SDP? Who will be 
>responsible to block such requests?  
>
>- 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 
>Isn't RTP timestamp generated at the source and destination. 
>The Session Border Controller will not be able to determine 
>end-to-end latency which is of importance to understand 
>end-to-end quality.
>
>- 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).
>
>
>[email-masked] for questions on current sip 
>[email-masked] for questions on current sip

---

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

Consider the example I gave below when there are three NATs, the end users
not available of the "middle" NAT.

-Medhavi.

> From: Medhavi Bhatia [mailto:[email-masked]]
> Sent: Friday, February 18, 2005 10:02 AM
> To: 'Arjun Roychowdhury'; 'Jani Hautakorpi'
> Cc: 'sipping'
> 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.
Behalf Of Arjun
> > Roychowdhury
> > Sent: Friday, February 18, 2005 8:14 AM
> > To: Jani Hautakorpi
> > Cc: sipping
> > Subject: Re: [Sipping] Draft: Functions of Current SBCs
> >
> > On Fri, 18 Feb 2005 10:39:13 +0200, Jani Hautakorpi
> > > 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.
> > >
> >
> > 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: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 24 Feb 2005 06:45:36 -0600

Thanks Christer,

That is the best consise response/comment on this topic to date. Even, us, service providers that deploy SBCs and/or SBC like functions, have a need to "identify how a SBC affects SIP", and work on ways to address these.

Cheers,

Martin

>>>Christer Wrote on 2/23/2005 at 11:17am

Hi,

I agree with Gonzalo. We can list all the functions in the world, and I'm sure it's interesting reading to many people, but at the end we should identify how and what affects SIP and SIP procedures. 

Please also remember that WE, if I've understood correctly, invited the SBC vendors to provide information about what functions the SBCs provide - NOT to argue whether they are bad or not.

There has also been a few mails about where in a network the SBCs can be located. I also think that we need to remember that there may be more than one SBC between the end-users, and that must be taken into consideration when the "toolbox" is extended... 

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 24 Feb 2005 16:02:30 -0500

Henry,
 
Yes.  And now have WiFi-based UA1 go visit UA2 and still be able to
send/receive calls.
 
Mike
 
p.s.  all your single and double lines are NATs if some have their way.

________________________________

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

	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,
	 
	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

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sun, 27 Feb 2005 19:35:41 +0100

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.

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:

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: "Roy, Radhika" <[email-masked]>
Date: Mon, 28 Feb 2005 07:34:19 -0500

Medhavi:
 
We did discuss this during RFC 3261 (Jonathan R. - is this ALG example for modifying SDP an exception or we are missing something?). 
 
We did NOT agree that a SIP Proxy will be allowed to change SDP. It is fundamental, like Web, to SIP standards. It is a very serious thing because it will have basic implications in designing of all SIP products.
 
By the way, in 3rd Party Controller RFC, it is defined as a B2BUA. So, is the case of Transcoder (Exploder and others).
 
If you want to change this, let us "standardize" it right from the beginning instead of "twisting" it creating confusions.
 
Radhika

From: Medhavi Bhatia [mailto:[email-masked]]
Sent: Sun 2/27/2005 10:20 PM
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: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Feb 2005 12:13:07 -0500

Brian,

I agree with you up to a point. But I also think that part of the 
recommendation may very well be "if you do X and Y then you are a Z - 
but a conforming Z doesn't do Y at all. Instead, the function of Y is 
achieved in another way that doesn't involve a Z."

(E.g. Z is an SBC and Y is SDP rewriting.)

	Paul

Brian Rosen wrote:
> Gonzalo
> 
> We are all a little caught in the "deer in the headlights" phenomenon of
> wishing middleboxes would go away and realizing that they aren't, and
> recognizing that ignoring them makes the problem worse, not better.
> 
> We can all agree, I believe, that marketing departments will call anything
> they market by any name they wish, and we can't do anything about that.
> 
> Nevertheless, I think we have to accept that there is a device called an
> SBC, and, with the possible differentiation Henry notes (enterprise/consumer
> vs carrier), are pretty recognizable beasts.  I think we CAN come up with a
> reasonably helpful list of common functions they do.
> 
> I think such a list is useful, and that includes the functions that they do
> which we would all class as "normal".  It is useful because we can then
> point to that list and say "if you do these things, you are an SBC, and we
> ask you to behave in a particular way", which I believe is the goal of this
> work: to specify "good behaviors" for the things that SBCs do.  Good
> behaviors include "normal" behaviors, and I for one think it is useful to
> say what they are.  
> 
> The reason is simple: if we define the list as the function of the device,
> rather than the mechanism, then we can choose the most appropriate
> mechanisms and recommend them.  That will, I hope, prevent some from
> choosing some other, less appropriate behavior for that function.
> 
> Brian
> 
> 
>>From: Gonzalo Camarillo [mailto:[email-masked]]
>>Sent: Monday, February 28, 2005 11:42 AM
>>To: Paul Kyzivat
>>Cc: Brian Rosen; 'Bob Penfield'; 'Alan Hawrylyshen'; 'Christer Holmberg
>>(JO/LMF)'; 'David R Oran'; 'Shai Mohaban'; 'sipping'
>>Paul,
>>if your box performs one of the functions proxies perform (e.g., rewrite
>>the Request-URI), you can call it an SBC, or whatever name you wish, but
>>it will be a proxy and there will be nothing new to specify there.
>>
>>I was referring to functions that may go against the SIP spec (e.g., SDP
>>rewriting). We need to document them and come up with alternative
>>solutions (e.g., session policies) that are, as people usually put it,
>>"SIP friendly".
>>
>>Thanks,
>>
>>Gonzalo
>>
>>
>>Paul Kyzivat wrote:
>>
>>>
>>>Gonzalo Camarillo wrote:
>>>
>>>
>>>>Brian,
>>>>
>>>>I agree with documenting:
>>>>1) bad behavior -- we have better answers
>>>>2) bad behavior - we need to do something
>>>>
>>>>although the better answers would not be documented in this document.
>>>>
>>>>Still, I would not like to document here normal behavior, for the
>>>>reasons given before in this thread.
>>>
>>>
>>>Gonzalo - the problem here is that there is no "normal behavior" for a
>>>B2UA or an SBC. There are behaviors that might be "normal" for a proxy.
>>>But then people deploy an SBC instead of a proxy. Whether the SBC
>>>performs functions that are normal to a proxy or not is of interest.
>>>
>>>It is good however if certain behavior can be described simply, by
>>>relating it to already defined behavior for other kinds of sip
>>
>>components.
>>
>>>    Paul
>>>
>>>
>>>>Thanks,
>>>>
>>>>Gonzalo
>>>>
>>>>Brian Rosen wrote:
>>>>
>>>>
>>>>>Wouldn't it actually make sense to go ahead and list all the
>>>>
>>functions,
>>
>>>>>classify them (normal behavior, bad behavior -- we have better
>>>>
>>answers,
>>
>>>>>bad behavior - we need to do something, ...) and then go work on the
>>>>>parts
>>>>>that need attention?
>>>>>
>>>>>I don't want to revisit this again later and have to go through that
>>>>>work
>>>>>again.
>>>>>
>>>>>Brian
>>>>>
>>>>>
>>>>>
>>>>>>Behalf
>>>>>>Of Christer Holmberg (JO/LMF)
>>>>>>Sent: Wednesday, February 23, 2005 11:17 AM
>>>>>>To: Gonzalo Camarillo (JO/LMF); Shai Mohaban
>>>>>>Cc: 'Bob Penfield'; 'David R Oran'; 'Alan Hawrylyshen'; 'sipping'
>>>>>>I agree with Gonzalo. We can list all the functions in the world,
>>>>>>and I'm
>>>>>>sure it's interesting reading to many people, but at the end we
>>>>>
>>should
>>
>>>>>>identify how and what affects SIP and SIP procedures.
>>>>>>
>>>>>>Please also remember that WE, if I've understood correctly, invited
>>>>>
>>the
>>
>>>>>>SBC vendors to provide information about what functions the SBCs
>>>>>>provide -
>>>>>>NOT to argue whether they are bad or not.
>>>>>>
>>>>>>There has also been a few mails about where in a network the SBCs
>>>>>>can be
>>>>>>located. I also think that we need to remember that there may be
>>>>>>more than
>>>>>>one SBC between the end-users, and that must be taken into
>>>>>>consideration
>>>>>>when the "toolbox" is extended...
>>>>>>
>>>>>>
>>>>>>Regards,
>>>>>>
>>>>>>Christer Holmberg
>>>>>>Ericsson Finland
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>From: [email-masked] [mailto:[email-masked]]
>>>>>>>Sent: 21. helmikuuta 2005 14:12
>>>>>>>To: Shai Mohaban
>>>>>>>Cc: 'Bob Penfield'; 'sipping'; 'Alan Hawrylyshen'; 'David R Oran'
>>>>>>>>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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>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...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>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
>>>>>>>
>>>>>>>
>>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: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 28 Feb 2005 12:56:20 -0500

One of the issues is that the SBC wants to be as transparent as
possible, but still may need to interject messages into the flow to
"guide" the UAC or UAS to a better way of interacting with the distant
UA.  While the intermediate is not supposed to (in most cases) generate
messages or responses, perhaps relaxing that could help solve the "don't
rewrite SDP" goal.  

For example, a 3xx Try This response from the SBC to the UAC with the
"new and improved" SDP.  Or perhaps, some new method INFORM to
immediately follow an incoming INVITE to let the UAS know what network
parameters will work best for the identified INVITE to be used in
response to that INVITE.

Mike

>[mailto:[email-masked]] On Behalf Of Paul Kyzivat (pkyzivat)
>Sent: Monday, February 28, 2005 12:06 PM
>To: Gonzalo Camarillo
>Cc: 'Bob Penfield'; 'Alan Hawrylyshen'; 'Christer Holmberg 
>(JO/LMF)'; 'sipping'; 'Shai Mohaban'; Dave Oran (oran)
>If some incarnation of an SBC is really "just" a proxy, then I 
>agree with you. But if it is in reality a B2BUA, which tries 
>to be transparent and perform functions that otherwise might 
>be done by a proxy, as well as a few that can't be done by a 
>proxy, then I would like to understand that by having it spelled out.
>
>For instance, hypothetically we might have a device that:
>- is inserted in path via Route header
>- forwards messages in both directions like a proxy
>- preserves dialog info like a proxy
>   (from/to tags, callid cseq)
>- alters From and To URIs like a B2BUA
>- alters SDP like a B2BUA
>- based on altered SDP, terminates and reoriginates
>   RTP media streams.
>
>This is neither fish nor fowl. I want to know about the 
>proxy-like things it does as part of the context to 
>understanding it in full.
>
>	Paul
>
>Gonzalo Camarillo wrote:
>> Paul,
>> 
>> if your box performs one of the functions proxies perform (e.g., 
>> rewrite the Request-URI), you can call it an SBC, or 
>whatever name you 
>> wish, but it will be a proxy and there will be nothing new 
>to specify there.
>> 
>> I was referring to functions that may go against the SIP spec (e.g., 
>> SDP rewriting). We need to document them and come up with 
>alternative 
>>> Gonzalo - the problem here is that there is no "normal 
>behavior" for 
>>> a B2UA or an SBC. There are behaviors that might be "normal" for a 
>>> proxy. But then people deploy an SBC instead of a proxy. 
>Whether the 
>>> SBC performs functions that are normal to a proxy or not is 
>of interest.
>>>
>>>>> functions, classify them (normal behavior, bad behavior 
>-- we have 
>>>>> better answers, bad behavior - we need to do something, ...) and 
>>>>> then go work on the parts that need attention?
>>>>>
>>>>> I don't want to revisit this again later and have to go through 
>>>>> that work again.
>>>>>
>>>>> Brian
>>>>>
>>>>>
>>>>>> On Behalf Of Christer Holmberg (JO/LMF)
>>>>>> sure it's interesting reading to many people, but at the 
>end we should
>>>>>>>> worthwhile to describe why carriers are using these 
>devices today in
>>>>>>>> general...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sipping mailing list  
>https://www1.ietf.org/mailman/listinfo/sipping
>>>>>> Sipping mailing list  
>https://www1.ietf.org/mailman/listinfo/sipping

---

From: "Roy, Radhika" <[email-masked]>
Date: Mon, 28 Feb 2005 13:10:48 -0500

It sounds like functionalities similar to that of the SIP Redirect server. It is not a bad idea if you still want to preserve the SIP standards. If needed, we can standardize new METHODs.
 
The other approach has been: To keep the functionalities in the hand of the middle box like SBC. The pros and cons of this method need to be compared to that of the above approach.
 
Radhika

From: [email-masked] on behalf of Michael Hammer (mhammer)
Sent: Mon 2/28/2005 12:56 PM
To: Paul Kyzivat (pkyzivat); Gonzalo Camarillo
Cc: Bob Penfield; Alan Hawrylyshen; Christer Holmberg (JO/LMF); sipping; Shai Mohaban; Dave Oran (oran)
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Mike

---

From: "Roy, Radhika" <[email-masked]>
Date: Mon, 28 Feb 2005 14:40:47 -0500

True.
 
Any middle boxes (e.g., 3rd party call controller, transcoder, exploder, XCON conf server, etc.) will also accept calls from other intermediaries like SIP proxies and will route the call to them, if needed.
 
So, the properties of the SBC is not different from any other middle boxes per SIP rules. 
 
The only difference is the kind of service-specific properties among all of them.
 
Radhika

From: Medhavi Bhatia [mailto:[email-masked]]
Sent: Mon 2/28/2005 1:38 PM
To: Roy, Radhika; 'Gonzalo Camarillo'
Cc: 'Bob Penfield'; 'Alan Hawrylyshen'; 'Christer Holmberg (JO/LMF)'; 'David R Oran'; 'Paul Kyzivat'; 'sipping'; 'Shai Mohaban'
Subject: RE: [Sipping] Draft: Functions of Current SBCs

I guess the difference may be, as a user agent, I routed my call to the service. With the SBC, it is like an intermediary, maybe accepting calls from other intermediaries (like proxies) and routing calls to them. 

Medhavi.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roy, Radhika
Sent: Monday, February 28, 2005 1:30 PM
To: Gonzalo Camarillo
Cc: Bob Penfield; Alan Hawrylyshen; Christer Holmberg (JO/LMF); David R Oran; Paul Kyzivat; sipping; Shai Mohaban
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Hi,

I agree that we may not be able to provide names for devices other than some functionalities. Hope that we would have one in a more generic way like Middle box, etc.

The question is this: Will we ever be able to "generalize" the behavior with one "shot" just what you have indicated?

If we could, we it would be the best. I wish you "Good Luck!" You have my full support.

I would also request to see why are we defining (or have defined) the services like 3rd party call controller, transcoder, exploder, centralized SIP-based conferencing (XCON), etc where all of them are acting as a kind of "Middle Box" in the network for providing services to the endpoints (presumably SIP UAs)?

Does it not point out that we better take another approach, for example, service-specific solutions?

Best regards,

Radhika

From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Mon 2/28/2005 1:04 PM
To: Roy, Radhika
Cc: Paul Kyzivat; Bob Penfield; Alan Hawrylyshen; Christer Holmberg (JO/LMF); sipping; Shai Mohaban; David R Oran
Subject: Re: [Sipping] Draft: Functions of Current SBCs

Hi,

I actually do not think that having a definition of a device that is
called SBC would help. Having different definitions for different types
of SBCs would not help either, IMO.

I would rather say: "if you perform this function in this way, you are
not a SIP compliant device. But you can perform the same function in
this other way, and you will be compliant".

Of course, we need to explain the advantages of being compliant (e.g.,
faster service deployment and more innovations)

Gonzalo

Roy, Radhika wrote:
> Agreed.
> 
> It is a fact that a "device" can do many things (as stated below by
> Paul).
> 
> A "device" can be built to act the UA, Proxy, B2BUA, RTP-aware/dealing
> with media, location server, and/or many other things.
> 
> Based on some pre-define service logic, we can define a "device," for
> example, as follows:
> 
> 1. 3rd Party Call Controller
> 2. Transcoder
> 3. Exploder
> 4. Media Bridge
> 4. Anonymizer (SIP Proxy with B2BUA to provide a lot of services
> transparent to users)
> 5. Others
> 
> Radhika
>

---

From: "Andrew Graydon" <[email-masked]>
Date: Mon, 28 Feb 2005 22:47:17 -0500

I fully agree with you that the definition currently being talked about
for an SBC is what you would classify below as a 'device' and not
necessarily a standard. There are many functions that are provided by
the current SBC incarnations and proposed in the Edge Proxy by ourselves
that will further the security aspects of SIP and could be transformed
into a standard, one of the reasons we asked people to look and discuss
the discussion paper we sent, but the current discussion is off the
standards track.

We need to revisit the full SIP message flow between the endpoint and
the variety of topologies that it may pass through, and discuss where
the security points must be and what functionality must be involved, and
then decide on whether this group wants to discuss this as a standard or
a best practice.

Andrew

________________________________________________________________________
Andrew Graydon                                 Phone: 905-804-1855 x289
V.P. Technology                                Fax:   905-804-1865
Borderware Technologies Inc.                   http://www.borderware.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: February 28, 2005 12:06 PM
To: Gonzalo Camarillo
Cc: 'Bob Penfield'; 'Alan Hawrylyshen'; 'Christer Holmberg (JO/LMF)';
'sipping'; 'Shai Mohaban'; 'David R Oran'
Subject: Re: [Sipping] Draft: Functions of Current SBCs

Gonzalo,

If some incarnation of an SBC is really "just" a proxy, then I agree
with you. But if it is in reality a B2BUA, which tries to be transparent
and perform functions that otherwise might be done by a proxy, as well
as a few that can't be done by a proxy, then I would like to understand
that by having it spelled out.

This is neither fish nor fowl. I want to know about the proxy-like
things it does as part of the context to understanding it in full.

	Paul

Gonzalo Camarillo wrote:
> rewrite the Request-URI), you can call it an SBC, or whatever name you

> wish, but it will be a proxy and there will be nothing new to specify
there.
> SDP rewriting). We need to document them and come up with alternative 

>> Gonzalo - the problem here is that there is no "normal behavior" for 
>> proxy. But then people deploy an SBC instead of a proxy. Whether the 
>> SBC performs functions that are normal to a proxy or not is of
interest.
>>>> functions, classify them (normal behavior, bad behavior -- we have 
should
introduction,
>>>>>>> worthwhile to describe why carriers are using these devices
today in