[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00)
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:lendl at labs.nic.at] On Behalf Of Otmar Lendl
Sent: Monday, April 07, 2008 5:00 AM
To: Brian Rosen
Cc: 'Paul Kyzivat'; 'Richard Shockey'; enum at ietf.org; '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 <br at brianrosen.net> 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 <lendl at nic.at>, 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
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum