Re: Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00)
"Brian Rosen" <[email protected]>
| Newsgroups | gmane.ietf.enum |
|---|---|
| Message-ID | <[email protected]> |
Right. So, there is indeed a pretty substantial problem to do something sensible for a SIP version of this. The network could complete its processing of the call as soon as it has sufficient digits to route. The originating end however needs to know how many more digits there will be in order to actually send a complete INVITE, and the receiving end can't issue an 200 until it has all the digits. Seems like we have two choices, neither of them good. 1) We build a database which really is delegated out to enterprises, and require that they populate the database if they want to get calls, and have the originating side collect the right number of digits, and send a single INVITE with the correct telephone number 2) Have the originating side send an INVITE when it has at least the prefix number of digits, and then let the receiving end collect DTMF to determine the rest of the digits using early media. To get the right user experience, you can't complete the call until all the required digits are entered. Just another user experience question: Suppose there was a network busy condition. The user is going to get the error tone after they enter the prefix, but before they have completed dialing, right? Brian -----Original Message----- From: Otmar Lendl [mailto:[email protected]] On Behalf Of Otmar Lendl Sent: Monday, April 07, 2008 5:00 AM To: Brian Rosen Cc: 'Paul Kyzivat'; 'Richard Shockey'; [email protected]; 'Clive D.W. Feather'; 'Duane' Subject: Overlap dialing user experience (Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00) On 2008/04/04 19:04, Brian Rosen <[email protected]> wrote: > One thing I don't think we have to do is give the black phone or black phone > connected to TA a BETTER experience than they have now. > > Those of you in countries that allow this kind of "enterprise can define how > long the number is", what is the user experience? You can route as soon as > the prefix is entered. What is the user experience after that? What if > there was a short or a long pause between the prefix and one of the > internally consumed digits? After all, the originating switch doesn't know > how many digits the enterprise uses. The simple answer is: The user does not notice that the PBX on the terminating side is not integrated into the operator's switch. It's all completely transparent and realtime. Overlap dialing is an end-to-end feature: individual digits are passed from originating PBX, via originating carrier, via destiation carrier to the receiving PBX. Here are some D-channel traces to explain this (using Asterisk connected to a Colt ISDN PRI, calling is via Telekom Austria.) Lines starting with < are receiving, the ones with > are sent to the operator. I'm calling extension 300 on +43 1 25397. 1) Direct dialing (incl. extension) < Message type: SETUP (5) < Called Number (len= 6) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '300' ] New call coming in, indicting extension 300. Actually, it is a config option on an ISDN line whether these "Called Number" messages contains just the extension or the national number + extension. > Message type: SETUP ACKNOWLEDGE (13) > Message type: CONNECT (7) "300" is known, thus Asterisk accpects the call. < Message type: CONNECT ACKNOWLEDGE (15) 2) overlap dialing. On the sending side, all digits are passed one by one to the operator, the second I hit the '7' key, I see on the receiving side: < Message type: SETUP (5) There is no "called number" information element in the setup message > Message type: SETUP ACKNOWLEDGE (13) I continue dialing and see < Message type: INFORMATION (123) < Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '3' ] then: < Message type: INFORMATION (123) < Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '0' ] < Message type: INFORMATION (123) < Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '0' ] At this point, the Asterisk knows that the extension is complete and thus sends: > Message type: CONNECT (7) 3) Timeout (receiving side): Here is the case where the receiving side implements a timeout: Overlap-dialing till the 7, then waiting: < Message type: SETUP (5) (no called party IE) > Message type: SETUP ACKNOWLEDGE (13) (some seconds later) > Message type: CONNECT (7) 4) Timeout (sending side) I can't reproduce this right now, but I rememeber that when calling from a POTS phone, the network will issue a "SENDING COMPLETE" IE to the receiving ISDN line after a suitable delay. ------------ I hope this helps a bit. /ol -- // Otmar Lendl <[email protected]>, T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg