[SIPForum-techwg] Registration Mode on Large PBXs

[Richard Shockey]

In line..

 

From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
Behalf Of Hadriel Kaplan
Sent: Wednesday, February 11, 2009 6:41 PM
To: Francois Audet; Chris Gatch; techwg at sipforum.org
Subject: Re: [SIPForum-techwg] Registration Mode on Large PBXs

 

Any Enterprise of that type is hardly likely to use only SIP-Connect
profiles to begin with, as they'd probably have special needs for other
things anyway.  And that's ok - it's justified by the size of the
Enterprise.  Really, we're not talking about the SIP Trunks between American
Airlines and their provider(s).  That's the exception case, not the rule.

 

RS: For now perhaps. The goal was a interoperable specification for any
market size. granted SMB is the market target at this point for any number
of economic reasons . You are right .. any large enterprise of greater than
???? seats will always have special needs that the SSP will accommodate on a
more manually provisioned basis. 

 

RS: But Realistically . I should think Microsoft , Avaya, Siemens Enterprise
and Cisco are is very interested in SIP trunks between AA , Boeing Lufthansa
etal. Gee (maybe) even ATT ( well maybe not). 

 

My concern for this annex-a/b thing is that any vendor that makes a PBX that
doesn't have pseudo-registration capabilities now, regardless of their size
or intended market, will just claim compliance to the other non-registering
annex, and we're back to square one.  

 

RS:  Maybe. the concern I have now is even if you went to a MUST MUST
requirements the chances that "pseudo registration" capabilities could be
incorporated into Enterprise class products within 18 month product cycles
are slim to none.  And gee we be back to square one.  Not to pick on Cisco
but their product cycles are notorious.  As a theoretical matter MUST MUST
is the optimal solution but I'm trying to be realistic as well.

 

RS: From what I am hearing from the threads over the last few days there is
little if no desire on the part of the Large Enterprise PBX vendors to
support the REGISTER "pseudo-registration" methodology at all under any
conditions.  Am I wrong here? Most PBX vendors have different classes of
products for different market segments at different price points. I've lost
track of how many Cisco products there are. ( Just picking on Cisco) 

 

 

The fact is we need those PBX's to do it, for the SMB market scenario.  

 

RS: There is no argument about that. The economic rationale for
pseudo-registration AKA provisioning etc. is self evident. So where is the
demark between SMB and Enterprise?  

 

That market is about Enterprises that don't understand SIP, won't read RFCs,
won't go reading some SIP Forum spec for what "Annex-a" vs. "Annex-b" is,
and just expect things to work with minimal configuration.  

 

RS: Again the market TODAY is about SMB enterprises that don't understand
SIP. 

 

How about we do this: call the registration mode "SIP-Connect
Plug-and-Play", and call the static mode "SIP-Connect
Plug-and-setup-DNS-and-Firewall-and-wait-for-transaction-timeouts-to-get-fai
lover".  That will give them some clue at least about which one to look for.
J

 

 

The 2 state solution ? J Oh sorry that describes another  intractable
problem.

 

 

 

 

 

-hadriel

 

  _____  

From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
Behalf Of Francois Audet
Sent: Wednesday, February 11, 2009 12:22 AM
To: Chris Gatch; techwg at sipforum.org
Subject: Re: [SIPForum-techwg] Registration Mode on Large PBXs

 

The place where it is not practical is where the Enterprise network is,
well, a network of PBXs, using a proxy to communicate with the Service
provider. I.e., the peering model.

The PBX within the enterprises (or the SIP endpoints) may be doing
pseudo-registration and registration (respectively) to their own Enterprise
SIP proxy.

That Enterprise SIP proxy is unlikely to use this pseudo-registration
concept, and instead, probably has a concept of "federation" or "peering" or
"foreign domain" or whatever to communicate with the service provider. It
also is probably supporting the "real" SIP procedures using RFC 3263. They
may also have assigned the DNS entry for the Enterprise PBX to be sitting on
some proxy in the DMZ (or on an SBC). They may also use the same mechanism
for PEERING with other Enterprises, or, God Forbid, for using normal SIP
(even for things that are not voice calls using phone numbers). Consequently
it would be  MORE work for them to have a different mechanism for the
Service Provider.

In short, they may run their internal SIP network the way SIP is supposed to
be used, and will not see kindly being forced to do
"tricks-for-dummies-who-can't-setup-their-own-DNS-names".

I believe this would often applies to large PBXs too, not just networks.

So, my take is that rather than talking about arbitrary concepts of large
and small, we stick to a/b (or whatever it was that Eric Burger proposed),
and list the two modes. One is definitively targeted at environments where a
DNS name is not assigned to a PBX/Enterprise network, and another that is
targeted at environments where a DNS name for the PBX is available.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20090212/9280ebb5/attachment-0001.html