[SIPForum-techwg] Registration Mode on Large PBXs

Wed Feb 11 16:23:42 EST 2009

I agree as well.  If you try to operate some PBXes without DNS, many,
many things break - it is just part of their fundamental design for
peering.  On the other hand, some PBXes act like SIP phones, and do not
rely on DNS for reachability.

Forcing a SIP PBX which operates according to RFC 3261 principles and
rules to try to pretend like it doesn't rely on DNS for reachability
just makes no sense at all.

Thanks,
Alan

________________________________

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

I agree with this.

John

________________________________

	From: techwg-bounces at sipforum.org
[mailto:techwg-bounces at sipforum.org] On Behalf Of Francois Audet
	Sent: 11 February 2009 05:22
	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.

	On Feb10 2009 20:36 , "Chris Gatch" <Chris.Gatch at cbeyond.net>
wrote:

	One idea that seems established as fact on this list is that
registration mode is not practical or helpful on large-scale PBXs.
Based on my experience integrating with different PBXs and witnessing
different deployment scenarios, I don't agree.  Below are several
scenarios where I believe it benefits a large-scale PBX to support
registration mode.

	1)     Perhaps most obvious, large PBXs sometimes get deployed
in smaller environments.  Most large PBXs achieve scale through
deployment of multiple servers, and a small deployments with a single
server or HA pair into a small environment is not uncommon.  I see this
first hand at Cbeyond that customers do indeed deploy a system like
Cisco Call Manager into small and medium business environments.  

	2)     A large PBX requires connectivity with multiple SIP
Trunking partners.  We see some customers who have primary SIP trunking
service with one service provider and then establish service with
another provider for very specific services like LD to a particular
international market.  In this case, the small scale of the relationship
with the secondary supplier makes the simplicity of registration of
value versus static peering.  Often these providers are 'over the top'
VoIP companies.

	3)     Simplicity equals less cost.  There is no doubt that
registration mode works and it's easy.  A medium or even large business
can buy a 'large PBX" and configure it for service using registration
mode without touching anything else.  Assuming that medium business does
not have an IT guy and needs to configure the system for static
connectivity, they will first need a VAR to configure the PBX for them.
But wait, he's probably not the same guy that manages the firewall for
that medium business, which needs to be configured.  So the owner will
connect the PBX guy with the firewall guy, someone will call the service
provider, and maybe eventually they will get it to work.  And then the
business owner will get a bill for $2000 in consulting fees.  Buyers
find value in simplicity. They don't give a crap about 99% of the stuff
we talk about on this list.

	4)     Using registration mode, it provides a crude form of
availability information about the PBX for the service provider.  The
Broadsoft platform in R14, for example, employs a feature that
automatically triggers a special form of call forwarding when a PBX
connected via SIPconnect becomes unregistered.  This is a nice way to
add an additional layer of redundancy that all PBX buyers appreciate,
not just small ones.  I'm sure there is a way to implement this is
static mode, but the registration allows proactive notification from the
PBX when it is again available.  I don't believe you would get this is
in static mode.

	I'm sure there are many other ideas as well, and I would
challenge those in opposition to registration mode to look at the
problem from the customer angle. How many customers ever complain about
having a choice? "No, large PBX maker, I want less options for
interoperability"  Instead of blocking registration mode, let's get it
out there and let the market decide when it's in their advantage to use
it.

	Chris

________________________________

	_______________________________________________
	techwg mailing list
	Send mail to: techwg at sipforum.org
	Unsubscribe or edit options at:
http://sipforum.org/mailman/listinfo/techwg

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