On Thu, 2009-11-12 at 11:44 -0500, Damian Krzeminski wrote:
> http://track.sipfoundry.org/browse/XX-6605
>
> That seems to me like pushing the burden of configuring system properly to
> end user. Shouldn't administrator make sure the dial plans work reasonably
> with contact information?
>
> Don't get me wrong: it's trivial to add but how do we plan to explain end
> users what needs to be entered there?
This is one of those really obnoxious cases that arise when
administrators configure non-optional prefixes. Unfortunately, it does
not appear to be practical to forbid this or even to transmit high
voltages to the key board when it is requested... so we have to live
with the bad effects.
[Administrators - phone numbers should "just work", which means that you
should try to design your dial plans so that is true. We stopped
needing to use a prefix to 'seize' an outside line a long long time
ago... let go of the past...]
The approach we've tried to take for some time now is:
When configuring a number to which the system will send a call
(for example, when setting up forwarding or autoattendant call
targets), then should work to use any number that would work if
dialed from a SIP phone on the system, and not if such a call
would not.
This creates a problem if we provide ways for people to enter or import
numbers in "normal" forms. If I put my 'cell' number into the system as
'978-555-1133' (a "normal-looking" number for anyone in eastern
Massachusetts USA), should that work? That's probably the form I would
have in my Outlook contact (if I used Outlook and wasn't a telephony
geek). The problem it creates if administrators have used prefixes is
that in effect to use such 'normal' numbers we need _something_ that
understands how to apply the dial plans in reverse in order to generate
"dial strings" that, when then routed through the dial plan will
actually work. This is a very non-trivial problem.
The more narrowly defined problem that the issue was, if I recall,
designed to attack was the example that Peter cited:
> A specific use case implied by XX-6605 would involve the Personal
> Assistant (IM bot) user entering
>
> "call 63931211 from cell".
>
> The PA then makes a call to the cell phone and refers it to 63931211.
> The cell phone number entered by the user via sipXconfig does not
> start with a dialing prefix (eg. 9) so somewhere the dialing prefix to
> use must be defined either by the user or the administrator.
To expand that into a sequence of events, what we get is:
1. My system is in eastern Massachusetts USA, and my administrator
(against my advice) set up a dial plan in which I MUST put a '9'
prefix onto a 10 digit number.
2. I configure my 'cell' number in the system in the form my local
colleagues will expect and understand when they read it in the
Phonebook: '978-555-1133'.
3. I am at the shopping mall and want to call someone using the
office system, so I whip out my smart phone, log in to XMPP, and
enter the @call command (sound realistic? never mind):
@call 63931211 from cell
What should happen?
What the user (not me, actually, since I know better) expects is that
the system will first call my 'cell' number. When that call is answered
(hopefully by me and not my cell service voicemail), the system will
then blind transfer that call to 63931211 (which, for those of you not
in the know looks like an internal Nortel phone system number - the 6 is
a prefix digit, by the way).
This issue proposes that the system should somehow have a value
configured somewhere that can be prepended to my cell number to make
that first call work.
The problem I see with that is that dial plans can be arbitrarily
complicated - I've seen many sites where administrators set up multiple
prefixes for different purposes.
I think that the only approach that's really reasonable is to go back to
the rule we put in for forwards and transfers:
When configuring a number to which the system will send a call
(for example, when setting up forwarding or autoattendant call
targets), then should work to use any number that would work if
dialed from a SIP phone on the system, and not if such a call
would not.
so... if the user wants to be able to say "@call 63931211 from cell',
then there should be a configuration entry somewhere that maps 'cell' to
a dial string that would work if that user called it from a SIP phone on
the system.
I do _not_ think that any other approach will actually work in practice,
including having anyone separately enter a prefix.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
