Subject: Re: [Sipping] WGLC for ISUP overlap signaling

From: [email-masked]
Date: Mon, 3 Jun 2002 11:47:13 EDT

To all:

Following comments on the subject draft.

The final conclusion in Section 5 is correct: "the ingress gateway should 
always perform overlap to en-bloc conversion". I truly believe that this 
should be the required operation, thereby reducing this draft to only a few 
pages. However, presuming that the draft will be progressed, following are a 
number of issues that need to be addressed:

Section 3.1

A note should be added that T35 is defined in Q.764 as 15-20 seconds.

Section 3.2

The statement after the figure should read "Note that T10 is defined in Q.764 
for conversion between overlap signaling (e.g. CAS) and en-bloc ISUP."

The statement about "PSTN switches usually implement an equivalent 
proprietary timer ..." is confusing. They do just what is shown in the figure 
and in Q.764, but the value of the timer they use might not be exactly within 
the 4-6 seconds recommended by ITU-T, but it's not really "proprietary". 
Suggest this sentence and the remainder of the paragraph be reworded as:

PSTN switches usually implement a locally defined value of timer T10, which 
may not be within the 4-6 second range recommended by Q.764. This document 
uses T10 and recommends the range of values defined in Q.764, which seems 
suitable for conversion from overlap to en-bloc SIP operation. The actual 
choice of the timer value is a matter of local policy.

Section 3.3

In the last paragraph, it's hard to see why the INVITE with an extra digit 
could result in a 484 (Address Incomplete). It should be expected that any 
destination would throw away the extra digit and the response would be the 
same as if the extra digit were not there. Or, if the destination recognizes 
that the digit string is invalid because it is too long, the response should 
not be "incomplete". There must be a different response.

In fact. 2543bis describes this response as being used for overlapped 
dialing. It states that the client "sends strings of increasing lengths, 
prompting the user for more input, until it no longer receives a 484 status 
response." There should not be a 484 response when there are too many digits.

Section 3.4

The statement about a number "belongs to a part of the PSTN where overlap 
signaling is used" is confusing. Whether or not overlap signaling is used is 
more a function of the originating end, not where the destination number 
belongs. Typically, it is required because the destination has a rather 
unstructured dial plan (e.g., different length numbers in the same country or 
city) but it is actually required by the fact that the originating side does 
not have enough data to fully define the combinations for digit analysis.

Further, the final sentence in the first paragraph about a "prefix of the 
number" identifying any other user is addressing a separate concept from 
overlap. There are two separate concepts and dialing quirks that are being 
addressed: overlap dialing, and ambiguous numbers. Sometimes they go 
together, but not normally. For example, in places in the US, the originating 
exchange needs to apply a timeout (relatively short) after the user dials 
something like 18072345, since this might be a full number or it might be the 
first 8 digits of a 1+10-digit dialing. But there is no overlap signaling in 
use and this timing to resolve ambiguous numbers is never required at the 
receiving end of ISUP. In another case, when the originating network is 
performing overlap because of the unstructured dial plan in the destination 
country or city, it will apply a timeout (relatively short) after some 
minimum number of digits, and will definitely stop after 15 or when it gets 
an end-of-dial from the other end. There are no ambiguous codes in this case. 
I can't really think of a case in which both overlap signaling and ambiguous 
code procedures apply together on the same call or at the same switch.

I would propose that the first paragraph of 3.4 be reworded as follows to 
only address the overlap situation:

3.4 Applicability of these mechanisms
The overlap signaling mechanisms are applicable only under certain 
circumstances. An ingress gateway may use overlap signalling in SIP when an 
analysis of the called party number shows that it belongs to a part of the 
PSTN where there is a variable number of digits required to form a complete 
number and the gateway lacks the information to determine the length of the 
number solely by interpretation of the received digits. The gateway will use 
a timeout after some minimum number of digits or an end-of-dial indication 
from the destination to determine the end of dialing.

Then the second paragraph addresses the handling of ambiguous numbers as it 
pertains to overlap vs. en bloc. I think it's still a little confusing on 
what significance it has to overlap. I suggest that the following phrase be 
added to the last sentence: "which is why overlap should not be used in this 
case."

In fact, this issue would seem to invalidate the statement in Section 3.7 
about multiple INVITEs that says that "one of the IAMs has an incomplete 
number". If one number really could be the prefix of another, both IAMs might 
have a complete (but different) number. This better not be possible.

On the other hand, the procedures for multiple INVITEs would need to deal 
with the case in which the earlier INVITE with fewer digits is really the 
right one and the latter INVITE simply has extra unneeded digits dialed. 
Remember that, at least in the US, businesses often list their phone numbers 
with words and often include extra letters (digits) which are dropped by the 
local exchange. If extra digits are entered using overlap with SIP, the 
destination interworking would likely result in the originating gateway 
receiving a 200 OK for multiple IAMs.

Section 3.5

As noted elsewhere, there is no guarantee that all the responses but one are 
400 class.
Also, it is not always correct to give priority to the one with "a greater 
number of digits".

Section 3.6

This description of sending multiple INVITEs and CANCELing all but one when a 
200 OF is received seems to have some of the pit-falls of the FORKing 
problem. It isn't clear why the gateway would not immediately CANCEL one 
INVITE before sending another which it thinks is "more" correct (more digits) 
but then would have to explicitly CANCEL every extra INVITE later when the 
200 is received. The desired operation is that the new INVITE immediately 
replaces the old one so no CANCEL would be needed. (Presuming it is 
restricted to going the same place as noted in the comments to Section 3.7 
below.)

3.7 Sending multiple IAMs to the PSTN for the same call is not acceptable. 
Overlap within circuit switched networks was done on the basis on successive 
pieces of information being passed in association with one call. It never 
caused different routing. Since multiple INVITEs in SIP are, by definition, 
new "calls", this approach to overlap is not acceptable.

The 2nd paragraph addresses why the INVITEs should not be forced to all 
follow the same path. The desire is to allow different "routing" to possibly 
activate different services. However,  as described in Section 3.1, overlap 
always begins by waiting for "the minimum amount of digits to route". Because 
of this, and the apparent minimal use of overlap within SIP, it should be 
acceptable to force all INVITEs for a call to follow the same route.

Section 4.1

Since the ingress side that sent the INVITE set a timer and expected more 
digits, it should certainly be possible to include explicit information in 
the INVITE that overlap is being used at the ingress side. Otherwise, the 
egress side could be at a loss to know what to do.

It also must be presumed that, when an egress gateway "is attached to the 
PSTN in an area where en-bloc signaling is used" (e.g., the US), that it 
knows the local dial plan and would know that it does not have a complete 
number yet. In fact, it requires the complete number in order to correctly 
format the IAM for en-bloc. It can not send an IAM with an incomplete number 
(since it is limited to use of en-bloc) so it would never have to later 
release the IAM in preference to another one. It either needs an explicit 
indication from the originating side that the number is complete, it needs to 
know by digit analysis, or it must apply a timeout before sending the first 
IAM. Essentially, it performs the overlap-to-en-bloc procedure.

5. Conclusions

It is unknown what is intended by the statement that this mechanism "is 
intended to be used in a close(d) environment". Closed environments should 
have well known dial plans which eliminate the need for overlap or ambiguous 
code resolution. It is the world-wide, public telephony network that needed 
overlap procedures in the past. In fact, Section 3.4 in the draft seems to 
describe this mechanism as applicable "only" in the PSTN.

The final sentence of the first paragraph leads to confusion. An "en-bloc 
zone" is generally characterized by a uniform numbering plan in which it is 
impossible for the "prefix" digits of one number to cause a call to reach the 
wrong callee when the call is going through the network functions described 
in this draft. As noted further below, this misdirection of a call may occur 
due to unintended timeout when resolving an ambiguous codes in the local 
dialing plan, but this is not a function of overlap (ISUP) signaling. It 
simply is a function of interpretation of subscriber dialing (signaling). At 
least, this sentence should be reworded as:

If this mechanism were used with telephone numbers that are ambiguous in the 
local dial plan, calls could end up reaching a different callee than the one 
who was supposed to receive the call if an inadvertent timeout occurs.

It is uncertain how the use of overlap within SIP, as defined here, would 
reduce the call establishment delay. The last digit can not be forwarded at 
the destination SIP gateway until the final T10 expires, whether T10 expires 
at the originating or the terminating gateway. In the ISUP world, when 
interworking with a slow signaling system (like dial pulse) at the 
destination, it was advantageous to support overlap in ISUP in order to allow 
the slow signaling system to begin transferring digits as soon as it had 
enough for routing, with the expectation that further digits (the last few of 
the subscriber's number) would be available when ready to send them and the 
last would not be sent until the network decided that it was the end. This 
drastically reduced call setup time.

It should be noted here again that the US telephone network is based on 
standard T1.113 for ISUP which does not support overlap signaling. It does 
not include the Subsequent Address Message. In addition, many countries 
around the world are moving to uniform numbering plans since they have 
recognized the complications caused by having variable length local numbers. 
Further, the slow signaling systems at the destination which were the reason 
for including overlap in the ITU-T version of ISUP are rapidly being replaced 
with high speed SS#7. Therefore, the advantage of supporting overlap is 
rapidly disappearing.

Mike Pierce
Artel

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 28 Jun 2002 15:49:41 +0300

Mike,

Thanks for your feedback. Answers inline:

[email-masked] wrote:
> The final conclusion in Section 5 is correct: "the ingress gateway
> should always perform overlap to en-bloc conversion". I truly believe
> that this should be the required operation, thereby reducing this
> draft to only a few pages. However, presuming that the draft will be
> progressed, following are a number of issues that need to be
> addressed:
> 
> Section 3.1
> 

Done.

> Section 3.2
> 
> The statement after the figure should read "Note that T10 is defined
> in Q.764 for conversion between overlap signaling (e.g. CAS) and
> en-bloc ISUP."
> 

Done.

> proprietary timer ..." is confusing. They do just what is shown in the
> figure and in Q.764, but the value of the timer they use might not be
> exactly within the 4-6 seconds recommended by ITU-T, but it's not
> really "proprietary". Suggest this sentence and the remainder of the
> paragraph be reworded as:
> 
> PSTN switches usually implement a locally defined value of timer T10,
> which may not be within the 4-6 second range recommended by Q.764.
> This document uses T10 and recommends the range of values defined in
> Q.764, which seems suitable for conversion from overlap to en-bloc SIP
> operation. The actual choice of the timer value is a matter of local
> policy.
> 

Done.

> Section 3.3
> 
> In the last paragraph, it's hard to see why the INVITE with an extra
> digit could result in a 484 (Address Incomplete). It should be
> expected that any destination would throw away the extra digit and the
> response would be the same as if the extra digit were not there. Or,
> if the destination recognizes that the digit string is invalid because
> it is too long, the response should not be "incomplete". There must be
> a different response.

The text you are referring to is only an example. And as an example, it
is OK. In fact, this can happens when a number is the prefix of another
one. Anyway, as I said, it is onl an example and it is OK as it is.

> dialing. It states that the client "sends strings of increasing
> lengths, prompting the user for more input, until it no longer
> receives a 484 status response." There should not be a 484 response
> when there are too many digits.
> 
> Section 3.4
> 
> The statement about a number "belongs to a part of the PSTN where
> overlap signaling is used" is confusing. Whether or not overlap
> signaling is used is more a function of the originating end, not where
> the destination number belongs. Typically, it is required because the
> destination has a rather unstructured dial plan (e.g., different
> length numbers in the same country or city) but it is actually
> required by the fact that the originating side does not have enough
> data to fully define the combinations for digit analysis.
> 
> Further, the final sentence in the first paragraph about a "prefix of
> the number" identifying any other user is addressing a separate
> concept from overlap. There are two separate concepts and dialing
> quirks that are being addressed: overlap dialing, and ambiguous
> numbers. Sometimes they go together, but not normally. For example, in
> places in the US, the originating exchange needs to apply a timeout
> (relatively short) after the user dials something like 18072345, since
> this might be a full number or it might be the first 8 digits of a
> 1+10-digit dialing. But there is no overlap signaling in use and this
> timing to resolve ambiguous numbers is never required at the receiving
> end of ISUP. In another case, when the originating network is
> performing overlap because of the unstructured dial plan in the
> destination country or city, it will apply a timeout (relatively
> short) after some minimum number of digits, and will definitely stop
> after 15 or when it gets an end-of-dial fro! m the other end. There
> are no ambiguous codes in this case. I can't really think of a case in
> which both overlap signaling and ambiguous code procedures apply
> together on the same call or at the same switch.
> 
> I would propose that the first paragraph of 3.4 be reworded as follows
> to only address the overlap situation:
> 
> circumstances. An ingress gateway may use overlap signalling in SIP
> when an analysis of the called party number shows that it belongs to a
> part of the PSTN where there is a variable number of digits required
> to form a complete number and the gateway lacks the information to
> determine the length of the number solely by interpretation of the
> received digits. The gateway will use a timeout after some minimum
> number of digits or an end-of-dial indication from the destination to
> determine the end of dialing.

Now it reads as follows:
"This mechanism is applicable only under certain circumstances. An
ingress gateway may use overlap signalling in SIP if, and only if, an
analysis of the called party number shows that it belongs to a part of
the PSTN where there is a variable number of digits required to form a
complete number and the gateway lacks the information to determine the
length of the number solely by interpretation of the received digits.
This ensures that a particular prefix of the number does not identify
any other user."

> Then the second paragraph addresses the handling of ambiguous numbers
> as it pertains to overlap vs. en bloc. I think it's still a little
> confusing on what significance it has to overlap. I suggest that the
> following phrase be added to the last sentence: "which is why overlap
> should not be used in this case."

Done

> In fact, this issue would seem to invalidate the statement in Section
> 3.7 about multiple INVITEs that says that "one of the IAMs has an
> incomplete number". If one number really could be the prefix of
> another, both IAMs might have a complete (but different) number. This
> better not be possible.

I have added to section 3.7:
"It could even happen that both IAMs contained complete, but different
numbers (i.e., one number is the prefix of the other one)."

> On the other hand, the procedures for multiple INVITEs would need to
> deal with the case in which the earlier INVITE with fewer digits is
> really the right one and the latter INVITE simply has extra unneeded
> digits dialed. Remember that, at least in the US, businesses often
> list their phone numbers with words and often include extra letters
> (digits) which are dropped by the local exchange. If extra digits are
> entered using overlap with SIP, the destination interworking would
> likely result in the originating gateway receiving a 200 OK for
> multiple IAMs.
> 
> Section 3.5
> 
> As noted elsewhere, there is no guarantee that all the responses but
> one are 400 class.
> Also, it is not always correct to give priority to the one with "a
> greater number of digits".

It is explained somewhere else in the draft, so I believe it is OK not
to repeat it once more in this section.

> 
> Section 3.6
> 
> This description of sending multiple INVITEs and CANCELing all but one
> when a 200 OF is received seems to have some of the pit-falls of the
> FORKing problem. It isn't clear why the gateway would not immediately
> CANCEL one INVITE before sending another which it thinks is "more"
> correct (more digits) but then would have to explicitly CANCEL every
> extra INVITE later when the 200 is received. The desired operation is
> that the new INVITE immediately replaces the old one so no CANCEL
> would be needed. (Presuming it is restricted to going the same place
> as noted in the comments to Section 3.7 below.)
> 
> 3.7 Sending multiple IAMs to the PSTN for the same call is not
> acceptable. Overlap within circuit switched networks was done on the
> basis on successive pieces of information being passed in association
> with one call. It never caused different routing. Since multiple
> INVITEs in SIP are, by definition, new "calls", this approach to
> overlap is not acceptable.

This is exactly what the draft says.

> 
> The 2nd paragraph addresses why the INVITEs should not be forced to
> all follow the same path. The desire is to allow different "routing"
> to possibly activate different services. However,  as described in
> Section 3.1, overlap always begins by waiting for "the minimum amount
> of digits to route". Because of this, and the apparent minimal use of
> overlap within SIP, it should be acceptable to force all INVITEs for a
> call to follow the same route.

There has already been too much discussion about this, so I will not
discuss it again.

> 
> Section 4.1
> 
> Since the ingress side that sent the INVITE set a timer and expected
> more digits, it should certainly be possible to include explicit
> information in the INVITE that overlap is being used at the ingress
> side. Otherwise, the egress side could be at a loss to know what to
> do.

We do not want to introduce an "overlap indicator" in SIP. The idea is
to push compexity to the gateway, not to add it to SIP.

> 
> It also must be presumed that, when an egress gateway "is attached to
> the PSTN in an area where en-bloc signaling is used" (e.g., the US),
> that it knows the local dial plan and would know that it does not have
> a complete number yet. In fact, it requires the complete number in
> order to correctly format the IAM for en-bloc. It can not send an IAM
> with an incomplete number (since it is limited to use of en-bloc) so
> it would never have to later release the IAM in preference to another
> one. It either needs an explicit indication from the originating side
> that the number is complete, it needs to know by digit analysis, or it
> must apply a timeout before sending the first IAM. Essentially, it
> performs the overlap-to-en-bloc procedure.
> 
> 5. Conclusions
> 
> It is unknown what is intended by the statement that this mechanism
> "is intended to be used in a close(d) environment". Closed
> environments should have well known dial plans which eliminate the
> need for overlap or ambiguous code resolution. It is the world-wide,
> public telephony network that needed overlap procedures in the past.
> In fact, Section 3.4 in the draft seems to describe this mechanism as
> applicable "only" in the PSTN.

It means that we do not recommend the use of this mechanism, but if
somebody insists in using it, it has to be aware of the possible
consequences.

I fixed the typo.

> 
> The final sentence of the first paragraph leads to confusion. An
> "en-bloc zone" is generally characterized by a uniform numbering plan
> in which it is impossible for the "prefix" digits of one number to
> cause a call to reach the wrong callee when the call is going through
> the network functions described in this draft. As noted further below,
> this misdirection of a call may occur due to unintended timeout when
> resolving an ambiguous codes in the local dialing plan, but this is
> not a function of overlap (ISUP) signaling. It simply is a function of
> interpretation of subscriber dialing (signaling). At least, this
> sentence should be reworded as:
> 
> If this mechanism were used with telephone numbers that are ambiguous
> in the local dial plan, calls could end up reaching a different callee
> than the one who was supposed to receive the call if an inadvertent
> timeout occurs.
> 

Done.

> It is uncertain how the use of overlap within SIP, as defined here,
> would reduce the call establishment delay. 

Without this mechanism, the ingress gateway would always have to convert
(using a timeout) to en-bloc. This way, it can send the INVITE right
away.

Thanks again for your valuable comments. I will be releasing a new
version of this draft very soon.

Regards,

Gonzalo

The last digit can not be
> forwarded at the destination SIP gateway until the final T10 expires,
> whether T10 expires at the originating or the terminating gateway. In
> the ISUP world, when interworking with a slow signaling system (like
> dial pulse) at the destination, it was advantageous to support overlap
> in ISUP in order to allow the slow signaling system to begin
> transferring digits as soon as it had enough for routing, with the
> expectation that further digits (the last few of the subscriber's
> number) would be available when ready to send them and the last would
> not be sent until the network decided that it was the end. This
> It should be noted here again that the US telephone network is based
> on standard T1.113 for ISUP which does not support overlap signaling.
> It does not include the Subsequent Address Message. In addition, many
> countries around the world are moving to uniform numbering plans since
> they have recognized the complications caused by having variable
> length local numbers. Further, the slow signaling systems at the
> destination which were the reason for including overlap in the ITU-T
> version of ISUP are rapidly being replaced with high speed SS#7.
> Therefore, the advantage of supporting overlap is rapidly
> disappearing.
> 
> Mike Pierce
> Artel

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Sat, 29 Jun 2002 11:15:02 +0300

Folks,

Until it appears in the archives, you can fetch it from:

http://standards.ericsson.net/gonzalo/papers/draft-ietf-sipping-overlap-01.txt

Finally, section 3.4 reads as follows:
"3.4 Applicability of this mechanism

  This mechanism is applicable only under certain circumstances. An
  ingress gateway may use overlap signalling in SIP when an analysis of
  the called party number shows that it belongs to a part of the PSTN
  where there is a variable number of digits required to form a
  complete number and the gateway lacks the information to determine
  the length of the number solely by interpretation of the received
  digits.

  Within some dialing plans in the PSTN, a phone number might be a
  prefix of another one. This situation is not common, but it can
  certainly occur. Where en-bloc signalling is used, this ambiguity is
  resolved before the digits are placed in the en-bloc signalling. If
  overlap signaling was used in this situation, a different user than
  the one the caller intended to call might be contacted. That is why
  in the parts of the PSTN where overlap is used, a prefix of a
  telephone number never identifies another valid number. Therefore, an
  ingress gateway may use overlap if, and only if, an analysis of the
  called party number shows that it belongs to a part of the PSTN where
  overlap signalling is used. This ensures that a particular prefix of
  the number does not identify any other user."

Regards,

Gonzalo