TELECOM ACCESS STANDARDS NEWSLETTER NO. 98 MAY/JUNE 1997


CONTENTS

1. PTC 200: 1997 EDITION
2. PRE-APPLICATION ENQUIRIES
3. NEWSLETTER ON INTERNET
4. ENHANCEMENTS TO ISDN
5. "CALLTRACK" SERVICE INTRODUCTION: CPE IMPLICATIONS
6. YEAR 2000 - IS YOUR EQUIPMENT AFFECTED?
7. ALARM SYSTEM TEST CALLS AND PTC COMPLIANCE
return to index

1. PTC 200: 1997 EDITION

We have been working on amendments and additions to PTC 200:1996 almost since the original version was published. This work has now been completed and, rather than issue almost a complete set of replacement pages, it has been decided to re-issue the document as PTC 200:1997.

Key features of the new edition are requirements for Caller Display CPE (ref Newsletters 96 and 97), more information on "series" and "bridging" devices, and full details on the new "Ringer Number" or "RN" measurement arrangements. These are intended to cover the reliable assessment of ringing performance where multiple devices are connected on the same line. This has been a major source of problems with our
earlier 3-wire system and the less stringently assessed "RAL" ringing load system.

In addition, we have included Appendix 2, which covers testing procedures, and many editorial and consequential amendments.

PTC 200:1997 will be made available to registered purchasers of PTC 200: 1996 for a nominal fee of $50, inclusive of GST and postage. It is supplied without the binder which, of course, was already supplied with the earlier edition.
Return to Contents


2. PRE-APPLICATION ENQUIRIES

Access Standards staff frequently get enquiries and information related to specific products before a Telepermit application is made. As with application submissions that are received "progressively" over a period of weeks or months, these enquiries can result in confusion as to what was supplied at the "enquiry stage" and what is still outstanding. Sometimes it results in two separate files of information, each with no
reference to the other because there has been nothing to connect them. We stumble across these situations regularly, or sometimes it is only a niggling recollection that prompts us to search.

We now propose to extend our application reference number system to include these enquiries. This will enable us to relate these initial papers more easily to the application when it finally arrives. In future, we will provide a reference number when responding to any written enquiry. However, these initial enquiries will still not be regarded as applications until the full submissionhas been received. "Enquiries" and partial
submissions will not jump the queue and gain any benefits relative to those suppliers who have taken the trouble to prepare complete applications right from the start.

On a similar note, there have been some problems over Telepermit number reservations. If the applicant makes the formal application some time after the initial reservation but does not refer to that reservation, then there is a strong risk that a further Telepermit number will be allocated. Also, since a statement of charges is given at the time of reservation, it follows that the applicant may be charged twice for the same
Telepermit grant.

Inorder to reduce the above problems, suppliers are requested to usef the reference number allocated to their enquiry or reservation in any follow-up correspondence, including their Telepermit application when it is finally made. This will help us to avoid missing relationships between documents. Similarly, if a product has a Telepermit and there is some enquiry in relation to it, please quote the Telepermit number. While an
enquirer/applicant might be dealing with one product and have no problems keeping his correspondence with us in one place, this is not the position we are in with many hundreds of applications and enquiries each year and now almost 4 000 different Telepermitted products to manage.
Return to Contents


3. NEWSLETTER ON INTERNET

We are investigating possible use of the Internet for distribution of this newsletter. If we proceed, details will be advised in a later issue, but at this stage we would like some feedback from our readers. Our preference would be for everyone to use the Internet rather than receive a hard copy mailed out by us. However, we do appreciate that this will not necessarily be convenient to all current readers. We therefore request that you provide some feedback by informing us of your preference.

Attached to this issue is a form which will provide a simple means of response, and we also invite readers to take this opportunity of commenting generally on these newsletters and their content. If we do not get a response from individuals on our mailing list and we decide to proceed, we will assume that those particular readers are happy to use the Internet. We will then cease mailing copies to them once the arrangements are complete.
Return to Contents


4. ENHANCEMENTS TO ISDN

Telecom's ISDN was initially based on the Blue Book version of ITU Recommendations Q. 931 and Q. 932 published in 1988. Since then both Recommendations have been revised, with Q. 932 being updated in March 1993 when a number of additions were made.
One of these enhancements is the Generic Notification Procedures described in Section 9 of Recommendation Q. 932. This allows for the sending of a 'NOTIFY' message during any state of a call. Notifications can be characterised by the following properties:-

(a) They do not cause a change of state on either side of the user-network interface;

(b) they represent a one-way flow of information that requires no response; and

(c) they provide additional information that can be discarded.

Several additional values have been added to the 'Notification' indicator information element. An example is "call is diverting".

It has been noticed that some terminals object to the 'NOTIFY' message by sending a 'STATUS' message with a cause, reporting "message not compatible with call state". Often there is no cause diagnostic reporting which message is being objected to. In some situations this causes the network to clear the call.

Also, some terminals object to the additional 'Notification' values and send a 'STATUS' message with cause "invalid information element contents". This does not cause any difficulty but does increase the messages on the D-channel and and, as a result, could affect performance.

The reliability of ISDN would be improved if user terminals, particularly PABXs, were enhanced to accept these new messages - or at least not send a 'STATUS' message.

Necessary changes will be included in the revised version of TNA 134 and TNA 135 currently under preparation, and which may possibly be merged into one document.
Return to Contents


5. "CALLTRACK" SERVICE INTRODUCTION: CPE IMPLICATIONS

Further to the announcement in Newsletter No. 92 of a proposed "call control service", Telecom has introduced "CallTrack", which provides for customers to customise their monthly telephone account formatting. Charges can typically be sorted according to the person that made the call or the client account to which the call is to be billed by the customer. The formatted account is particularly useful for bill reconciliation, cost allocation and on-charging by business customers.

This service relates only to Telecom's monthly account formatting. As such, it does not operate in conjunction with calls made via bypass networks where the other network is handling the billing.Customers subscribing to this service will dial the wanted number and then be prompted to input one of a pre-arranged set of control numbers. These control numbers will typically be account codes for particular clients, each of between 1 and 5 digits, or PIN's of 4 or 5 digits indicating individual callers. Where 4 digits or less are used for either an account number or PIN, it is recommended that it be followed with a # to avoid a brief time-out delay which can be up to 5 secs.

These control numbers can be made optional or mandatory. Where the mandatory code option has been selected and the voice prompt cannot be recognised and manually acted upon, then a # should be added to the end of the called number followed by a mandatory timed pause of 2 to 4 secs. The # is not required for Telecom national or local numbers, but is required for international numbers and may also be required
for alternative network providers. To simplify matters, it is recommended that the # be added to all called numbers.

Where the optional code option has been selected, inserting the # after the called number is not necessary, but it will reduce post dialling delay for calls to international and alternative network numbers.

Should customers subscribe to this new Telecom service and make control numbers
mandatory, then any auto-calling CPE devices connected to the lines concerned will
need to be set up to work with CallTrack. This requirement also applies to manually
initiated calling equipment which is capable of making repeat attempts automatically,
such as fax machines. Details are as follows:-

(a) Auto-calling equipment is not able to detect the voice prompt, which may be delayed in some

circumstances. To ensure that fully automatic calls to all networks, it will be necessary to programme a # and a "pause" of between 2 and 4 seconds at the end of the called number, followed by a valid control number. This applies to ALL automatically initiated calls.

(b) For manual call initiation using memory diallers, it will be advisable to set up the more commonly used control numbers on separate memories and simply press the appropriate button on receipt of the voice prompt. Should it be necessary to combine the control code with the called number so that both

can be dialled with one key press, it will be necessary to add the # at the end of each digit string and insert the 2-4 second pause, as explained above.

(c) For automatically initiated calls where 4 digits or less are used for the control number, it should be followed with a # to avoid a further time-out delay.

(d) These requirements also apply to non-voice devices such as modems and fax machines when they automatically make repeat call attempts and are connected to lines set up for mandatory control numbers.

(e) Because they are usually looked after by a maintenance organisation different to that which manages a customer's other telecommunications services, it is particularly important that auto-calling alarm systems are not overlooked when arranging such re-programming.

(f) If CPE is not capable of being reprogrammed for mandatory CallTrack or the customer is reluctant to make the necessary programming changes, it will be necessary to either connect that CPE to a CallTrack line set up for optional control codes or to a line which does not have the CallTrack service.

(g) Care is also needed with customer-controlled call diversion where the called line is set up for mandatory control number insertion. Diversions which lead to a chargeable call, such as to a cellphone, should be avoided. Otherwise, the calling party could be prompted to input some unknown control number and the call will be dropped when this is not done.
Return to Contents


6. YEAR 2000 - IS YOUR EQUIPMENT AFFECTED?

There is increasing publicity about the potential problems for computer programmes incorporating calendar data when we reach the year 2000. For example, where any of these programmes hold the year in two-digit format, the "00" of "2000" could well end up being recognised as "1900" and cause total confusion at the very least. There are also other potential difficulties embraced by the "Year 2000 problem" which are
likely to affect equipment other than computers and will require thorough investigation. If these problems are not addressed thoroughly, in many cases the systems concerned, together with associated equipment, are likely to actually "crash".
Telecom itself is facing costs of some millions of dollars to upgrade its own computer systems, so telecommunications systems are certainly not exempt from the problem. Since we now have nearly 4000 different types of CPE connected to the Telecom network, it seems likely that many of these will have problems. Most simple CPE items do not have calendars or date displays, but there many more complex
devices which, for example, may have least cost routing arrangements based on real time calendars that determine weekends and holidays. Simpler devices may just end up showing February 29 on non-Leap Years, but as stated above, the potential problems are wider than this and may cause systems to fail in a much more serious manner.

The computer industry has concluded that there is a need for a vast amount of reprogramming work, all of which has to be done before 1 January 2000 - now less than 3 years away! What could well be overlooked is computer and microprocessor-based control systems in telecommunications equipment. In view of this,
it is suggested that CPE suppliers checkout all their products, both past and present, to ensure they do not go into total confusion on 1.1.2000 (or should I use the official International Standard date format of 2000-01-01?). In fact, while checking this date, it is recommended that suppliers also check whether there are any other critical dates or day counters within equipment which could affect its operation.

The main point in raising this matter is that reprogramming or modifying equipment may take some time and it will be most embarrassing to suppliers if they do not become aware of any problems until after they have actually occurred. If this happens, our mutual customers could be severely inconvenienced.
Return to Contents


7. ALARM SYSTEM TEST CALLS AND PTC COMPLIANCE

In Newsletter No. 83, I mentioned the problems caused by daily alarm test calls. It appears that these same problems are continuing as more and more alarms systems are installed. Areas of concern are:-

(a) test calls made during "normal calling hours" (as distinct from during the very early morning, when few customers are likely to be using their telephones);

(b) test calls holding the line for long periods;

(c) test calls breaking into an existing call and not releasing it before initiating another call;

(d) where customers are either not aware of the fact that their alarms may make test calls from time to time, or are not being warned what actually happens during a test call.

Item "c" includes alarm systems which, on an existing call, inject one or more strings of DTMF signals over the top of conversation to the other party. This typically occurs where the alarm is not connected for line grabbing, but simply plug connects via a "break-in" double adapter, which is also used for connecting one of the telephones. If the customer is using another telephone in the house, the alarm is likely to attempt a
test call and inject DTMF tones over the conversation. Having failed to make a connection, it retries after a brief delay. This can happen several times if the customer is still engaged on the original call.

Many customers are not very familiar with the operation of their alarm systems and report these incidents as line faults, or even as "someone interfering with their phones". As a result, the customer is inconvenienced and Telecom staff are called out to attend the "fault". Most alarm companies are understood to set their customers' alarms to dial back at the same time each day. Some prefer to use "random" settings for each
individual alarm to spread the traffic, while others set the time for test calls in the very early morning, when the customer is unlikely to be using the telephone. Unfortunately, there can be some gradual time drift due to clock inaccuracies and calls can end up being made during normal conversation times.

Where the alarm is to be set up for line grabbing, clause 10.7 of PTC 200 requires that the alarm is to grab the line, open the loop for at least 5 seconds, reloop the line and then either detect dial tone or pause at least 2 seconds before dialling. While line grabbing is obviously justified in a real emergency, there seems to be little real need to break into the customer's conversation simply to make a routine test call. It is
suggested that a better approach would be to check the line status BEFORE making each test call.

The "faults" described are solely due to privately-owned CPE, not to the service provided by the Telecom network. Alarm installers and suppliers are reminded that Telecom service staff called out to problems caused by private equipment are entitled to charge the customers concerned. In turn, the customer is then entitled to claim against the alarm supplier/installer.

To avoid these problems, alarm companies should check that their systems hold a Telepermit, and that they do still comply with Telecom's PTC requirements. In particular, the line grabbing arrangements need to comply with the above simple rules to work reliably and effectively. If they do not, there is always the risk that a genuine alarm call could fail.

RECOMMENDATION
Where systems are deliberately set up for "daytime test calls", or where time drift is
possible, alarm companies should warn their customers as follows:-

(a) That line interruptions may occur,

(b) describe what the customer can expect to hear when a test call occurs, and

(c) advise the customer who to contact when problems are experienced.

(This should not be Telecom)
Return to Contents




PETER WHEELER
Manager
Access Standards Technology
Return to Contents



To: Access Standards Section

Telecom New Zealand Ltd
PO BOX 570
WELLINGTON


Re: ACCESS STANDARDS NEWSLETTER

I am/We are interested in use of the Internet to access information published in the
Access Standards Newsletter, in place of a mailed out copy:

YES


NO



Comments on Newsletter
content:..............................................................................................

.......................................................................................................


.......................................................................................................

.......................................................................................................

.......................................................................................................

.......................................................................................................

.......................................................................................................

.......................................................................................................


Signed:.......................................................

Date:......................................

Name of Company......................................................................

Address.....................................................................................

.................................................................................................

MAY/JUNE 1997 Access Standards Newsletter No. 98



Return to Contents