Subject: RE: [Sipping] User=Phone/DialString and Pause and Wait

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 24 Nov 2003 11:46:28 -0500

Rumors are always fascinating to watch form and spread.

Contrary to what you may have heard, no one has proposed modifying
a tel uri to carry a dial string, nor to permit pause/wait in a tel uri.

What was proposed was a new option for the user parameter of a sip uri,
so that you could have a uri of the form:

sip:[email-masked];user=dialstring

We all agreed that a tel uri, which is also convertible to a sip uri
with the user=phone convention, remained a way to express local or global
phone numbers, and not dial strings.

>It should be expected that the interface from a Gateway to the 
>PSTN would use something modern like ISDN, without any notion of pauses 
>or waits. 
Sorry that the world does not meet your expectations, but there are tens
of thousands of analog gateways out there that use DTMF

>If a Gateway uses channel associated signaling like DTMF, all modern 
>switches only require waiting for dial tone for the first digit, 
>something the Gateway must know without it being coded into the digit 
>string. They do not require further pauses or waits for dial tone, 
>even if another dial tone is being returned to the user (like after 
>dialing "9" in a PBX).
Again, the world does not meet your expectations.  If you were to dial
6000 on my local PBX from any station, you would discover that if
you waited for a dial tone, and entered a 4 digit extension, you would
find yourself depositing a voice mail in the extension's voicemailbox.
If you choose not to wait, you would find that you would often get an
error.

The gateway can insert the pause/wait.  Not all analog gateways do, but
those that do need a standardize way to send a dialstring to it.

We actually use this in our "call forward, no answer" behavior.  We
store a URI like the above in a database, and when the proxy server
handles the call forwarding behavior, it forwards the call to the
gateway with a uri not much different than the example above (the
host is the gateway, rather than the local proxy server, so it's
really something like sip:[email-masked] 

>What I find particularly bad about this whole user=phone discussion 
>is that this issue was discussed and resolved over 15 years ago for 
>ISDN and documented in Q.931 for the Called Party Number. If that 
>definition in Q.931 had been used as the base for SIP (with possible 
>deletion of some values that don't apply), this whole issue would have
>been much easier and resolved a long time ago.
Well, once again, surprise, the world doesn't meet your expectations,
nor that of the ITU.  Q.931 has not taken over, even today, for UNI
dialing.  In fact, here in North America, backwards that we are,
Q.931 basically went pffft, except the last 5 or 6 years on T1s.  
Certainly at the station level, there is still a ton of DTMF, and we have
to be able to deal with it, because there are two ends (a gateway and
a UA/proxy server), and they need a standardized way to communicate.
Dialstrings are a fact of life in the real world.

But, we didn't change the tel uri, because there is no need to.

Brian 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 21, 2003 5:13 PM
To: [email-masked]
Subject: [Sipping] User=Phone/DialString and Pause and Wait

Following the discussion in IPTEL (which belongs in SIPPING) concering the
idea of including "pause" and "wait" in the dial string, I have the
following comments: 

Long before the current revision of RFC2806 was started, it was recognized
that RFC 2806 was very wrong, and, following my early suggestions on
beginning a fix, the draft revision came out with these old "AT modem
command" functions removed. The discussion at last week's meeting about
re-adding them is very troubling. 

The fundamental issue seems to be a lack of agreement on the application, or
environment, in which the tel:uri or any of its extensions, is to be used.
It was clear to me from the beginning that the scope of the effort was to
provide a coding to be used in messages from the end user's terminal (the
one "dialing") to some other device that might need to interpret those
digits for routing purposes. As such, it needs to deal with "dial strings"
vs "numbers", and this has been the main part of the discussion. As stated
in the tel:uri draft: "the tel:uri describes resources identifed by
telephone numbers". 

However, at the meeting, this notion of again including "pause" and "wait"
came up, and when challenged, someone used the example of needing to tell an
outgoing Gateway how to send the digits into the circuit switched network
(PSTN or private). I believe this is not in the scope of the effort. 

In any case, if someone still thinks it is, some further comments are in
order: 

It should be expected that the interface from a Gateway to the the PSTN
would use something modern like ISDN, without any notion of pauses or waits.

If a Gateway uses channel associated signaling like DTMF, all modern
switches only require waiting for dial tone for the first digit, something
the Gateway must know without it being coded into the digit string. They do
not require further pauses or waits for dial tone, even if another dial tone
is being returned to the user (like after dialling "9" in a PBX). 

Even with old PSTN switches, the application still is based on sending a
single string of digits (no pauses or waits). 

For the application of telling a Gateway how to send out digits, only the
"dial string" format, not the "number" format would apply. 

Bottom line: the application of coding the digits entered by the originating
human or agent and the one of telling a Gateway how to send digits are very
much different and should not be combined into one definition or discussion.

What I find particularly bad about this whole user=phone discussion is that
this issue was discussed and resolved over 15 years ago for ISDN and
documented in Q.931 for the Called Party Number. If that definition in Q.931
had been used as the base for SIP (with possible deletion of some values
that don't apply), this whole issue would have been much easier and resolved
a long time ago. 

Mike Pierce 
Artel 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Nov 2003 17:26:12 -0500

Brian - I need to pick some nits in what you say below.

	Paul

> phone numbers, and not dial strings.

I wouldn't go quite that far. While we agreed that the sip uri with 
user=dialstring may be used to represent dial strings, I don't believe 
that eliminates the option of using a tel: uri with a local number and a 
context.

Rosen, Brian wrote:
 >
 > To be clear, we agreed in Minneapolis that Rohan's proposal that
 > user=phone designates a phone number exactly as a tel uri does;
 > that is, a sip uri with user=phone is convertible to a tel uri
 > without change in meaning and vice versa.

We have to be very careful about the visa versa part. Sip uris retain 
the rule that the user part is only interpretable within domain of its 
address. So sip:[email-masked];user=phone may be understood to 
be equivalent to tel:+1-234-567-8901 by the foo.com proxy, but not by 
the bar.com proxy.

 > I almost typed "without
 > a change in destination or routing", but that may not be true,
 > because a given proxy could decide to route them differently.
 > Don't know why it would, but it could.

There are good reasons. If the address tel:+1-234-567-8901 is presented 
to both the foo.com and bar.com proxies, they may choose to route it 
differently. Perhaps one routes to a gateway in the US, and the other to 
a gateway in China.

But when both are presented with sip:[email-masked];user=phone,
the bar.com proxy will be compelled to route to the foo.com proxy, and 
from there it will be treated the same as one initially offered to 
foo.com. So both calls will be routed thru the same gateway.

	Paul