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

From: [email-masked]
Date: Fri, 21 Nov 2003 17:12:43 EST

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

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 22 Nov 2003 15:02:12 +0100

Amen.
I also remember Henning saying that the tel: URI is more like an URN.
I cannonot imagine an URN with a pause.
Richard

	-----Ursprüngliche Nachricht----- 
	Von: [email-masked] [mailto:[email-masked]] 
	Gesendet: Fr 21.11.2003 23:12 
	An: [email-masked] 
	Cc: 
	Betreff: [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 

��b�	��X��X��m����5��_��?�������+-�w��ȩ�)�N��+-����u�ޖ�fz{h~�^j�e�ƭ���}"RǬ����W�z{h��,r�n���y۟���z�b�{(�˫����*T��"�'�~��~��{^��h�g���r��H�

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 25 Nov 2003 10:20:51 -0500

I am proposing that they be allowed in a SIP URI that includes
a user=dialstring parameter.

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.  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.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, November 25, 2003 9:35 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] User=Phone/DialString and Pause and Wait

In a message dated 11/24/2003 11:47:54 AM Eastern Standard Time,
[email-masked] writes: 

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. 

Sorry if I misunderstood the points being made by some. I'm certainly
relieved that there is no proposal to add pauses and waits to the tel:uri.
The discussion in IPTEL was about the user=phone parameter in the tel:uri
(or so I thought) and there were several comments about the need to include
pauses and waits. 

If the discussion of user=phone and dialstring was not about modifying the
tel:uri to carry a dial string, why was it reported that the tel:uri draft
has been held up pending this discussion? 

So where and why were the pauses and waits being proposed? 

Mike Pierce 

_______________________________________________
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