Re: [Sipping] Details on SBC

["James M. Polk" <[e-mail]>]

At 03:37 PM 5/6/2005 -0700, Samir Chatterjee wrote:
>Hi:
>
>We are looking for some details on SBC and how they work in terms of call 
>flows etc. Any pointers?

SIP is a peer-to-peer protocol with defined elements (UA, UAC, UAS, Proxy, 
Registrar, etc); an "SBC" is not one of them.

SBC - as in "Session Border Controller" - is a marketing term.

There was a ADHOC BoF at the November (2004) IETF to discuss the 
requirements for SBC - to see if there were sufficient interest and 
sufficiently different requirements on the SIP protocol that energy ought 
to be spent doing a proper gap analysis for those requirements and openly 
discuss in the SIPPING WG what should be done about those gaps. There are 
two individual IDs discussing the requirements for SBCs in SIP as a result 
of this BoF:

draft-camarillo-sipping-sbc-funcs-00.txt
draft-bhatia-sipping-sbc-00

Both IDs were discussed at the last IETF meeting (March 05) in Minneapolis 
for a total of 10 minutes. I don't remember anything especially important 
coming out of those discussions. The notes of the meeting state the two IDs 
will be merged into one for the next meeting.

One of the problems I see (from my point of view) is the current plethora 
of definitions for what an SBC is and what an SBC should do/accomplish. It 
appeared to me in the BoF that nearly everyone in the room had a differing 
opinion on this one question - so there was not much progress that night.

An SBC can be as simple as a SIP Proxy (RFC 3261) with various levels of 
state maintained per session and/or per dialog. These various levels are 
attributed to the differing definitions for what an SBC is to do.

- Some wanted NAT traversal to be solved by SBCs..
- Some wanted IPv4 to IPv6 conversion to be solved by SBCs...
- Some wanted SBCs to be what some of us thought was defined as a Middlebox 
from the MIDCOM WG efforts (that weren't too successful)...
- Some wanted SBCs to terminate media streams and regenerate those streams 
out the other side of the SBC for control and privacy purposes...
- Some wanted SBCs to terminate encrypted media flows on one side of the 
SBC and initiate new encrypted corresponding ones on the other side of the 
SBC for control and privacy purposes...
- Some thought an SBC could solve an administrative domain's QoS issues for 
voice and video traffic...

The message types in the messages flows you seek will be highly dependent 
on what you want an SBC to accomplish from the list above (and other items 
not on this list).

Question to you - what combination of functions do you want an SBC to 
accomplish?

 From that or from those functions - you ought to be able to build the 
flows if you know SIP.


>Dr. Samir Chatterjee
>Founding Director, NCL http://ncl.cgu.edu
>School of Information Science
>Claremont Graduate University
>130 East 9th Street
>Claremont, CA 91711
>(P) 909-607-4651
>(F) 909-621-8564
>
>http://fac.cgu.edu/~chatters
>
>
>_______________________________________________
>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use [e-mail] for questions on current sip
>Use [e-mail] for new developments of core SIP


cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

                      Alas, few *truths* exist without the math.

                             ...all else is a matter of perspective

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP