[asterisk-users] SIP 484 (Early Dial) and International Dialing

[James FitzGibbon]

On 4/3/07, Olle E Johansson <oej at edvina.net> wrote:

> I turned on the "early dial" option on the GXP, which causes each
> > digit to be sent as it is pressed, and the user response was much
> > more favourable.  Now I come to set up my international dialplans
> > and I'm running into a problem.




You are assuming that SIP works like zaptel in the dialplan, but it
> does not. You propably need to re-configure your phones.
>
>
>
I recognize the difference between Zaptel and SIP.  The option to turn on
'early dial' in the GXP2000 makes the user experience of dialing on a SIP
phone more like a Zaptel (or traditional analong phone).  SIP phones have
many similarities to cell phones, and while my users are familiar with the
"enter entire number then press send" concept, they don't seem to
intuitively apply it to their desk phones.

The process flow for the GXP2000 out of the box is:

1. user starts dialing
2. GXP collects digits until the keypad timeout (default 4 seconds) expires
or the # button is pressed
3. GXP sends entire dialstring as an INVITE, to get back something from *,
typically a 404 or 100

If you turn on early dialing (against * v1.2), then the process changes to

1. user starts dialing
2. digit is sent as an invite, GXP waits for 100/404/484
3. If 484 is received, GXP waits for next digit from the user.  When
received, both digits are sent as an invite, and the wait for 100/404/484
starts again
4. If the keypad timeout expires, the GXP looks to see if the last received
message was a 484.  If so, the user gets a congestion tone

The problem comes in with users who are used to dialing 9 and waiting for a
redial tone.  With early dial turned off, they hit 9, wait, don't get a
redial tone because there's no such thing in *.  If they start dialing the
rest of their number before the keypad timeout expires, then all is good.
If they don't, then the GXP sends an invite for '9', which get rejected with
a 404 or possibly handled using "Playback(pbx-invalid)" or something
similar.

You can avoid the potential for the timeout to expire by increasing it from
the default of 4 seconds to 5 or 6, but then you force users to press # or
wait for the initial INVITE to be sent when they dial an extension
correctly.  I've found this "dead time" to be a source of confusion and
frustration for users.  After all, if I know my buddy is at extension 301,
shouldn't the call go through the second I finish dialing the 1 key?

The early dial mode in the GXP allows you to set the timeout value higher
(to avoid sending the incomplete '9' invite) without the downside of forcing
correctly dialed extensions to timeout before the invite is sent.  It just
makes the phone work more like the way people are used to phones working.
Unfortunately, it has this downside when the number of digits in the
extension is variable, and I didn't account for this during planning.

I am thus left with a choice between preserving the traditional user
experience and letting calls to variable-length extensions work properly.
Or changing phones - obviously something with an on-phone dialplan would not
suffer from this problem, nor would it need something like early dial.

The DISA() solution works.  Once it's invoked, the user experience is just
like a Zap channel.  I was just hoping that there might be some "tips and
tricks" type of workaround for this situation.  If not, DISA() will service
my needs for now.

-- 
j.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20070403/e07c5338/attachment.htm