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

From: Adam Roach <[email-masked]>
Date: Tue, 2 Jul 2002 16:08:24 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
 
>This is one of the most significant disagreements I have
>with this entire discussion. I do not believe there is a
>single place in the world's numbering plan where a number
>can be a "prefix" of another number. I'm speaking of the
>international, E.164 number, not the local number that one
>might dial to reach operators, local numbers, long-distance
>numbers, etc. Can you give me one example of where one
>E.164 number is a "prefix" of another? 

Although I don't have the exact numbers on me at the moment,
I've seen cases (in Sweden and Germany, if my memory serves)
in which Hotel and Business PBXs are configured such that
this occurs. Typically these act in a way in which a short
series of digits, e.g. +891 24 7350 reaches the hotel front
desk, while +891 24 735 0324 reaches room 324. One number is
fully contained in the other.

In this case, +891 24 735 06 would be an incomplete number --
too long to route to the front desk, and too short to route
to a room. Sounds like a "484 Address Incomplete" to me.

IIRC, the ambiguity is handled by timers. So, yes, if you
dial too slowly, you might reach the front desk by accident.

Before you argue that using a timer like this is unacceptable,
consider: when you dial from a landline phone in the NANP,
you have an identical situation. 011-44-020-123-45-67 would ring
a phone in London. If I pause too long between the 0 and the
1 at the beginning, though, I reach an operator.

/a

_______________________________________________
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: "Alexeitsev, D" <[email-masked]>
Date: Wed, 3 Jul 2002 08:46:57 +0200

Hello All

some comments for the overlap WGLC

The section 3.1 reprints the procedures that are already defined in the Q.767. What will be the status of the overlap RFC? If proposed standard, then this section is not necessary. 

The section 3.2 talks about the use of the timer T10 for the ISUP overlap to SIP en bloc conversation. The use of this T10 timer is defined in the Q.767 and the only described action at it's expiry is the sending of ACM. One can not redifine the procedures of already defined timers.

My propose is to define an interworking timer that may do the same things as T10 with the additional functionality of sending the INVITE at it's expiry.

Greeting,
Denis Alexeitsev

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 3 Jul 2002 15:27:28 +0100

I am afraid I could not find a defining term in any of the ITU-T stuff, primarily because ITU-T does not define such a condition. This does not preclude it, it is just national use only. The only term I have seen, and that was a long time ago (20 years) and I am not sure it is still current, was "critical dialling" or "critical timing". That was not in any standards documentation.

Note that some people are assuming a reference to open numbering plans where subscriber numbers are of different lengths, particularly in the same NDN. For example

+358 9 299 3371
+358 9 299 0

would represent this, but in this case 

+358 0 200 0xxx would not normally be valid numbers. These cases certainly exist within the same NDN in Austria and Germany. In other countries E164 numbers may be of different lengths but the length is determined at the NDN level. USA has a closed numbering plan where all E164 numbers are the same length (Please do not list exceptions as I am sure there are some).

The case I assume we are dealing with here is the case where (in addition to an open numbering plan existing):

+358 9 299 0 is a valid number and
+358 9 299 0xxx are also valid numbers.

In the cases I have given here the examples could all be termed E.164 numbers.

In the example given by Adam in another mail, where

0 reaches the operator and
011-44-020-123-45-67 reaches a UK number

0 is a local service number (i.e. not an E164 number)
011 is an international prefix, and
440201234567 is an E164 number

Keith

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: 02 July 2002 13:08
> To: Drage, Keith (Keith)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Sipping] WGLC for ISUP overlap signaling
> 
> 
> Keith,
> 
> As you point you, I was using the word "prefix" without giving any
> formal definition... and it seems that people familiar with the ITU
> definition got confused...
> 
> Could you suggest a clearer set of terms so that everybody understands
> things in the same way? Let me know the paragraphs in the 
> draft that are
> not clear enough.
> 
> Thanks,
> 
> Gonzalo
> 
> "Drage, Keith (Keith)" wrote:
> > 
> > As you seem to be substantially disagreeing on the word 
> prefix, I would point out that according to E.164 none of the 
> numbers given by Gonzalo is a prefix. E.164 definition of 
> prefix is "A prefix is an indicator consisting of one or more 
> digits, that allows the selection of different types of 
> number formats, networks and/or service".
> > 
> > +358 9 299 3371 is the representation of 358 9 299 3371
> > 
> > 00 placed in front of this to indicate an international 
> number would be a prefix.
> > 
> > 358 is a country code, not a prefix
> > 9 is a national destination code, not a prefix
> > the remaining 7 digits are the subscriber number.
> > within the PBX the 299 could be considered as an escape 
> code, but certainly not as a prefix.
> > 
> > Gonzalo appears to be describing the case where
> > 
> > +358 9 299 1 and
> > +358 9 299 1000
> > 
> > are both valid numbers in the numbering plan.
> > 
> > I can find no specification in E.164 which specifies this 
> as either allowed or precluded, and therefore no 
> internationally recognised term to describe it. I believe in 
> the US it used to be called critical dialling, but in this 
> case it was used to reach attendants, and one of the numbers 
> in that case was not an E.164 number, because it was a local 
> service number.
> > 
> > I would stress that such numbering schemes are in very 
> limited use throughout the world. I was not aware that any of 
> the CEPT countries used them.
> > 
> > Keith
> > 
> > > From: Gonzalo Camarillo [mailto:[email-masked]]
> > > Sent: 02 July 2002 07:54
> > > To: [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: [Sipping] WGLC for ISUP overlap signaling
> > >
> > >
> > > Hello,
> > >
> > > I would appreaciate if you could use text format in your 
> messages, as
> > > opposed to html. It is easier for me to answer.
> > >
> > > You write:
> with this
> > > >entire discussion. I do not believe there is a single 
> place in the
> > > >world's numbering plan where a number can be a "prefix" 
> of another
> > > >number. I'm speaking of the international, E.164 number, not
> > > >the local number that one might dial to reach operators,
> > > local numbers,
> > > >long-distance numbers, etc. Can you give me one example
> > > >of where one E.164 number is a "prefix" of another?
> > > >
> > > >As for the above "example", I still don't believe there 
> is a single
> > > >valid case in which an INVITE with too many digits 
> should result in
> > > >a response that says there isn't enough digits.
> > >
> > > 358 is the prefix for Finland.
> > > 9 is the prefix for Helsinki
> > > 299 is the prefix for the PBX of Ericsson.
> > > Within our PBX, we manage the last 4 digits of the number.
> > >
> > > My phone number is: +358 9 299 3371
> > > My fax number is: +358 9 299 3052
> > >
> > > If you want to call the reception, you should dial: +358 9 299 1
> > >
> > > Now, if you want to dial any extension (the last four 
> digits of the
> > > phone number) that begins with 1 (e.g., +358 9 299 1234), 
> you have the
> > > problem I was describing.
> > >
> > > Best regards,
> > >
> > > Gonzalo
> > > --
> > > 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

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 3 Jul 2002 14:03:10 -0400

> From: Alexeitsev, D [mailto:[email-masked]]
> 
> The section 3.1 reprints the procedures that are already 
> defined in the Q.767. What will be the status of the overlap 
> RFC? If proposed standard, then this section is not necessary. 

The section is included for completeness. Omitting it would make
the sections that follow confusing. As nothing in this section
contradicts Q.767, there is no harm that can be caused by
including this text.

> The section 3.2 talks about the use of the timer T10 for the 
> ISUP overlap to SIP en bloc conversation. The use of this T10 
> timer is defined in the Q.767 and the only described action 
> at it's expiry is the sending of ACM. One can not redifine 
> the procedures of already defined timers.

By sending an ACM (which is performed, although not shown in the
diagram), the gateway precludes collection of any further digits.

If we are performing conversion from overlap to en-bloc signalling
(which is what this section covers), we send an INVITE once we are
certain that we have collected all of the digits.

Ergo, when T10 expires, the gateway sends an INVITE.

We are not "defining new procedures" for T10, since our behavior
TOWARDS THE ISUP NETWORK is precisely, 100% compliant with what is
described in Q.767. The jurisdiction of Q.767's procedures ends
once you get into the SIP network, and therefore have no bearing
on what the gateway decides to do in terms of SIP messaging.
Instead, we look towards RFC 3261 -- and the behavior on the SIP
side of things is completely in compliance with RFC 3261.

I hope this clears things up for you.

/a

---

From: [email-masked]
Date: Wed, 3 Jul 2002 13:31:45 EDT

In a message dated 6/28/02 8:50:14 AM Eastern Daylight Time, 
[email-masked] writes:

> >  Mike Pierce had commented:
> > 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 complexity to the gateway, not to add it to SIP.
> 

I'll try once more to demonstrate the problems with this approach of not 
including an explicit indication in the INVITE that the ingress GW thinks the 
number is complete (or not).

Consider a case in which the originating PSTN is fully capable to determining 
end-of-dial, for example, the originating user is an ISDN phone. The user in 
the US dials a number in Indonesia (which has lots of different length 
numbers). The ISDN signaling sends the complete number to the local switch 
(maybe the user hit an "end-of-dial" button or the terminal applied a 
time-out or the complete number was pulled from a pre-built speed dial list). 
The local switch sends an IAM which also indicates that the number is 
complete. The ingress GW gets this IAM, puts the complete number in the 
INVITE, but throws away the indication from the IAM that it is a complete 
number.

The egress GW gets the INVITE and recognizes the country code for Indonesia 
and is connected to the PSTN by an interface that does not support overlap. 
It doesn't have the data base necessary to determine if this particular 
number in Indonesia is complete, so it must apply the overlap to en-bloc 
conversion procedures, which is a 4-6 second timeout before sending its IAM. 
This unnecessarily delays call setup.

In a message dated 7/2/02 2:53:57 AM Eastern Daylight Time, 
[email-masked] writes:

> Now, if you want to dial any extension (the last four digits of the
> phone number) that begins with 1 (e.g., +358 9 299 1234), you have the
I find it hard to believe that any PBX would use extension numbers beginning 
with "1" if "1" is used to get to the reception (attendent) of that PBX. 
However, if such a dialing plan is actually used anywhere, then this points 
out another serious problem with the overlap operation described. If a new 
INVITE is sent for each new digit, then everytime someone dials one of the 
extensions in the PBX, it will first cause one or more calls to be made to 
the attendent (reception) which will then be released. In fact, Section 3.6 
suggests that the GW might actually wait an extra time before sending CANCEL 
for these extraneous INVITES. These extra IAMs, which result in false call 
attempts to the attendent, are unacceptable in any network. The text of the 
draft suggests that the orginating side is somehow able to know not to use 
overlap by digit interpretation, that is, it has a data base defining the 
dialing plan of the entire world. While this is possible, it must be possible 
to work properly when the ingress GW does not have this knowledge. In fact, 
if the originating GW had such a data base, it would be capable of always 
doing overlap to en-bloc conversion without adding a timeout.

The solution to these problems is to copy the functionality of ISUP (IAM and 
SAM) into SIP (INVITE). That means including two explicit indications in the 
INVITE:

1. Explicitly indicating end-of-dial. The egress GW then knows when the 
ingress GW already decided that the number is complete and it can avoid the 
extra timeout before sending its IAM. Without this explicit indicator, every 
egress GW must first presume overlap operation for every INVITE it receives, 
unless it has the numbering plan data base to tell it otherwise. This 
presumption of " overlap" operation contradicts the idea that en-bloc is the 
"default" or preferred operation.

2. Explicitly indicating whether this is the first INVITE (resulting from an 
IAM) or a succesive INVITE (resulting from an SAM). This allows the egress GW 
to ensure that it does not send an IAM when another GW may already have sent 
one for a subset of the digits. That is, it allows the egress GW to verify if 
all INVITEs for one call are routed the same and to not act on ones that are 
not.

Mike Pierce
Artel

---

From: Adam Roach <[email-masked]>
Date: Wed, 3 Jul 2002 14:21:14 -0400

On behalf of myself and the other parties who have asked,
I am reiterating my request that you stop sending HTML-
formatted mail to the list. AOL works with several standard
clients that have the ability to play well with others. One
such program is Eudora, available as a free download from
http://www.eudora.com/

Comments inline.

-----Original Message-----

> Consider a case in which the originating PSTN is fully
> capable to determining end-of-dial, for example, the
> originating user is an ISDN phone. The user in the US
> dials a number in Indonesia (which has lots of different
> length numbers). The ISDN signaling sends the complete
> number to the local switch (maybe the user hit an
> "end-of-dial" button or the terminal applied a time-out
> or the complete number was pulled from a pre-built speed
> dial list). The local switch sends an IAM which also
> indicates that the number is complete. The ingress GW
> gets this IAM, puts the complete number in the INVITE,
> but throws away the indication from the IAM that it is
> a complete number. 

> The egress GW gets the INVITE and recognizes the country
> code for Indonesia and is connected to the PSTN by an
> interface that does not support overlap. It doesn't have
> the data base necessary to determine if this particular
> number in Indonesia is complete, so it must apply the
> overlap to en-bloc conversion procedures, which is a 4-6
> second timeout before sending its IAM. This unnecessarily
> delays call setup. 

Wow. I finally see what you're getting excited about. For
normal PSTN users, international dialling will have a small
(~5 second) post-dial-delay imposed by their end office
when making international calls. For ISDN connected users,
international dialling will have a small (~5 second) post-
dial-delay imposed by the terminating gateway. This is
completely unacceptable. By paying for a premium service,
the ISDN users should *obviously* expect to have the
network bend over backwards to elminate this delay. To
accomodate this expectation, we should definitely hash
out a solution to this corner case and make everyone wait
for PSTN/SIP gateway deployments.

(As a related, somewhat unscientific poll, I'd like everyone
on the list -- everone -- who has ISDN and regularly uses it
to make international voice calls to please send me a private
e-mail response to let me know about it. I'm serious. Don't be
shy.)

/a

---

From: [email-masked]
Date: Wed, 3 Jul 2002 15:04:58 EDT

In a message dated 7/3/02 2:21:30 PM Eastern Daylight Time, 
[email-masked] writes:

Adam:

The problem isn't just with an ISDN orginating party. (I get your sarcasm 
that there may not really be that many ISDN users anyway!)

When an analog subscriber in the US makes a call to Indonesia, a local 
exchange must perfom a timeout to determine end-if-dial. With the description 
in the overlap draft, the egress GW (connected to a non-overlap network) must 
then perform another timeout if it doesn't have the data base to tell it the 
proper length for this particular number. This adds another 4-6 seconds to 
the call setup, which it considered bad. As I've described, there is a very 
simply fix.

As I've described, this "corner case" (overlap to the very few places in the 
world that don't have uniform or "closed" numbering systems) is going to mess 
up the normal case, since the egress GW must assume overlap for every call, 
unless it has the specific data base to tell it otherwise.

Mike Pierce

---

From: "Alexeitsev, D" <[email-masked]>
Date: Thu, 4 Jul 2002 13:14:55 +0200

Thank you for the answer

comments inline

Greeting,
Denis Alexeitsev

-----Ursprüngliche Nachricht-----
Von: Adam Roach [mailto:[email-masked]]
Gesendet am: Mittwoch, 3. Juli 2002 20:03
An: 'Alexeitsev, D'; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Betreff: RE: [Sipping] WGLC for ISUP overlap signaling

We are not "defining new procedures" for T10, since our behavior
TOWARDS THE ISUP NETWORK is precisely, 100% compliant with what is
described in Q.767. The jurisdiction of Q.767's procedures ends
once you get into the SIP network,

[DA]That is why one can not use the T10 Timer as it's only jurisdiction lies in the ISDN/PSTN network. I'm supporting the procedures proposed in this section, but it is a misuse of the defined timer T10 for the proposes it is not designed for. Again it would be correct to define own interworking timer with the functionality as described in the overlap draft.

---

From: Adam Roach <[email-masked]>
Date: Sun, 7 Jul 2002 23:38:45 -0400

> [DA]That is why one can not use the T10 Timer as it's only 
> jurisdiction lies in the ISDN/PSTN network. I'm supporting 
> the procedures proposed in this section, but it is a misuse 
> of the defined timer T10 for the proposes it is not designed 
> for. Again it would be correct to define own interworking 
> timer with the functionality as described in the overlap draft.

The distinction you're trying to make is purely semantic.

The SIP INVITE will be generated when we are certain that all
the digits are collected. The fact that such knowledge is
gained by the expiration of an ISUP timer has no bearing on
the situation.

Yours is such a patently ridiculous and pedantic objection that
I will not waste any further time trying to debate such an
academic and pragmatically nonexistant point.

/a

---

From: [email-masked]
Date: Mon, 8 Jul 2002 17:33:44 EDT

[MAP] I believe Dennis has a good point, although maybe it didn't come 
through perfectly in English. (Entschuldigen Sie, Dennis, Ich meine nicht 
dass Ihr Englisch schlect ist!)

Since "T10" is the name of the timer in ISUP, and ISUP is also executing in 
the same device as SIP, the description of SIP should not refer to using 
"T10". It makes it read as if it is specifying how ISUP functions. The SIP 
overlap draft should refer to its own timer, with some other name or number, 
and just needs to say that it should use the same value as T10 defined in 
ISUP.

Yes, I suppose the comment is "purely semantic", but then, so are many other 
worthwhile editorial comments made on drafts.

Mike Pierce
Artel

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Sun, 14 Jul 2002 06:49:14 -0400

There is a real issue beneath this discussion.  The draft at this point in
its descritption takes the implicit point of view that ISUP procedures and
interworking are all done together.  The alternative point of view is that
ISUP does its job, then passes the appropriate information on to the
interworking function which acts on the SIP side (and vice versa). 

Your reference to the T10 timer describes an ISUP procedure.  What the
interworking function cares about is that digits are ready to send.  So
instead of talking about T10 trhe draft should simply say "when ISUP
procedures determine that digits are ready to send, ...".

-----Original Message-----
From: Adam Roach [mailto:[email-masked]]
Sent: Sunday, July 07, 2002 11:39 PM
To: 'Alexeitsev, D'; Adam Roach
Cc: [email-masked]; Hogg, Chris [MOP:MA01:EXCH]
Subject: RE: [Sipping] WGLC for ISUP overlap signaling

/a