[SIPForum-techwg] Who is the audience for SIPconnect 1.1? Who will be certified? Why are we building it?

Dan York dyork at voxeo.com
Tue May 20 11:11:37 EDT 2008


I've been offline for most of the past 5 days (buying a house,  
starting moving, etc.) and after seeing the flurry of messages about  
SIPconnect 1.1 fly by my Blackberry during that time, I sat down and  
read through them all this morning.  In doing so, it seemed to me that  
as we were diving into the protocol details, are we sure we are all in  
agreement on WHY we are building "SIPconnect 1.1"?

If I go back to the SIPconnect page on the SIP Forum web site:

http://www.sipforum.org/content/view/273/227/

it seems to me that this can be basically summarized as:

- We are seeking to create "plug and play" SIP interoperability  
between premise equipment and service providers.

The idea being that any "SIPconnect-compliant" IP-PBX (or other  
premise device) can connect via a "SIP trunk" to a "SIPconnect- 
compliant" Service Provider with extremely little interop testing (in  
the *ideal* world, none).

If a customer buys a SIPconnect-compliant premise product, they should  
be able to contract with a SIPconnect-compliant service provider...  
connect the premise product to the network and... ta da... start  
making calls.

Are we in agreement that this is the end goal of the SIPconnect  
program (as it is formulated today)?

If we aren't in agreement on that (subject to the inevitable  
wordsmithing of my summary), then I think we need to have that  
discussion to ensure we're all in sync.

If we are in agreement, then a second set of questions comes to mind.  
Who are the vendors that are actually going to go through the  
SIPconnect 1.1 certification process?  What is the state of their  
deployed SIP infrastructure?  Would they meet a spec that documents  
current best practices?  Would they meet a spec that points to how we  
*want* SIP to be deployed?

To put it another way, what constitutes the "success" of the  
SIPconnect 1.1 program?  Is it 200 vendors who successfully implement  
a spec that some of us may have to reluctantly go along with (because,  
for instance, it allows SIP over UDP)?  Or is it 20 vendors that  
provide the kind of SIP interoperability we really want to see out  
there?  How widely do we want to see the "SIPconnect compliant" mark  
adopted?  Do we want every IP-PBX vendor to support it?  Do we want  
large numbers of Service Providers to adopt it?

How do we as the SIP Forum define "success" for this program?

I fully agree with the points made by several folks about the need to  
provide guidance/recommendations for how to do this "right".  I very  
much look forward to the day that we've truly built the pure IP  
interconnect and can leave the current PSTN and all its legacy  
problems behind.  Heck, those of you who know me know that I'd love  
everyone to be using TLS-encrypted SIP and SRTP.  Throw in wideband  
codecs, too, and we can show how amazingly better this world of SIP  
can be than the PSTN ever was.

But that's one kind of specification and one that, in my opinion,  
would not really be widely adopted. Even though SIP has been around  
for as long as it has, we have only to look at the latest SIPit  
results to see we still have a ways to go. Some % of vendors would  
certainly get on board, largely depending upon how much work it would  
take them to get to the point the spec requires, but it wouldn't be  
mass numbers.  Maybe that's okay.

The other kind of specification *does* document current best  
practices... perhaps pushing the edge a bit, but mostly showing how to  
create SIP connections *today* between premise products and service  
providers.  The bar is lowered and more people can potentially climb  
over it. Interoperability of "SIP trunking" gets pushed further along.  
The "SIPconnect-compliant" mark gets more widely distributed. (The SIP  
Forum also gets more funding to run the program through the larger  
number of participating vendors. ) The down side of this approach is  
that some of the ways of working with SIP that we don't want would  
stay around and potentially slow down the longer-term evolution of the  
full IP interconnect.

That seems to me to be our choice: do we want a spec that is adopted  
by a smaller number of vendors that requires doing SIP connections the  
"best" way?  Or do we want a spec that could potentially be adopted by  
a large number of vendors but allows current SIP usage that we'd like  
to get away from?

Either spec would be useful to the industry - but they are two very  
different documents.

My 2 cents,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     dyork at voxeo.com
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free







More information about the techwg mailing list