RE: [Sipping] Details on SBC

["Baruch Sterman" <[e-mail]>]

You may want to take a look at:
NAT Traversal in SIP
http://www.kayote.com/web/docs/Kayote_NAT_White_Paper.pdf

Baruch

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Samir Chatterjee
Sent: Saturday, May 07, 2005 1:53 AM
To: James M. Polk; [e-mail]
Subject: RE: [Sipping] Details on SBC

We are particularly interested in how SBCs solve the NAT/FW issues with
SIP. Most stuff out there seems to be proprietary. Jasomi appears to be
a leading vendor but absolutely no documentation available.
But thanks for your pointers and insight.


Dr. Samir Chatterjee
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

-----Original Message-----
From: James M. Polk [mailto:[e-mail]] 
Sent: Friday, May 06, 2005 4:45 PM
To: Samir Chatterjee; [e-mail]
Subject: Re: [Sipping] Details on SBC

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



_______________________________________________
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