On 4/3/07, <b class="gmail_sendername">Olle E Johansson</b> <<a href="mailto:oej@edvina.net">oej@edvina.net</a>> wrote:<div><span class="gmail_quote"></span><div><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> I turned on the "early dial" option on the GXP, which causes each<br>> digit to be sent as it is pressed, and the user response was much<br>> more favourable. Now I come to set up my international dialplans
<br>> and I'm running into a problem.</blockquote><div><br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">You are assuming that SIP works like zaptel in the dialplan, but it
<br>does not. You propably need to re-configure your phones.<br><br><br></blockquote></div><br>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.
<br><br>The process flow for the GXP2000 out of the box is:<br><br>1. user starts dialing<br>2. GXP collects digits until the keypad timeout (default 4 seconds) expires or the # button is pressed<br>3. GXP sends entire dialstring as an INVITE, to get back something from *, typically a 404 or 100
<br><br>If you turn on early dialing (against * v1.2), then the process changes to<br><br>1. user starts dialing<br>2. digit is sent as an invite, GXP waits for 100/404/484<br>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
<br>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<br><br>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.
<br><br>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?
<br><br>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.
<br><br>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.
<br><br>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.
<br><br>-- <br>j.