Subject: AW: [Sipping] Comments to the SIP-ISUP WGLC

From: "Alexeitsev, D" <[email-masked]>
Date: Thu, 11 Jul 2002 13:22:06 +0200

Hello Gonzalo
 
> That also would be consistent with the "SIP Call Flow Examples" draft.

The figure in the draft reflects better the reality, IMO.

[DA] Then are the both SIP call flows and media cutthroughs valid? Or should one document change it's figures?

Greetings,
Denis Alexeitsev

_______________________________________________
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: [email-masked]
Date: Thu, 11 Jul 2002 10:24:47 EDT

In a message dated 7/11/02 6:31:38 AM Eastern Daylight Time, 
[email-masked] writes:

>[Dennis had written] 
> The section 11 "Construction of Telephony URIs" does not highlight the 
handling of the end-of-pulsing (ST) signal after address signals. Should it 
be mapped to the tel: URI or not?

[Gonzalo responded]
Section 11 references [7], which is:

[7]  Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
        2000.

There, and in the future documents that will obsolete that spec, you can
find all the info related to tel URIs.

[Mike says]

RFC2806 indirectly allowed one to indicate end-of-pulsing by including the # 
character, which is often used in subscriber signaling to do the same thing. 
However, I did not see any explicit support for an end-of-pulsing indication, 
since it allowed the # character to be in the middle of a string. In any 
case, RFC 2806 is being extensively rewirtten and should not be referenced.

The replacement in draft-antti-rfc2806bis-05 does not define the # character 
(but allows each digit to be a HEX value. There is not coding included (in 
error IMO) to indicate end-of-dialing or that the number contained in the 
tel:url is a complete E.164 number.

Mike Pierce

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 11 Jul 2002 16:11:58 +0100

Use of # in functional signalling schemes to indicate end of dialling is not preferred, as it could mean lots of other things as well, depending on how the receiver is configured (I could name at least two PBX manufacturers who use it as an integral part of the feature identification signalling).
 
To the best of my knowledge, ISUP does not define it, but uses an explicit ST signal to indicate whether the number is complete or not.
 
DSS1 defines an explicit information element (Sending complete) to indicate end of dialling, although the # is allowed in stimulus signalling with the Keypad facility information element.
 
Additionally, I thought RFC 2806 was about putting E.164 numbers into URLs (among other things). E.164 numbers are by definition complete, and # does not form part of an E.164 number.
 
Keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 11 July 2002 15:25
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Sipping] Comments to the SIP-ISUP WGLC

In a message dated 7/11/02 6:31:38 AM Eastern Daylight Time, [email-masked] writes: 

>[Dennis had written] 
> The section 11 "Construction of Telephony URIs" does not highlight the handling of the end-of-pulsing (ST) signal after address signals. Should it be mapped to the tel: URI or not? 

[Gonzalo responded] 

[Mike says] 

RFC2806 indirectly allowed one to indicate end-of-pulsing by including the # character, which is often used in subscriber signaling to do the same thing. However, I did not see any explicit support for an end-of-pulsing indication, since it allowed the # character to be in the middle of a string. In any case, RFC 2806 is being extensively rewirtten and should not be referenced. 

The replacement in draft-antti-rfc2806bis-05 does not define the # character (but allows each digit to be a HEX value. There is not coding included (in error IMO) to indicate end-of-dialing or that the number contained in the tel:url is a complete E.164 number. 

Mike Pierce

---

From: Michael Hammer <[email-masked]>
Date: Fri, 12 Jul 2002 15:12:24 -0400

Kieth,

By "definition", does that mean that tel: URLs can not be used for overlap?

In general, I think it would be a good idea if the world adopted an 
explicit "end of dialing" character, and that an indication of such was 
carried end-to-end.

Mike

At 04:11 PM 7/11/2002 +0100, Drage, Keith (Keith) wrote:
>Use of # in functional signalling schemes to indicate end of dialling is 
>not preferred, as it could mean lots of other things as well, depending on 
>how the receiver is configured (I could name at least two PBX 
>manufacturers who use it as an integral part of the feature identification 
>signalling).
>
>To the best of my knowledge, ISUP does not define it, but uses an explicit 
>ST signal to indicate whether the number is complete or not.
>
>DSS1 defines an explicit information element (Sending complete) to 
>indicate end of dialling, although the # is allowed in stimulus signalling 
>with the Keypad facility information element.
>
>Additionally, I thought RFC 2806 was about putting E.164 numbers into URLs 
>(among other things). E.164 numbers are by definition complete, and # does 
>not form part of an E.164 number.
>
>Keith
> handling of the end-of-pulsing (ST) signal after address signals. Should 
> it be mapped to the tel: URI or not?
>
>[Gonzalo responded]
>RFC2806 indirectly allowed one to indicate end-of-pulsing by including the 
># character, which is often used in subscriber signaling to do the same 
>thing. However, I did not see any explicit support for an end-of-pulsing 
>indication, since it allowed the # character to be in the middle of a 
>string. In any case, RFC 2806 is being extensively rewirtten and should 
>not be referenced.
>
>The replacement in draft-antti-rfc2806bis-05 does not define the # 
>character (but allows each digit to be a HEX value. There is not coding 
>included (in error IMO) to indicate end-of-dialing or that the number 
>contained in the tel:url is a complete E.164 number.
>
>Mike Pierce