Subject: Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt

From: Larry Cox <[email-masked]>
Date: Wed, 17 Nov 1999 21:06:40 -0700

At 05:06 PM 11/16/99 -0600, you wrote:
>>
>>...
>>
>
>There are a variety of problems here. The first is determining how
>intervening proxies will react. If, for example, a proxy is making
>decisions about where to forward messages based on a called party URI, 
>your suggestion would require it to understand ISUP (for interpretation 
>of SAM message). It also requires it to have number analysis code and 
>dialing plan information (potentially for the entire globe).

As you imply here this is simply not something that can be considered rational.

>
>The problem gets even stranger for redirect servers, which expect to
>be able to send an immediate response to an INVITE -- not sit around
>collecting digits.
>
>Basically, your suggestion forces overlapped dialing deep into each 
>and every SIP node in the network that is expected to receive calls 
>originating from the PSTN network.

For a significant transition period this will effectively be all nodes.

>
>I agree that this is a problem that needs to be solved if we intend
>to use SIP between two PSTN phones; but we need to find a better
>solution than tunelling SAMs all over the place.
>
>We shouldn't overlook human factors: it could be that customers are
>willing to, for example, be trained to press "#" at the end of a
>phone number to skip the post-dial-delay.
>

You have pointed out quite clearly some of the problems that I have been
thinking about for some time. It also appears that a compelling answer to
the question will not be easily found.

Since there will be a significant interim period during which SIP systems
will represent a small percentage of total calls routed, it must be
possible to provide seamless inter-operation with the PSTN if SIP is to be
an acceptable call control protocol outside of private networks. This
precludes requiring a # digit at the end of the digit string.

Since knowledge of the required number of routing digits in many parts of
the world is local information subject to change at random intervals,
waiting for a timeout is the only reliable way to be sure that all digits
are collected. This tends to introduce a significant perception of
unreliable call switching. It appears that it would be much better to find
an alternative.

I agree that sending SAMs does not appear to be a viable answer. I have
been unable to find any approach that does not appear to have fatal flaws
in it. The existing call routing system is almost organic in nature and
with SIP we are trying to fit it into a much more rigid structure. Since
the market will not allow forcing this change, we can only succeed if we
identify a structure that improves on the existing PSTN capability without
causing user distress. I think this will not be an easy task.

>--
>Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
>[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA
>

======================================

Larry Cox
Senior Software Engineer

Hypercom Network Systems Inc.
2851 West Kathleen Road
Phoenix, AZ 85053
USA

Phone: (602) 504-4657
Fax: (602) 504-4711
Web: www.hypercom.com

---

From: Thomas Marshall Eubanks <[email-masked]>
Date: Thu, 18 Nov 1999 07:11:45 -0500

Hello;

> precludes requiring a # digit at the end of the digit string.

I would not be so sure of this. In the US, this might be a problem, as
our phone numbers have been stable for decades. In the US, a # sign
would probably not be
necessary, though, except for overseas calls. In Europe, however, I am
not sure that such a change 
would be a big problem, as changes like this tend to happen more
frequently anyway. In Austria, 
for example, within this decade they re-numbered much of the country. I
don't know the details, 
but EVERY number I use in Austria changed. If they can handle this, they
can handle a # sign, 
especially as it would not be absolutely required.

My point here is simply that the more "organic" the phone system, the
more users have to
put up with instabilities in the system, and so the more they would be
willing to accept
additional changes.

Also, won't recently called numbers be cached ? If a number is in the
cache, neither
a # sign nor a wait would be necessary. For most people, this would
remove most of the problem.

> unreliable call switching. It appears that it would be much better to find

                                         Regards
                                         Marshall Eubanks
                                         Multicast Technologies LLC
                                         [email-masked]

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 18 Nov 1999 18:32:36 -0600 (CST)

>precludes requiring a # digit at the end of the digit string.

I must have been unclear:

I was not proposing the *requirement* of a '#' to signal the end of a
number; merely that it could be used to bypass a timeout. Customers
can be informed that, if they want to minimize post-dial-delay, they
can hit '#'. Customers who don't care or haven't been informed can
wait for the timeout. This is, I know, massively sub-optimal. But
it was what I was suggesting (merely for being the least of all
evils considered so far, in my opinion).