Scott Lawrence wrote: > 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. >
Makes sense to me. Didn't see any counter arguments so I marked XX-6605 as "won't fix". D. _______________________________________________ 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/
