[SIPForum-techwg] Modest Proposal to Go Beyond Section 7

[Chris Gatch]

Speaking from the perspective of a service provider implementing the specification, it works fine.  And it's certainly an option that should satisfy most of the large PBX implementers who don't want to implement registration mode.

Speaking as one involved in the SIPconnect Compliant program, it's really not too ideal.  In order to avoid consumer confusion, it seems we will need to have SIPconnect Annex A and SIPconnect Annex B compliant programs, which forces the consumer to know the difference to determine interoperability.  This outcome I do not view favorably.

My view is that we should make both static and registration mode a MUST.  I don't think it's unreasonable to ask the small number of large-scale PBX manufacturers that have not yet implemented this capability to add it.   I am not persuaded by the arguments that it's not practical.  Many very large PBXs already support this capability, and even if a few don't think it's a good idea, the broader voice of the working group seems to disagree.

I think as service providers, infrastructure suppliers, and PBX manufacturers, we should all take the high road that leads to the broadest interoperability.  Anything less is a vote for PRI and analog lines to hang around that much longer.

With respect for my colleagues who disagree,

Chris

From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of Eric Burger
Sent: Sunday, February 08, 2009 1:39 PM
To: techwg at sipforum.org
Subject: [SIPForum-techwg] Modest Proposal to Go Beyond Section 7

Here is a modest proposal for breaking the logjam and moving forward on the Registration/Static provisioning problem.

First, some background. If we say something like "big PBXen acting as peers MUST do static mode and little PBXen acting as endpoint B2BUA's MUST do registrtion" is begging for interoperability and customer deployment failure.  There is no definition of either big or little.  Moreover, I do not want there to be a definition based on size, as we will have a 100% chance of getting it wrong.

I would also point out that saying SSE's MUST do both and the PBX MUST chose one requires manual configuration. Some service providers are unwilling to do such provisioning, and most enterprises will not have a clue they need to do. One of the major goals of SIPconnect is to reduce, not increase, the number of configuration options.

So, back to how to move forward. One could say the key distinction between the two models is not size, but peer versus B2BUA. Although almost a non sequitur, saying what we mean has value here. In fact,  I believe peer (static) versus B2BUA (registration) is the only distinction. Therefore, I would offer we do the unthinkable and say, as in 802.11, we have SIPconnect/1.1a and SIPconnect/1.1b, where {a,b} maps to {static,register}.

I do not see this as bifurcating SIPconnect. However, if we went with the MUST/MUST + MUST solution (current text), I foresee someone going on eBay, buying a Brand A IP-PBX that is SIPconnect/1.1 certified, and buys SIPconnect/1.1 trunks from Brand C. Surprise! They do not just work, because the IP-PBX expects static configuration, but the service provider, while able to offer static configuration, does not expect it.

Reiterating, the only difference for 'big' versus 'small' is this registration issue. Therefore, my proposal is:

Section 7:
State that registration occurs. If a product or service desires certification for SIPconnect/1.1a, the product or service MUST conform to the specification in Annex A of this document. If a product or service desires certification for SIPconnect/1.1b, the product or service MUST conform to the specification in Annex B.

Annex A:
Defines (clarifies) static registration. Move the text from Section 7.2 here.

Annex B:
Defines using REGISTER for registration. Move the text from Section 7.1 here.



This model worked for 802.11a and 802.11b, so hopefully it will work for us, too.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20090208/42a76fbe/attachment.html