<PAGE> 1
================================================================================
SECURITIES AND EXCHANGE COMMISSION
Washington, D.C. 20549
------------------------------
FORM 10-Q/A
Amendment No. 1 to Form 10-Q
X QUARTERLY REPORT PURSUANT TO SECTION 13 OR 15(d) OF THE SECURITIES EXCHANGE
- --- ACT OF 1934 ---
For the quarterly period ended SEPTEMBER 30, 1997
----------------------------
__ TRANSITION REPORT PURSUANT TO SECTION 13 OR 15(d) OF THE SECURITIES
EXCHANGE ACT OF 1934
For the transition period from
-------------
Commission File Number 0-22210
-------------------------
SUMMA FOUR, INC.
(Exact name of registrant as specified in its charter)
Delaware 02-0329497
(State of Incorporation) (IRS Employer Identification Number)
25 Sundial Avenue, Manchester, New Hampshire 03103
(Address of registrant's principal executive office)
(603) 625-4050
(Registrant's telephone number)
------------------------------
Indicate by check mark whether the registrant (1) has filed all reports
required to be filed by Section 13 or 15(d) of the Securities Exchange Act
of 1934 during the preceding 12 months (or for such shorter period that the
registrant was required to file such reports), and (2) has been subject to
such filing requirements for the past 90 days. Yes X No
--- ---
Indicate the number of shares outstanding of each of the issuer's classes of
common stock as of the latest practical date.
Common Stock, $.01 par value 5,752,399
Outstanding as of October 31, 1997
=============================================================================
<PAGE> 2
FORM 10-Q/A
PART II
PAGE 13
SUMMA FOUR, INC.
INDEX TO FORM 10-Q/A
Page (s)
--------
Part II - Other Information: 13
Item 6 - Exhibits and Reports on Form 8-K
Signature(s) 14
EXHIBIT NO. DESCRIPTION
10.1 Lease Agreement, dated July 3, 1997, by and between the
Registrant and Bay Business Centers, Inc.
10.2 Products and Services Agreement, dated August 4, 1997,
by and between the Registrant and D2 Technologies Inc.
10.3 Software License and Maintenance Agreement, dated
August 4, 1997, by and between the Company and D2
Technologies, Inc.
11.0 Statement Re: Computation of per Share Earnings (1)
27 Financial Data Schedule (1)
(1) Incorporation herein by reference to the Registrant's Form 10-Q for the
Quarter Ended September 30, 1997 filed with the Securities and Exchange
Commission on November 12, 1997.
<PAGE> 3
FORM 10-Q/A
PART II
PAGE 14
SIGNATURES
----------
Pursuant to the requirements of Securities Exchange Act of 1934, the registrant
has duly caused this amendment to the report to be signed on its behalf by the
undersigned thereunto duly authorized.
Summa Four, Inc.
Date: June 19, 1998 By: /s/ Jeffrey A. Weber
----------------------
Jeffrey A. Weber
Vice President and Chief
Financial Officer
<PAGE> 1
EXHIBIT 10.1
LEASE AGREEMENT
1. PARTIES
-------
This Lease, dated for reference purposes only, Thursday, July 3, 1997, is made
by and between BAY BUSINESS CENTERS, INC., Lessor, and SUMMAFOUR hereinafter
called Lessee.
2. PREMISES
--------
Lessee hereby leases from Lessor the premises described as 2121 No. California
Boulevard, Suite #290, Walnut Creek, CA 94596, Office #220 & #221.
3. TERM
----
A one year term shall commence on August 1, 1997, and shall continue until July
31, 1998. Lessee shall give a 60-day notice in writing of its intent to renew or
cancel Lease Agreement, prior to termination date of July 31, 1998. If a 60-day
notice is not rendered, Lessor will consider Lease Agreement to be renewed for
an additional term, at the then going rate. Holdover - in the event Lessee holds
over beyond the end of the Lease term, the monthly recurring charges shall be
assessed at 150% their monthly rate and the holdover period shall be for no less
than one month.
4. POSSESSION
----------
In the event the offices are not available within 30 days of the commencement of
the term, Lessee shall have the right to terminate the Lease without further
obligation. The parties further agree that if the leased premises are made
unusable, in whole or in part by fire or other casualty not due to negligence of
Lessee, Lessor may at its option, terminate the lease upon notice to Lessee. In
the event the leased premises are not repaired within 90 days, Lessee reserves
the right to terminate the Lease. The monthly rent shall be abated on a per diem
basis for the portions of the leased premises that are unusable. In the event
that Lessor shall permit Lessee to occupy the leased premises prior to the
commencement date of the term, such occupancy shall be subject to all of the
provisions of this Lease Agreement. Such early possession shall not advance the
termination date hereinabove provided.
5. RENT
----
Lessee agrees to pay Lessor the sum of $1490.00 per month plus $55.00 per phone
set for phone equipment rental per month due on the first day of each month. Any
installment
Page 1 of 8
<PAGE> 2
of rent or any other recurring charge due from Lessee not received by Lessor
within five (5) days after such amount is due shall be assessed a late charge
equal to ten percent (10%) of such overdue amount plus $50.00. Clerical Services
and Other Services incurred shall be invoiced semi-monthly on the 15th and last
day of each month. Payment for said services are due and payable within thirty
(30) days of billing date. A late charge equal to two percent (2%) plus $10.00
will be assessed on said services if payment is not received within thirty (30)
days of billing date. If an installment for rent or invoice for services is
overdue more than thirty (30) days, Lessor has the right to discontinue all
services upon the thirty-first (31st) day of delinquency. Billing inquiries
and/or change of address should be directed towards: Bay Business Centers, Inc.,
Attn: Accounting Dept., 2010 Crow Canyon Road, Suite #100, San Ramon, California
94583. In the event this Lease Agreement term starts on a day other than the
first of the month, the monthly recurring charges shall be prorated for the
current month and collected with the first full month plus last month.
The monthly rental rate stated herein is predicated on providing office space
and services, as provided in Paragraphs 13 and 14, for 2 person(s).
Additional Reception Service $100.00/each additional person - w/o voice mail
(receiving calls & callers) $125.00/each additional person - with voice mail
Lessee hereby agrees to notify Lessor in writing no less than thirty (30) days
prior to addition of staff members for which Lessor will provide services.
6. PREPAID RENT & OPENING CHARGES
------------------------------
Concurrently with Lessee's execution of this Lease Agreement, Lessee shall pay
the Lessor the sum of:
RECURRING CHARGES (1ST & LAST)
Office Rent(lst & last)(recurring charge) ............................. $2980.00
Additional Users (lst & last)(recurring charge) ...........................$0.00
Furniture: N/A
(lst and last)(recurring charge) ..........................................$0.00
Mail Forwarding Service (lst & last)(recurring charge) ....................$0.00
Storage Rental (lst & last) (recurring charge) ............................$0.00
Additional Voice Mail Box Rental
($25/each/month)(lst & last)(recurring charge) ........................$0.00
Voice Mail Paging (lst & last)(recurring charge) ..........................$0.00
Phone Line/ISDN Service - Dial Tone
(lst & last)(recurring charge) ......................................$360.00
Phone Equipment Rental (lst & last)(recurring charge) ...................$220.00
Speed Dial (lst & last)(recurring charge) .................................$0.00
Page 2 of 8
<PAGE> 3
Conference Calling (lst & last)(recurring charge) .......................$0.00
Call Forwarding (lst & last)(recurring charge) ..........................$0.00
Delayed Call Forwarding (lst & last)(recurring charge) ..................$0.00
Pacific Bell Directory Listing ($2/mo.)(lst & last)(recurring charge) ...$4.00
Copy Pkg. (lst)(recurring charge) .......................................$0.00
Conference Pkg. (lst)(recurring charge) .................................$0.00
Administrative Pkg. (lst)(recurring charge) .............................$0.00
Secretarial Pkg. (lst)(recurring charge) ................................$0.00
Parking (lst & last)(recurring charge) ................................$220.00
ONE-TIME/INSTALLATION CHARGES
Administrative Start-up Fee (one-time charge) .........................$250.00
Additional Users Administrative Start-up Fee (one-time charge) ..........$0.00
Cleaning Fee ($200/Ofc.)(one-time charge) .............................$400.00
Furniture Move Fee (one-time charge) ....................................$0.00
Furniture Set-Up Fee (one-time charge) ..................................$0.00
Lobby Directory Listing (one-time charge) ..............................$40.00
Key Deposit ($65/set X 2 Key Set(s))(refundable) ......................$130.00
Single Key Deposit (N/A) ................................................$0.00
Storage Installation (one-time charge) ..................................$0.00
Voice Mail Installation (one-time charge) ...............................$0.00
ISDN Installation (2 lines plus cable & installation) ...............$1,000.00
Phone Line Installation (4 lines, one-time charge) ....................$480.00
Fax/Modem Install (1 line, one-time charge) ...........................$185.00
Phone Equipment Programming (one-time charge) .........................$370.00
Calling Feature Installation (one-time charge) ..........................$0.00
-----
TOTAL ......................................................$6,639.00
=========
*PHONE LINE SERVICE represents monthly fee for dial tone. PHONE LINE USAGE
(outgoing calls) is a variable charge and will be billed semi-monthly, due
within 10 days of statement date.
7. USE
---
The premises are to be used for sales and administrative purposes only.
8. CONDITIONS
----------
Lessee shall not disturb, annoy, endanger or inconvenience other tenants in the
building or suite, nor use the premises for any immoral, unlawful, or sleeping
purposes, nor violate any law or ordinance or commit waste, nuisance or damage
upon or about the property.
Page 3 of 8
<PAGE> 4
9. REPAIRS, MAINTENANCE AND ALTERATIONS
------------------------------------
Lessee shall at all times during the term hereof, at its sole cost and expense,
keep the premises and every part thereof in good condition and repair, except
damage thereto by fire, earthquake, act of God or the elements. Lessee hereby
waives the right to make repairs at Lessor's expense under any law, statute or
ordinance with respect thereto now or hereafter in effect. Unless otherwise
expressly provided herein, Lessor shall not be required to make any improvements
or repairs of any kind or character on or to the leased premises during the term
of this Lease Agreement; however, Landlord will provide routine maintenance for
any damage or problems not caused by Lessee. Lessee shall return, upon
expiration of this Agreement the premises in their original configuration,
design, and condition to Lessor. Lessee shall, at its own cost and expense,
repair or replace any damage or injury to the leased premises, or any part
thereof, caused by Lessee or Lessee's agents, employees, invitees, licensees, or
visitors; provided, however, if Lessee falls to make such repairs or
replacements promptly, Lessor may, at its option, make such repairs or
replacements, and Lessee shall reimburse the cost thereof to Lessor on demand,
together with interest at the maximum annual rate permitted by law from the date
of such work.
If Lessee vacates the premises and leaves the premises in a condition requiring
painting, carpet cleaning, or other maintenance to restore the premises to
leasable condition, a minimum fee of $200.00 per office will be assessed and
confirmed in the termination meeting (if conducted) or within 30 days of date of
vacancy.
Lessee agrees to keep a floor mat under any and all chairs with rollers/wheels
at all times to protect the carpeting.
10. ABANDONMENT
-----------
If Lessee abandons or vacates the premises, Lessor may at its option terminate
this Lease Agreement, re-enter the premises and remove all property.
11. ESSENCE OF TIME
---------------
Time is of the essence of this Lease Agreement and all provisions hereof.
12. INSURANCE
---------
Lessee shall indemnify and hold harmless Lessor as respects to any bodily injury
or property damage arising out of their operations and business conducted on
premises. Lessee shall maintain liability insurance in amounts no less than
$300,000 combined single limit for bodily injury and property damage. Lessee
shall provide Lessor with a certificate of insurance as evidence of the above
conditions and Lessor shall be named as an additional insured.
Page 4 of 8
<PAGE> 5
13. SERVICES
--------
Included in the monthly rental specified in Paragraph 5 herein, Lessee shall be
entitled to the following clerical and administrative services:
Full-time Receptionist Service Mail Processing Service
(8:30 a.m. - 5:00 p.m., Monday-Friday Incoming Mail Sorted
excluding holidays) Outgoing - daily mail 10 pcs.
Telephone Answering Voice Mail 24 hrs./day,
8:30 a.m. - 5:00 p.m. 7 days/week
Monday-Friday, by Receptionist, Complimentary 100 Voice Mail
(excluding holidays) Msgs./Box
Additional messages @ $.35/ea.
Access to Office, Building, & Copier
24 hrs./day, 7 days/week
Hourly Office Rental/ Access to:
Conference Room Facilities Secretarial Services
By Reservation 8:30 a.m. - 5:00 p.m.
4 Hours/month included Monday-Friday,
(non-cumulative) (excluding holidays)
(Billed as Utilized, see Exhibit B/C)
Lessee hereby agrees all telephone equipment AND line services will be
coordinated by Lessor with Lessor's telephone vendor. Lessee shall not modify
nor change outlets, telephone sets, or jacks.
14. SERVICES & NON-SERVICE ITEMS
----------------------------
Services and non-service items shall be invoiced semi-monthly on the 15th and
last day of each month. Payment for said services are due and payable within
thirty (30) days of billing date. A finance charge of 2% per month will be
assessed for all services and recurring charges unpaid beyond 30 days of the
invoice date.
At the end of a term, all charges and credits will be applied. It is understood
freight bills and vendor charges may take up to 60 days to pass through Lessee,
therefore a 90-day period may be required to reimburse credits or conclude final
account balance.
If collection time is required due to delinquent account status a fee of
$45/hour will be assessed for administrative time at a minimum of $9.00 per
collection contact.
Page 5 of 8
<PAGE> 6
SERVICES
- --------
Secretarial Service Minimum billable unit 1/10
See Exhibit B/C for Rates of an hour.
Word Processing (keyboarding) Minimum billable unit 3/10
See Exhibit B/C for Rates of an hour.
Minimum per page 3/10
of an hour (input).
Editing - Minimum 2/10 of an hour.
Standard Turnaround - 1-3 pages (24 hrs.) 4 or more pages - turnaround
determined by Bay Business Centers, Inc.
Lessee agrees that during the term of this Agreement and for six (6) months
after its termination will not offer employment to or hire any of the employees
of Lessor. If Lessee does not keep that agreement, Lessee will be liable to
Lessor for damages in the sum of twenty-five percent (25%) of the annual
compensation of each employee involved, it being mutually agreed by Lessee and
Lessor that this provision for liquidated damages is reasonable and that the
actual damage which would be sustained by Lessor as the result of a failure to
keep the agreement would be, from nature of the case, impracticable or extremely
difficult to fix.
Further, Lessee shall not provide, utilize, or sell any services or non-service
items, which are provided by Bay Business Centers, Inc., as listed on Exhibit
B/C to other tenants or clients of Bay Business Centers, Inc., or for any other
person or company.
Lessee shall not contract with an independent contractor, temporary personnel
agency, or individual for the purpose of providing secretarial, word processing,
or any services Bay Business Centers, Inc. provides.
If Lessee wishes to employ an administrative assistant or clerical staff member,
it is with the understanding an additional office must be leased from Bay
Business Centers, Inc. and prior written approval is obtained from Bay Business
Centers, Inc. for its use.
15. NOTICES
-------
In every instance where it shall be necessary or desirable for the Lessee to
serve any notice or demand upon the Lessor, such notice or demand shall be sent
by United States "Registered" or "Certified" mail, postage prepaid, addressed
to:
Ms. Marilyn L. Newton
BAY BUSINESS CENTERS, INC.
2010 Crow Canyon Road, Suite 100
San Ramon, CA 94583
Page 6 of 8
<PAGE> 7
or at such other address of Lessor, as may appear on the records of Lessee. Any
notice or demand to be given by the Lessor to the Lessee shall be effective if
mailed to (Lessee's administrative office):
Ms. Pam Carter
SUMMAFOUR
25 Sundial Avenue
Manchester, NH 03103
Notice mailed as aforesaid shall be deemed to have been served at the time of
postal meter cancellation date.
16. OCCUPANCY/USE OF PREMISES
-------------------------
Lessee shall not assign this Lease nor permit the occupancy or use of any part
thereof without the written permission of Lessor.
Lessee will not install or maintain a coffee maker or copier machine in Lessee's
office. Lessee further acknowledges smoking is not permitted within the suite
and must be restricted to outside of the suite.
17. ATTORNEYS FEES
--------------
In an event of any legal action or proceeding brought by either party against
the other under this Lease Agreement, the prevailing party shall be entitled to
recover all its costs and expenses, including without limitation the fees and
costs of appeal, if any, of its attorneys of such action or proceeding in such
amount as is reasonable.
LESSEE: LESSOR:
SUMMAFOUR BAY BUSINESS CENTERS, INC.
By: /s/ Thomas A. St. Germain By: /s/ Marilyn Newton
-------------------------- ------------------
Title: SVP Title: President
Name Printed: THOMAS A. ST. GERMAIN Name: Marilyn L. Newton
Page 7 of 8
<PAGE> 1
EXHIBIT 10.2
EFFECTIVE DATE: 4 August 97 ________
AGREEMENT #: ____________________
CONTRACT FOR PRODUCTS AND SERVICES AGREEMENT
THIS AGREEMENT is made and entered into as of the 4th day of August, 1997,
(hereinafter "Effective Date") by and between Summa Four, Inc., a Delaware
Corporation with its principal place of business at 25 Sundial Avenue,
Manchester, New Hampshire, 03103-7251 (hereinafter "Summa Four"), and the
Contractor whose name and address is set forth below (hereinafter "Contractor"):
================================================================================
Company: D2 TECHNOLOGIES, INCORPORATED. MR. DAVID WONG, PRESIDENT
- --------------------------------------------------------------------------------
Street: 104 WEST ANAPAMU STREET, SUITE J.
- --------------------------------------------------------------------------------
City: SANTA BARBARA
- --------------------------------------------------------------------------------
State: CALIFORNIA Zip: 93101
================================================================================
RECITALS
A. Summa Four is engaged in the business of developing, marketing, supporting
and selling telephony Product(s), computer Product(s) and related
accessories; and
B. Contractor is a company qualified in performing a wide variety of technical
services; and
C. Summa Four desires to hire Contractor at will, to provide certain services
or products (hereinafter referred to as the "Work Product") as shall be
more fully described in an Appendix A attached to this Agreement; and
D. Contractor is desirous of performing the Services for Summa Four as an
independent contractor pursuant to the terms hereof.
NOW THEREFORE, in consideration of the mutual promises herein contained, the
Parties agree as follows;
1. TERM OF AGREEMENT. This Agreement shall have a maximum duration of 180
working days from the above stated Effective Date. Nevertheless, this
Agreement and the Contractor's performance hereunder may be terminated by
Summa Four at any time on written notice to Contractor. This Agreement may
only be extended by mutual written Agreement of the Parties.
<PAGE> 2
2. NATURE OF WORK. Unless otherwise directed by Summa Four, Contractor shall
provide the Work Product set forth in Appendix A.
3. PAYMENT OF CONTRACTOR. During the duration of this Agreement, payment of
the compensation is subject to Contractors' continuing satisfactory
performance in accordance with Section 4 below. Summa Four shall compensate
Contractor in accordance with the provisions of Appendix A.
4. RIGHT OF INSPECTION AND ACCEPTANCE. Contractor shall, at all times, perform
services to Summa Four in a responsible and independent manner so as to
meet the deliverable time frames of Appendix A. Furthermore, all Services
shall be of the highest professional quality and all Work Product to be
delivered hereunder shall conform to the specifications therefore or if no
specifications have been agreed to by the Parties, be subject to Summa
Four's complete satisfaction.
5. INDEMNIFICATION. Contractor hereby certifies that it has obtained all
necessary authorizations, permits and approvals and that it is fully
licensed and capable of performing the services as specified herein. As
such, Contractor shall defend at its own expense all actions or claims
made against Summa Four, its employees, or customers, including without
limitation, all personal injury, property damage, or Product performance
claims which may arise out of or in connection with this Agreement or
Contractor's performance of the services for Summa Four and/or delivery of
the Work Product. Furthermore, Contractor is solely responsible for and
shall indemnify Summa Four against all liability, claim, expense and/or
cost in connection with its performance under this agreement including but
not limited to the payment of all federal, state and local taxes or
contributions which may be imposed on Contractor or Summa Four including
unemployment insurance, social security and income tax levies associated
with Contractor's performance under this Agreement.
6. INDEPENDENCE OF ACTION. Nothing herein shall be deemed to restrict Summa
Four's right to perform the Work Product for itself or develop similar or
like Work Product(s) or to retain other contractors or third parties to
provide Similar Services and/or Work Product upon such terms and conditions
as it deems appropriate.
7. TERMINATION OF AGREEMENT. This Agreement may be terminated at any time, for
any reason, by Summa Four, except that in the event of any termination of
this Agreement for the convenience of Summa Four and not for cause or other
matters attributable to Contractor, Summa Four shall give 30 days prior
written notice of termination. Upon any such termination, Contractor shall
promptly deliver to Summa Four any and all Work Product (including but not
limited to any other materials, products, supplies and/or Confidential
-2-
<PAGE> 3
Information of or to be returned to Summa Four hereunder) completed as of
the date of such termination. To the extent that any payment(s) are due
therefor, such payment(s) shall be made in accordance with Articles 3, 4
and Appendix A hereof.
8. CONTRACTOR'S SERVICES FOR OTHERS. It is agreed that since Contractor,
during the term of this Agreement, and any renewals hereof, will acquire or
have access to Summa Four Confidential Information as hereinafter defined,
Contractor agrees not to provide for a period of one year after the
termination of this Agreement similar Services to other competitors of
Summa Four in the development of a high density programmable switching
system that directly competes with Summa Four's VCO product line.
9. NON-DISCLOSURE OF CONFIDENTIAL INFORMATION. The term Confidential
Information, unless otherwise indicated, shall mean all information in
tangible and/or intangible form disclosed to Contractor or learned by
Contractor as a direct or indirect consequence of or through their
relationship with Summa Four.
Accordingly, Contractor agrees to be independently bound by Summa Four's
current Non-Disclosure Agreement which it has executed in conjunction with
this Agreement.
10. REMEDIES. Summa Four reserves all right and remedies it may have in law or
equity to enforce performance of this Agreement.
11. PROPRIETARY RIGHTS IN DATA AND DOCUMENTS.
a) Unless otherwise provided for herein, the Parties hereto mutually agree
that all title to and ownership of the Work Product as well as any related
proprietary rights, including but not limited to those relating to patents,
copyrights, trademarks, or trade secrets in any Work Product provided by
Contractor to Summa Four in accordance with this Agreement shall belong
exclusively to Summa Four. Except for Article 11 b.) below, Contractor
agrees that its performance of this Agreement and the resultant Work
Product constitute a work for hire relationship. Contractor, shall protect,
on behalf of Summa Four, all materials and written documents provided to it
by Summa Four and/or which may have been independently generated by
Contractor under this Agreement. Contractor agrees that upon termination or
expiration of this Agreement for any reason whatsoever, Contractor shall
promptly deliver to Summa Four all materials and written documents, as well
as all Confidential Information, which Contractor has used, developed,
maintained or had access to throughout this Agreement.
-3-
<PAGE> 4
b) Appendix B. sets forth certain Contractor owned Algorithms (Algorithms)
which shall be modified by Contractor under this Agreement for the use by
Summa Four in conjunction with such Algorithms under a separate Product
License and Support agreement to be entered into by the Parties. Contractor
shall retain all title and ownership of such Algorithms as well as the
modifications made thereto under this Agreement. Nevertheless, Contractor
shall grant to Summa Four a perpetual, fully paid, royalty free license to
use such modifications (together with the Algorithms) in accordance with
the terms of such Product License and Support agreement.
12. Indemnification for Patent and Proprietary Right Claims.
a) Contractor warrants to Summa Four that the Work Product provided by
Contractor will not infringe upon or violate any patent, copyright, trade
secret or any other proprietary or intellectual property right of any third
party. In the event of a claim by a third party against Summa Four, or
against any of its employees or customers, asserting or involving a patent,
copyright, trade secret or proprietary or intellectual proprietary right
violation which concerns the Work Product (except for that specified in
Article 12b. below), or any related work tangible or intangible Work
Product developed by Contractor for Summa Four, Contractor will defend at
its sole expense and will indemnify and hold harmless Summa Four, its
employees and its customers against any loss, costs, expense or liability
arising out of such claim, whether or not such claim is successful.
b) Appendix B. sets forth certain Contractor owned Algorithms (Algorithms)
which shall be licensed to Summa Four under a separate Product License and
Support Agreement to be entered into by the Parties. Indemnification for
Patent and Proprietary right claims for the algorithms specified in
Appendix B is provided under the separate Product License and Support
Agreement.
13. WARRANTY. Contractor warrants that the Work Product will perform
substantially according to the specifications of Appendices A and C for 90
days after the completion of Integration as specified in Exhibit A.
14. ASSIGNMENT. Contractor may not assign its obligations or responsibilities
under this Agreement without the written consent of Summa Four.
15. AGENCY. This Agreement does not appoint the Contractor as the agent or
legal representative of Summa Four for any purpose whatsoever. The
Contractor has no authority, expressed or implied, to assume or create any
obligation or responsibility on behalf of, or in the name of Summa Four, or
to bind or represent Summa Four in any manner whatsoever. Unless
specifically provided for otherwise in this Agreement, the Contractor shall
be solely
-4-
<PAGE> 5
responsible for its actions and any and all obligations or liabilities
incurred or assumed in the performance of this Agreement.
THE CONTRACTOR ACKNOWLEDGES THAT IT HAS READ THIS AGREEMENT AND UNDERSTANDS
AND AGREES TO BE BOUND BY THIS AGREEMENT'S TERMS AND CONDITIONS. THE
CONTRACTOR FURTHER AGREES THAT THIS AGREEMENT TOGETHER WITH ITS ATTACHED
APPENDIX IS THE COMPLETE AND EXCLUSIVE STATEMENT OF THE UNDERSTANDING OF
THE PARTIES REGARDING THIS MATTER AND THAT THIS AGREEMENT SUPERSEDES AND
CANCELS ALL PREVIOUS AND CONTEMPORANEOUS WRITTEN AND ORAL AGREEMENTS AND
COMMUNICATIONS RELATING TO THE SUBJECT MATTER OF THIS AGREEMENT. THIS
AGREEMENT MAY ONLY BE MODIFIED IN WRITING, SIGNED BY AN AUTHORIZED
REPRESENTATIVE OF BOTH PARTIES.
The validity, construction and interpretation of this Agreement and the rights
and duties of the parties hereto shall be governed by and construed in
accordance with the laws of the State of New Hampshire.
IN WITNESS WHEREOF, the parties have executed this Agreement on the day and year
first above written.
================================================================================
CONTRACTOR SUMMA FOUR, INC.
- --------------------------------------------------------------------------------
AUTHORIZED SIGNATURE AUTHORIZED SIGNATURE
/s/ David Y. Wong /s/ Dick Swee
- --------------------------------------------------------------------------------
NAME (Print or Type) NAME (Print of Type)
David Wong Dick Swee
- --------------------------------------------------------------------------------
TITLE TITLE
President Vice President, Engineering
- --------------------------------------------------------------------------------
DATE DATE
4 August 1997 4 August 1997
================================================================================
-5-
<PAGE> 6
Summa Four, Inc. AGREEMENT#: __________________
APPENDIX A
TO
CONTRACT FOR PRODUCTS AND SERVICES AGREEMENT
1. OVERVIEW
The document defines the deliverables expected from D2 Technologies for the
Service Platform Card Project.
The DSP engine that will be used for all deliverables will be the Texas
instruments TMS320C548 66MlPS 1 44pQFP part. The DSP Service Resource Module
will be the same for all deliverables in this document.
R1.1. All code delivered to Summa Four regarding the requirements defined in
this document will be targeted toward the Texas Instruments TMS320C54x
family, specifically the TMS320LC548. In the event of availability
problems during development, the TMS320LC542 will be considered an
optional device for initial development efforts only. All algorithm code
will be created compatible between the two devices.
The requirements in this document supersede any contained within the
Service Platform Card Engineering Marketing Requirements Document
(SPC-EMRD) Summa Four Number 49001650100-0AR. The latter document may
only be used for reference where subject material therein is not
addressed within this document.
R1.2. The order of document priority for requirement definition is defined as
follows (in order of importance, with 1 (one) as the first source):
1. This contract
2. SPC EMRD (49001650100)
3. Further detailed design documentation on specific design
sub-sections.
2. GENERAL
R2.1. D2 will deliver VP-Open software and drivers that run on the Summa
specific hardware and card architecture.
R2.2. In the interest of maintaining compatibility with the VP-Open software
specification and interface standards, VP-Open modifications (if any)
made for
-6-
<PAGE> 7
Summa Four will not impair the hiture path of the product as other
VP-Open compatible algorithms are added to the product's capabilities.
R2.3. D2 will deliver all software for the DSP engine section of the SPC card.
This includes (as required), operating systems, diagnostic code, drivers,
algorithms, and others as is required to implement the deliverables set
forth in this document.
R2.4. Deleted.
R2.5. D2 will provide progress reports for deliverables against this contract
via email to the Project Manager ([email protected]) and the Project
Technical Lead ([email protected])
R2.6. Where D2 is required to provide documentation or schedules, those items
will be provided in hardcopy and softcopy form for Summa Four's permanent
records.
R2.7. D2 will demonstrate the ability to generate the executable, downloadable
code at Summa for each deliverable. Summa will be required to purchase
the appropriate tools and compilers to this end.
R2.8. D2 will be responsible to send personnel as required for the following:
o Debugging and Software Integration issues that cannot be reasonably
resolved over the phone.
o Demonstration and verification of each deliverable being met if on-site
presence to meet same is required.
o Instances during the algorithm verification phase where algorithm
performance or capability is in question, as measured against the
requirements in this document.
o As is required during normal development efforts between two companies to
ensure interdependencies to not become drawn out beyond the schedule
requirements.
o As is required during integration of the card software (Summa's) and the
DSP software (D2's) on the alpha and beta (first and second spin)
hardware.
R2.9. D2 will provide a dedicated technical contact for the period of this
contract.
R2.10. D2 will request the quantity of alpha and beta (first and second spin)
hardware platform that it requires for its own in-house development and
verification. Any such hardware provided by Summa Four will be considered
the property of Summa Four, and will be returned upon the completion of
this contract or upon other demand of Summa Four, Inc.
-7-
<PAGE> 8
R2.11. D2 will assist in the definition of development materials required for
both development and continued maintenance of the deliverables within
Summa Four (i.e. compilers, development platforms, etc.) which Summa Four
will purchase.
R2.12. Source code will be delivered to Summa Four for VP-Open software,
diagnostic software, and drivers.
R2.13. An escrow agreement will be executed to protect Summa Four in the event
source code is not delivered for the algorithms themselves (see
Attachment 2).
R2.14. All software deliverables to Summa Four that are centered around the SPC
card architecture, including the drivers, diagnostics, and
command/control/response interface protocol and method, will be
considered confidential and proprietary and the intellectual property of
Summa Four, Inc.
3. COMMAND/CONTROL/RESPONSE ARCHITECTURE
R3.1. The command, control, and response functions will be implemented with
the serial protocol intended to support interaction with a single host
processor (single host to multi-DSP) utilizing the capabilities of that
host processor. The host processor will be a Motorola MPCMH860-50. D2
will work with Summa to implement this protocol within the DSP.
R3.2. D2 and Summa Four will create the necessary documentation (jointly or
separately) to completely describe the intended architecture. The effort
will begin with D2 providing Summa Four with a detailed 'API' for this
interface which is based upon the configuration control and response
parameters necessary to implement the algorithms and features detailed in
Section 5, Diagnostic Requirements. Summa Four, jointly with D2, will
provide the formal definition of the interface based on internal
requirements for future product support.
R3.3. The documentation supplied in R3.3 will include definition of the
approximate MIPs required to implement the protocol of choice deftned in
the architecture chosen.
R3.4. Review and approval of all architectural documentation will be required
from D2 and Summa Four before implementation, per our ISO and Software
Development Processes.
-8-
<PAGE> 9
4. BOOT ARCHITECTURE
R4.1. The 'Boot from TDM or BSP serial port' capability of the TMS320C548 will
be used for booting diagnostic code and application (algorithm) code. D2
will be responsible for implementing all of its deliverable with this as
the sole boot mechanism. The will be no local FLASH, PROM, or other
semi-permanent memory local and accessible to the DSP device (64K of SRAM
will be available).
5. DIAGNOSTIC REQUIREMENTS
R5.1. D2 will deliver diagnostic code that performs the following functions:
o DSP Engine self-test (all DSP device verification and local device
verification i.e. SRAM, etc.).
o Checksum downloaded image test.
o Loopback all data or individual timeslots from PCM interface back to PCM
interface.
o Provide an "Echo Me Message" in the API.
o Generate a tone on a specified channel, and detect it on another channel.
o Report or verify checksum/fumware version/revision.
o Measure the period of time in between frame sync inputs (intermpts).
R5.2. The diagnostic code developed will reside in the run-time software
algorithm deliverables.
R5.3. A separate diagnostic test code module (bootable and stand-alone) will be
provided by D2 for use during engineering development for the purpose of
proving the hardware platform and basic hostDSP processor communication
and boot capability before algorithm integration occurs.
R5.4. Run-time code will be capable of implementing per-timeslot loopback Tx to
Rx within the DSP for the purpose of implementing run-time diagnostics as
required in the SPC-EMRD.
6. ALGORITHM REQUIREMENTS
R6.1. D2 will provide documentation for each algorithm deliverable which will
contain information defining:
o The ported algorithm's performance (ports per DSP resource and MIPS per
port, total MIPS of application code including performance of serial
interface protocol, etc.)
o The command/control/response interface API subset that the algorithm
supports and the rules surrounding the use of the same (if not defined
-9-
<PAGE> 10
appropriately and completely within the documentation for the
command/control/response interface).
o The algorithm's capabilities for the purpose of advertising to Summa's
customers and verification during development test.
7. DTMF RECOGNITION ALGORITHM
R7.1. The following capabilities will be designed into the algorithm:
o Configurable A or [mu]-Law operation.
o Support Bellcore LSSGR section 6 and CCIT/TIITU Q.23 and Q.24 standards.
o Enhanced Noise immunity
o Enhanced Echo immunity
R7.2. It is a requirement that the maximum available features implemented by
the algorithm be programmable by the host processor. The host processor
will be responsible for maintaining and configuring the parameters
surrounding the algorithm's requirements. The algorithm at a minimum will
support the following as configurable on a per port, per call basis via
the command/control/response interface:
o Frequency tolerance
o Level
o Twist
o Interdigit Time
o Digit Time (Tone Duration)
o Detection of Leading and Trailing Edges
o Capable of detecting sequences of digits with timeout control
o Maximum sequence size will be 40 digits
o Long tone detection, with relaxed detection parameters.
R7.3. Additionally, the algorithm will have these features:
o Elimination of tone bounce
o Supenor talk-off and talk-down performance
o A high-quality porting effort, designed to maximize the number of ports
processed per DSP resource
o A minimum of 30 ports per DSP engine, given a DSP engine capacity of 66
MIPS and sufficient SRAM resources
8. CALL PROGRESS ANALYZER ALGORITHM
R8.1. The following capabilities will be designed into this algorithm:
o Support addition of expanded algorithm parameters within the algorithm's
capabilities.
-10-
<PAGE> 11
o Support for addition of new tones and tone types without algorithm code
changes (addition implemented through programmability of algorithm
parameters).
o Configurable A or [mu]-Law operation
o Meets or exceeds Bellcore specifications
R8.2. It is a requirement that the maximum available features implemented by
the algorithm be programmable by the host processor. The host processor
will be responsible for maintaining and configuring the parameters
surrounding the algorithm's requirements. The algorithm at a minimum will
support the following as configurable on a per port, per call basis via
the command/control/response interface:
o All algorithm parameters, including but not limited to:
o Frequency
o Level
o Cadence
R8.3. The algorithm will use the cadence parameters including minimum and
maximum timing requirements to determine tone rejection or acceptance.
The algorithm shall not report a valid tone detection event if it is
outside of the minimum and maximum allowable time window specified by the
host processor.
R8.4. D2 will provide its "Call Progress Leamiprofile" capability to
characterize CPA signals.
R8.5. Additionally, the algorithm will detect the following:
o 4 unique SITs (Special information Tones) as defined per country
variation
o NU (Number Unavailable) tone
o Fax CNG (2 types) and CED as defined in CCITT T.23 specification
o Modem (6 types): Bell 103, 212, 208, V.22, V.32, V.34; transmit and
receive for each.
R8.6. The minimum countries supported by the algorithm will be the following:
Argentina Australia Belgium
Chile China Columbia
Dominican Republic Finland Germany
Holland Hong-Kong India
Indonesia Italy Japan
Korea Lebanon Malaysia
Mexico Morocco Netherlands
New Zealand Philippines Puerto Rico
Singapore South Africa Spain
Sweden Switzerland Taiwan
-11-
<PAGE> 12
Thailand United Kingdom United States
Vietnam
R8.7 D2 will deliver the tone specifications for the above countries based on
Summa Four supplied data or published ITU data. The specifications shall
be mutually agreed to by D2 and Summa Four. D2 will affirm that it has
performed laboratory testing to support all countries outlined above
based on the tone specifications agreed to by D2 and Summa Four. Summa
Four will loan a VCO-series switch to D2 for this testing.
9. MULTI-FREQUENCY RECOGNITION ALGORITHM
R9.1. The following capabilities will be designed into the algorithm:
o Compliant with Bellcore CCITT/ITU Q400, Q401, Q441, Q442, Q45l, Q455,
Q457, Q466, Q470, Q471, Q472, Q474, Q475, Q476, and Q478.
o Support all existing variants of MF recognition.
o Configurable A or [mu]-Law operation
o Compliant with Bellcore LSSGR section 6, TR-TSY-000506 Section 6.4,
TR-NWT-000506, and CCITT Q.321, Q.322, and Q.323.
o Generation of backwards MF signals.
R9.2. It is a requirement that the maximum available features implemented by
the algorithm be programmable by the host processor. The host processor
will be responsible for maintaining and configuring the parameters
surrounding the algorithms requirements. The algorithm at a minimum will
support the following as configurable on a per port, per call basis via
the command/control/response interface as published in the CCITT/ITU
specifications and as outlined in R1.7.11:
o Designation
o Frequency tolerance
o Timing (time-outs)
o Tone Pulse duration
R9.3. Additionally, the algorithm will have these features:
o Configurable "No-detect" threshold from European specifications.
R9.4. Tone generation capability will be required to implement the R2 portion
of the algorithm.
R9.5. The DSP resource will be responsible to perform the complete R2 protocol,
including tone recognition and tone generation for sequences of digits up
to a maximum of 40.
-12-
<PAGE> 13
10. DIGITAL TONE GENERATION ALGORITHM
Tone Generation includes static tones (continually repeating), such as BUSY,
RINGBACK and DIAL; as well as the Outpulse channels, which are used for
signaling (DTMF, MF, etc.).
R10.1. The SPC will support both types of Tone Generation. The algorithm shall
support the following features:
o Full DTMF support (including 4th column), based on Bellcore LSSGR Section
6, CCITT Q.23, and other national standards.
o 6 Additional tone slots
o Configurable [mu]-Law or [mu]-Law generation.
o Support for tones of modulated amplitude.
o Support for four-tone mixes.
o Support for tones of non-constant frequency.
o Support for non-cyclic tones (ex: BONG, Call waiting, DIAL for Call
Forwarding).
o Support for tones with adjustable timings.
R10.2. At a minimum, the following will be configurable on a per-port, per call
basis via the command/contro1/response interface:
o Frequencies (up to 4)
o Level
o Twist
o Interdigit time
o Digit time (tone duration)
o The maximum outpulse sequence length will be 40 digits
o Modulation
o Frequency sweep
11. TESTING/TECHNOLOGY TRANSFER
R11.1. A test plan with expected and actual results for each of the algorithms
will be provided by D2. The test plan will be reviewed for approval by
Summa.
R11.2. D2 will provide a 2 day "Technology Transfer" at Summa Four. This will
include training, a codeldesign walk-through, and a hands-on session for
building and executing the code.
12. SCHEDULE/PAYMENT MILESTONES
A milestone is complete when the deliverable, along with associated
documentation, is delivered to and accepted by Summa Four.
-13-
<PAGE> 14
================================================================================
DELIVERABLE TARGET DATE PAYMENT
- ----------- ----------- -------
- --------------------------------------------------------------------------------
Progress reports Weekly
- --------------------------------------------------------------------------------
HDLC Low-level Code (Bit stuff/CRC) 7/21/97 21,034
- --------------------------------------------------------------------------------
Algorithm API documentation 7/21/97 12,000
Algorithm Capabilities documentation
Algorithm Performance Measurements (C54x)
- --------------------------------------------------------------------------------
HDLC link layer sw complete 7/21/97 18,800
- --------------------------------------------------------------------------------
Software External Design Spec draft 7/21/97 20,000
- --------------------------------------------------------------------------------
Software Internal Design Spec 8/14/97 6,000
- --------------------------------------------------------------------------------
Algorithm modifications complete 8/15/97 7,500
- --------------------------------------------------------------------------------
Nucleus software dev start 7/21/97 15,000
- --------------------------------------------------------------------------------
Nucleus sw dev complete 9/12/97 12,000
- --------------------------------------------------------------------------------
Diag software spec 7/14/97 2,000
- --------------------------------------------------------------------------------
Diag software complete 8/15/97 4,000
- --------------------------------------------------------------------------------
Test plan draft 8/22/97 3,000
- --------------------------------------------------------------------------------
Test plan complete (with results) 9/12/97 5,000
- --------------------------------------------------------------------------------
Pre-Integration Complete 9/15/97 8,000
- --------------------------------------------------------------------------------
Integration complete 11/10/97 19,000
- --------------------------------------------------------------------------------
Technology transfer start 11/14/97 2,000
- --------------------------------------------------------------------------------
Reimbursable expenses (travel, per diem etc.) as expended 8,000
- --------------------------------------------------------------------------------
TOTAL 169,334
================================================================================
Compensation to Contractor for the completion and delivery of Work Product and
Services (including integration services) shall be due on the acceptance of same
in accordance with the Deliverable Schedule above. The fixed compensation shall
be $169,334. Such compensation fee may be changed in the event of a material
change in the breadth and/or scope of the Software Design Specification
presently agreed upon by the parties and attached as Appendix C. Any such change
in the Specification or the fees shall be subject to the mutual agreement of the
parties. Contractor integration support shall include up to 2 one week trips to
Summa Four headquarters in New Hampshire by one Contractor engineer and shall
include services to support at least 2 major revisions of hardware (a major
revision defined as one which requires revisions in the DSP software).
13. SUMMA FOUR SUPPLIED EQUIPMENT AND SUPPORT
Summa Four agrees to consign VCO and SPC/SRM hardware to DR as agreed by the
parties to enable D2 to perform software testing and integration efforts on a
timely basis. Such Equipment shall be consigned in accordance with Summa Four's
standard consignment agreement. Summa Four shall also make available qualified
engineering support at mutually agreeable times to assist D2 in its development,
-14-
<PAGE> 15
integration and testing responsibilities under this agreement if either party
fails to meet the performance schedule, the parties shall convene to establish a
mutually agreed upon remedial plan to ensure timely completion of the contract.
Such remedial plan may include adjustments to the contract in terms of
compensation, payment schedules, credits etc, as appropriate.
-15-
<PAGE> 16
Summa Four, Inc. AGREEMENT #:______
APPENDIX B
TO
CONTRACT FOR PRODUCTS AND SERVICES AGREEMENT
D2 OWNED TECHNOLOGY SPECIFICATION
DTMF Detection and Removal Algorithm 5007-A
Universal Tone Detection Algorithm 50030-A
Multifrequency Tone Detection Algorithm 50028-A
Tone Generation Algorithm 50015-A
Voice Activity Detection and AGC 50013-B
-16-
<PAGE> 17
EXHIBIT C
EVP-SRM (DSP) Software Design
Specification
-1-
<PAGE> 18
EVP-SRM (DSP) Software Design Specification 2
- -----------------------------------------------------------------------
Table of Contents
<TABLE>
<CAPTION>
Page
----
<S> <C>
1. Introduction...............................................................................1
1.1 Open Issues...........................................................................1
1.2 Change History........................................................................1
1.3 Purpose of Document...................................................................1
1.4 Intended Audience.....................................................................1
1.5 Related Documents.....................................................................1
1.6 Glossary and Abbreviations............................................................2
2. DSP Hardware Requirements..................................................................3
2.1 Overview..............................................................................3
2.2 The TMS320LC548 Processor.............................................................3
2.3 Two Buffered Serial Ports.............................................................3
2.4 Interprocessor Communications.........................................................3
2.4.1 Loading DSP Programs.........................................................4
2.4.2 Starting Communications......................................................5
2.4.3 Steady State Communications..................................................5
2.5 Emulator support......................................................................5
3. DSP Software Functions and Architecture....................................................5
3.1 DSP Functions.........................................................................5
3.2 DSP Software Architecture.............................................................6
3.3 Command and Status Module.............................................................6
3.4 Major States..........................................................................7
3.4.1 DTMF DETECT..................................................................7
3.4.2 MF DETECT....................................................................8
3.4.3 CP DETECT....................................................................9
3.4.4 TONEGEN......................................................................9
3.4.5 MFcR2.......................................................................10
3.4.6 IDLE........................................................................10
3.5 Multi-port Management................................................................10
4. Signal Processing Algorithm Specification.................................................10
4.1 HDLC Communications..................................................................11
4.2 Voice Activity Detection.............................................................11
4.2.1 Functional requirements:....................................................11
4.2.2 Performance Requirements:...................................................12
4.3 DTMF Detection.......................................................................13
</TABLE>
-2-
<PAGE> 19
EVP-SRM (DSP) Software Design Specification 3
- -----------------------------------------------------------------------
<TABLE>
<S> <C>
4.3.1 Functional requirements:....................................................13
4.3.2 Performance requirements:...................................................14
4.4 Tone Generation......................................................................16
4.4.1 Functional requirements:....................................................16
4.4.2 Performance Requirements....................................................18
4.5 Universal Tone Detector..............................................................18
4.5.1 Overview....................................................................18
4.5.2 General.....................................................................18
4.5.3 General Functional Requirements.............................................19
4.5.3.1 Tone Detector Performance Requirements...........................20
4.5.3.1.1 Single Tones.......................................20
4.5.3.1.2 Dual Tones.........................................21
4.5.3.1.3 Amplitude Modulated Tones..........................22
4.5.3.1.4 Precedence.........................................23
4.5.3.1.5 North American Call Progress Signal Detection......23
4.5.3.1.6 FAX CNG Tone Detection.............................24
4.5.3.1.7 Modem Tone Specification...........................25
4.5.3.1.8 Three Tone Sequences...............................27
4.5.3.1.9 Unknown Tone.......................................28
4.6 Multifrequency Tone Detection (MFD)..................................................28
4.6.1 Functional requirements:....................................................29
4.6.2 Rl Detection Performance requirements:......................................30
4.6.3 R2 Detection Performance Requirements.......................................31
4.7 MFcR2 compelled signalling...........................................................33
5. Configuration Parameters..................................................................33
5.1 Global Parameters....................................................................33
5.2 DTMF Detection Parameters............................................................34
5.2.1 DTMF Collection Specifications..............................................34
5.2.2 DTMF Detection Parameter Memory Usage.......................................37
5.3 MF Detection Parameters..............................................................38
5.3.1 MF Collection Specifications................................................38
5.3.2 MF Detection Parameter Memory Usage.........................................41
5.4 Call Progress Detection Parameters...................................................41
5.4.1 CP Tone Groups..............................................................41
5.4.2 CP Tone Specifications......................................................44
5.4.3 CP Collection Specifications................................................47
5.4.4 CP Detection Channel Context................................................47
5.4.5 CP Detection Parameter Memory Usage.........................................48
5.5 Tone Generation Parameters............................................................48
5.5.1 Simple Tone Specifications.....................................................49
5.5.1.1 Special Tone Specifications...........................................51
</TABLE>
-3-
<PAGE> 20
EVP-SRM (DSP) Software Design Specification 4
- ------------------------------------------------------------------------
<TABLE>
<S> <C>
5.5.2 Special Case Tone Templates.................................................52
5.5.3 User-defined Tone Groups.......................................................53
5.5.3.1 User-defined Tone Groups for DTMF. MF
generation .................................................................54
5.5.4 Tone Generation Parameter Memory Usage......................................54
5.6 MFcR2 Signalling Parameters..........................................................55
5.6.1 MF Collection Specifications................................................56
5.6.2 MFcR2 State Transition Tables...............................................57
5.6.3 Actions.....................................................................58
5.6.4 Processes...................................................................58
5.6.5 MFcR2 Signalling Parameter Memory Usage.......................................60
6. DSP Time and Space Requirements...........................................................61
7. Command Messages..........................................................................62
7.1 Command String Format................................................................62
7.2 Command Message Definitions..........................................................63
7.2.1 IDLE (0x0) Commands............................................................63
7.2.2 DIAGNOSTIC TEST (0x1) Commands.................................................64
7.2.2.1 DIAGNOSTIC TEST - Version (0x10) Command............................66
7.2.2.2 DIAGNOSTIC TEST - TDM Loopback (0x11)
Command..........................................................66
7.2.2.3 DIAGNOSTIC TEST - HDLC Echo (0x12)
Command..........................................................67
7.2.2.4 DIAGNOSTIC TEST - Measure Performance (0x13)
Command..........................................................67
7.2.2.3 DIAGNOSTIC TEST - HDLC Echo (0x12)
Command..........................................................67
7.2.3 DTMF Detection (0x2) Commands...............................................68
7.2.3.1 DTMF/COLLECTION SPECIFICATION
DOWNLOAD (0x20)..................................................68
7.2.3.1 DTMF/SETUP (0x21)................................................70
7.2.3.3 DTMF/EXECUTE (0x22)..............................................71
7.2.4 MF Detection (0x3) Commands.................................................72
7.2.4.1 MF/COLLECTION SPECIFICATION DOWNLOAD
(0x30)...........................................................73
7.2.4.2 MF/SETUP (0x31)..................................................74
7.2.4.3 MF/EXECUTE (0x33)................................................75
7.2.5 CP Detection (0x4) Commands....................................................76
7.2.5.1 CP Detection/SETUP (0x40)...........................................76
7.2.5.2 CP Detection/EXECUTE (0x41).........................................77
7.2.5.3 CP Detect/COLLECTION SPEC DOWNLOAD (0x42)...........................78
</TABLE>
-4-
<PAGE> 21
EVP-SRM (DSP) Software Design Specification 5
- ------------------------------------------------------------------------
<TABLE>
<S> <C>
7.2.5.4 CP Detection NORMAL CP TONE SPEC DOWNLOAD
(0x43)...........................................................79
7.2.5.5 CP Detection SIT CP TONE SPEC DOWNLOAD
(0x44)...........................................................79
7.2.5.6 CP Detection TONE GROUP DOWNLOAD (0x45).............................80
7.2.6 Tone Generation (0x5) Commands..............................................80
7.2.6.1 Tone Generation TRANSMIT TONE (0x50)................................81
7.2.6.2 Tone Generation OUTPULSE DIGITS (0x51)..............................81
7.2.6.3 Tone Generation STOP EXECUTION (0x52)...............................82
7.2.6.4 Tone Generation DOWNLOAD SIMPLE TONE
SPEC (0x53)......................................................82
7.2.6.6 Tone Generation DOWNLOAD SPECIAL TONE
SPEC (0x52)......................................................84
7.2.6.7 TONE GENERATION DOWNLOAD USER-DEFINED
TONE GROUP (0X56)................................................84
7.2.7 MFcR2 Signalling (0x6) Commands................................................85
7.2.7.1 MFcR2/COLLECTION SPECIFICATION DOWNLOAD
(0x60)...........................................................85
7.2.7.2 MFcR2/SETUP (0x61)..................................................86
7.2.7.3 MFcR2/EXECUTE (0x63)................................................88
7.2.7.3.1 MFcR2/EXECUTE - Start Forward
Signalling.........................................89
7.2.7.3.2 MFcR2/EXECUTE - Start Backward
Signalling.........................................90
7.2.7.3.3 MFcR2/EXECUTE - Stop MfcR2
Signalling.........................................90
7.2.7.3.4 MFcR2/EXECUTE - Reset MfcR2
Signalling.........................................91
8. Status Messages...........................................................................92
8.1 Status String Format.................................................................92
8.2 Status Message Definitions...........................................................93
8.2.1 IDLE (0x0) Status..............................................................93
8.2.2 DIAGNOSTIC TEST Status.........................................................94
8.2.3 DTMP Detection (0x2) Status Messages........................................94
8.2.3.1 DTMF/DIGIT REPORT (without times) (0x20)............................95
8.2.3.2 DTMF/DIGIT REPORT (with times) (0x21)...............................96
8.2.3.3 DTMF/DIGIT ERROR (0x22).............................................96
8.2.4 MF Detection (0x3) Status Messages..........................................97
8.2.4.1 MF/DIGIT REPORT (without times) (0x30)..............................97
8.2.4.2 MF/DIGIT REPORT (with times) (0x31).................................98
8.2.4.3 MF/DIGIT ERROR (0x32)...............................................99
</TABLE>
-5-
<PAGE> 22
EVP-SRM (DSP) Software Design Specification 6
- ------------------------------------------------------------------------
<TABLE>
<S> <C>
8.2.5 CP Detection (0x4) Status Messages...........................................99
8.2.5.1 CP Detect/TONE DETECTED (0x40)......................................100
8.2.5.3 CP Detect/EVENT (0x41)..............................................100
8.2.5.3 CP Detect/ERROR (0x42)..............................................101
8.2.6 Tone Generation (0x5) Status Messages.......................................102
8.2.6.1 Tone Generation/OUTPULSE COMPLETE (0x50)...........................102
8.2.6.2 Tone Generation/ERROR (0x51).......................................102
8.2.7 MFcR2 Signalling (0x6) Status Messages......................................103
8.2.7.1 MFcR2/DIGIT REPORT (0x60)...........................................103
8.2.7.2 MFcR2/Error (0x32)..................................................105
</TABLE>
-6-
<PAGE> 23
EVP-SRM (DSP) Software Design Specification 1
- ------------------------------------------------------------------------
1. Introduction
1.1 Open Issues
1. Format of MFcR2 commands/status/parameters needs to be expanded to handle
compelled signalling.
2. References and glossary need to be completed.
1.2 Change History
1.3 Purpose of Document
This document is the contract between the Digital Signal Processor (DSP, Service
Engine) software developers, the system software developers, and the hardware
developers as to what the DSP software does and how it interacts with the
hardware and firmware on the Service Resource Module (SRM) and the Service
Platform Card (SPC). This document details the architecture, functions,
performance, and interface of all DSP functions that run on the DSP.
1.4 Intended Audience
This document is intended for system engineers, hardware engineers, and system
software (firmware) engineers developing the SRM.
1.5 Related Documents
This document references the following D2 internal documents:
1. VP Open Software Interface Specification, D2 Technologies, Document
Number 70001, February 1995.
2. VP Open System Component User's Guide, D2 Technologies, Document Number
70002, February 1995.
3. SRM Internal Software Design Specification, D2 Technologies, Document
Number [TBD], July 1997.
4. HDLC Module: Detailed Software Design Specification, D2 Technologies,
Document Number [TBD], June 199?.
This document references the following external documents:
-1-
<PAGE> 24
EVP-SRM (DSP) Software Design Specification 2
- ------------------------------------------------------------------------
1.
1.6 Glossary and Abbreviations
ANS V.25 Modem Answering Signal
Bellcore Bell Communications Research
CS4x Abbreviation for Texas Instruments' family of fixed point
digital signal processors based on the TM5320C54 core.
CNG FAX Calling Tone
CP Call Progress
CPE Customer Premise Equipment
DSP Digital Signal Processor or Digital Signal Processing
DTMF Dual Tone Multi frequency
PCM Pulse Code Modulation
RMS Root Mean Square
SIT Special Information Tone
SNR Signal to Noise Ratio
TDM Time Division Multiplex
-2-
<PAGE> 25
EVP-SRM (DSP) Software Design Specification 3
- ------------------------------------------------------------------------
2. DSP HARDWARE REQUIREMENTS
2.1 Overview
The hardware required for the Service Engine consists of four key components:
1. TMS320LC548PGE-66 processor.
2. Two Buffered Serial Ports
3. One Time Division Multiplexed Interface Serial Port
4. Program and data RAM.
The following sections shall outline the requirements for various subsystems
outlined above.
2.2 The TMS320LC548 Processor
The SRM design requires:
1. A TMS320LC548PGE running at 66 MIPS. Additional ports per DSP can
be supported if a DSP at a faster speed is used.
2. 64k x 16 of zero wait-state SRAM mapped into both program space
(starting at program address 0x0000) and data space (also starting
at data address 0x0000).
3. On-chip serial port interface to the TDM highway used for boot
loading.
2.3 Two Buffered Serial Ports
The C548 processor has two buffered serial ports, which will be used to route
voice data and HDLC messaging to the DSP from the Core Processor.
In the initial software, only one buffered serial port will be used. Where
appropriate, however, command and status messages, as well as parameters, will
be formatted to allow for usage of both buffered serial ports.
2.4 Interprocessor Communications
The DSP shall be loaded by the Core Processor using the DSP serial boot mode.
-3-
<PAGE> 26
EVP-SRM (DSP) Software Design Specification 4
- ------------------------------------------------------------------------
Communications between the DSP and the Core Processor is accomplished by
using the first 8-bit PCM timeslot on the first buffered serial port of
each DSP. The DSP and the Core Processor communicate using point-to-point
HDLC protocol over this timeslot.
2.4.1 Loading DSP Programs
A two-stage boot load will be used to load DSP programs. Since the core
processor is booting several DSPs with the same image, however, there
shall be no signalling from the DSP to the Core Processor during boot.
This is achieved as follows:
o The runtime DSP image shall consist of a boot loader, then several (TBD)
zeros, then the actual runtime image.
o The Core Processor shall utilize the standard method of booting the DSP
through the TDM port with this image.
o The DSP, upon downloading the boot loader section, will begin executing
the boot loader section.
o The boot loader section will reconfigure the memory map, interrupts, and
interrupt vectors. Then, the boot loader will monitor the TDM port for
the end of the zeros section. This zero section is present simply to
allow for a delay between the end of the boot section and the beginning
of the runtime image section. Its length will be determined by the
maximum delay needed for the boot loader section to execute.
o When the actual runtime image begins to be sent over the TDM port, the
boot loader will copy the image to the correct locations.
o When the image is completely downloaded, the boot loader branches to
start executing the runtime image.
This method of dual-stage booting is advantageous because the Core Processor can
send the same image to all DSPs that use a particular image, and no two-way
communication is needed until after the boot. It also allows for booting code
into sections of memory not addressable during the ROM boot.
-4-
<PAGE> 27
EVP-SRM (DSP) Software Design Specification 5
- ------------------------------------------------------------------------
2.4.2 Starting Communications
When the DSP executes the runtime image, the following steps are taken in order:
1. The DSP initializes control bits.
2. The DSP initializes (and preprocesses, if necessary) all parameters.
3. The DSP signals to the Core Processor that it is ready to accept
commands.
2.4.3 Steady State Communications
All steady state communications is done using the HDLC protocol over the first
timeslot on the first buffered serial port.
2.5 Emulator support
It is often necessary to use an emulator (Texas Instruments' XDS510) to debug
the DSP during integration. To provide access for XD5510, there shall be a 14
pin JTAG connector as described in Appendix B of the TMS32054x DSP CPU and
Peripherals Reference Set, Volume 1.
3. DSP Software Functions and Architecture
3.1 DSP Functions
The following signal processing functions shall be ported to the SPC.
1. Detection of DTMF signals.
2. Detection of MFRl, MFR2 Forwards, and MFR2 Backwards signals.
3. Detection of call progress (CP) tones and voice activity. CP tones
consist of the standard call progress plan tones, in addition to Special
Information Tones (SITs) and FAX Modem tones.
4. Generation of DTMF, MFR1, MFR2, call progress, and other tones.
5. Execution of compelled signalling protocols for MFcR2 signalling. This
will allow for compelled signalling using any combination of Rl, R2
Forwards, and R2 Backwards tones for generation and detection.
-5-
<PAGE> 28
EVP-SRM (DSP) Software Design Specification 6
- ------------------------------------------------------------------------
3.2 DSP Software Architecture
All DSP software conforms to the VP Open software architecture. All DSP
modules work on 64 sample blocks of data (8 ms). in each 8 ms interval, the DSP
performs the following functions:
1. Reads data from the buffered serial ports. This includes timeslot data as
well as commands from the Core Processor.
2. Interprets the Core Processor commands into calls to selected DSP
functions.
3. Sends data to the buffered serial ports. This includes voice data as well
as status to the Core Processor.
The scheduling of these functions is handled by the Command and Status Module
(CSM) according to the VP Open specification. Detailed description of the code
is presented in the following sections, in addition to [3].
3.3 Command and Status Module
In addition to communication with external devices and controlling the data flow
within the DSP, the CSM manages which modules are executed on the data. For each
command from the Core Processor, the CSM defines a state consisting of a
sequence of modules that are run.
The CSM is designed to handle multiple ports in different states. The state
machine and the states are designed so that any state transition is allowed.
HOWEVER, DUE TO MEMORY AND MIPS CONSTRAINTS, THERE WILL BE SEVERAL VERSIONS OF
THE RUN TIME CODE, EACH OF WHICH SUPPORTS A SUBSET OF THE STATES. EACH DSP WOULD
THUS BE DEDICATED TO A SUBSET OF THE TOTAL FUNCTIONALITY.
THE THREE SUBSETS OF FUNCTIONALITY WILL BE:
1. DTMF, MFR1, MFR2 FORWARDS, AND MFR2 BACKWARDS DETECTION
2. MFCR2 SIGNALLING AND TONE GENERATION
3. CALL PROGRESS DETECTION
-6-
<PAGE> 29
EVP-SRM (DSP) Software Design Specification 7
- ------------------------------------------------------------------------
3.4 Major States
3.4.1 DTMF DETECT
The DTMF DETECT state is used by the Core Processor to collect DTMF digits. In
this state, the DTMF detector detects DTMF digits. Reporting of DTMF digits to
the Core Processor happens when the requisite number of digits has been
collected, or when a time-out has occurred.
[Flow Chart depicting DTMF Detect state]
Figure 3-1: DTMF DETECT state]
-7-
<PAGE> 30
EVP-SRM (DSP) Software Design Specification 8
- ------------------------------------------------------------------------
3.4.2 MF DETECT
The MF DETECT state is used by the Core Processor to collect Multifrequency R1,
R2 Forwards, and R2 Backwards digits. Note, however, this is not the state that
does compelled signalling. In this state, the MFD detector only DETECTS MF
digits. Reporting of detected digits to the Core Processor happens when the
requisite number of digits has been collected, or when a time-out has occurred.
[Flow Chart depicting the MF Detect state]
Figure 3-2: MF DETECT State
-8-
<PAGE> 31
EVP-SRM (DSP) Software Design Specification 9
- ------------------------------------------------------------------------
3.4.3 CP DETECT
The CP DETECT state is used by the Core Processor to detect call progress, modem
ANS, CNG, SIT, and other call progress-like tones. In this state, the UTD
detector detects call progress tones and reports detection of the tones to the
Core Processor.
[Flow Chart depicting CP Detect state]
Figure 3-3: CP DETECT State
3.4.4 TONEGEN
The TONEGEN state is used by the Core Processor to generate tones or series of
tones. In this state, the GENF module is used to generate the tones.
[Flow Chart depicting Tonegen state]
Figure 3-4: TONEGEN State
-9-
<PAGE> 32
EVP-SRM (DSP) Software Design Specification 10
- ------------------------------------------------------------------------
3.4.5 MFcR2
The MFcR2 state is used by the Core Processor to do R2 compelled signalling. In
this state, the MFD detector detects MF digits, and the GENF tone generator
generates MF digits.
[Flow Chart depicting MFcR2 state]
Figure 3-5: MFcR2 State
3.4.6 IDLE
This state is used when a timeslot is not assigned to a voice port, or when
there are no signals to be processed. In the IDLE state, there is no processing
of Line In or Line Out.
3.5 Multi-port Management
Since all DSP modules are VP Open compatible, the DSP can easily support as many
simultaneous phone ports as memory and processor load allow. For each port,
memory is allocated for each module. This memory is referred to as the module's
object. The module uses the object to maintain its internal state from call to
call.
To run multiple ports, the CSM checks to see if there are any state transitions.
If there are, the objects for that port are reinitialized as required. Next, the
CSM runs all modules for each port with the appropriate data and module objects.
The CSM schedules ports on a round robin basis with all ports completing
processing on one block of data within the 8 ms block processing time. Finally,
the CSM outputs the status and data for all ports and restarts the process by
looking for new commands.
4. Signal Processing Algorithm Specification
This section lists the functional and performance requirement of the major DSP
algorithms included in the DSP software.
-10-
<PAGE> 33
EVP-SRM (DSP) Software Design Specification 11
- ------------------------------------------------------------------------
4.1 HDLC Communications
All command, status, and configuration signalling between the Core Processor and
the DSP will be sent over the first time slot on the first Buffered Serial Port,
utilizing point-to-point HDLC communications.
This algorithm is presented in detail in [4].
4.2 Voice Activity Detection
Voice Activity Detection (VAD) detects voice activity, adapts to background
ambient or line noise as well as the presence of echo, classifies voice activity
as "early" versus "sustained", and assigns an "effort level" to the speaker that
is independent of network loss.
This module is used to detect voice activity in the cP DeteCt state.
4.2.1 Functional requirements:
The Voice Activity Detector discriminates voice activity generated by a caller
from background noise (acoustic and line noise) as well as echo and sidetones
reflected back to the receive voice path. It also provides an "effort level"
quantity that indicates the level of effort of the caller. The functional and
performance requirements are specified to cover a wide range of applications,
such as voice activated recordings (as in voice messaging), outbound call
classification, digital speech interpolation (DSI), and voice conferencing.
1. The Voice Activity Detector classifies every block of voice data (8 ms
long) as "port active" (early detect), "speaker active" (port sustained),
and "not active".
2. It provides a measurement that approximates the level of effort exerted
by the caller. Such an approximation is made by normalizing the short
term RMS of the voice signal by a longer term RMS value. The "effort
level" varies between -32 dB and 31 dB, and is at 0 dB when the speaker
is speaking at his/her "normal" level.
3. The Voice Activity Detector adapts to background noise up to -24 dBm.
Adaptation is 200 ms when the noise level drops, and is approximately
1000 ms when noise rises.
4. The Voice Activity Detector screens out sidetone or echo as speech up to
an ERL of -26dB.
-11-
<PAGE> 34
EVP-SRM (DSP) Software Design Specification 12
- ------------------------------------------------------------------------
4.2.2 Performance Requirements:
The accuracy of the voice Activity detector is measured by the rate of "false
detection" (i.e. classifying noise or echo as voice activity) and "clipping"
(i.e. classifying voice activity as noise or echo) under different ambient noise
and echo conditions.
"Port active" detection under different ambient noise conditions:
1. No perceptible clipping at quiet to modest noise levels of -50 dBm to -40
dBm with nominal levels of speech activity (-20 dBm average power over 2
seconds of speech). No more than 5% of voice onsets is clipped for noisy
conditions (noise level from -40 dBm to -30 dBm).
2. No more than 1% of "silence" periods is detected as speech for the modest
noise condition. No more than 2% of "silence" is detected as port active
for noisy conditions.
3. The performance goals above is met when noise levels change during the
test.
"Speaker active" detection under different ambient noise conditions:
1. Speech activity that lasts more than tSUSTAIN is detected as "Sustained"
or "Speaker Active".
2. The clipping requirements is better than "Port Activity" detection. Fewer
than 0.50/0 of onsets/hour (2.5 per hour) for modest noise condition (-45
dBm) and fewer than 2 % (10 per hour) for high noise condition (-35 dBm)
have perceptible clipping.
3. False detection performance (i.e., detecting noise as "speaker active")
exceeds those of "port activity" due to tSUSTAIN criteria. No more than
1% (36 seconds per hour) of noise segments is misclassified as
"sustained" for modest noise conditions, and no more than 2% (72 seconds
per hour) of "silence" is detected as port active for noisy conditions.
"Port active" and "Speaker active" detection in the presence of echo:
1. Less than 1% of residual echo is detected as "port active" - (i.e. 36
sec. per hour) during normal operation of canceller.
-12-
<PAGE> 35
EVP-SRM (DSP) Software Design Specification 13
- ------------------------------------------------------------------------
2. Less than 0.1 % (i.e. 3.6 sec per hour) of residual echo is detected as
"speaker active" or "port sustained" during normal operation of
canceller.
3. Clipping of input speech in the presence of echo is no higher than
clipping in the presence of modest to high level of noise.
4.3 DTMF Detection
4.3.1 Functional requirements:
specifies the nominal frequencies for the DTMF digits that must be detected.
<TABLE>
- --------------------------------------------------------------------------------
<CAPTION>
Nominal High Group Frequencies (Hz)
1209 1336 1477 1633
- --------------------------------------------------------------------------------
<S> <C> <C> <C> <C> <C>
Nominal 697 1 2 3 A
Low Group 770 4 5 6 B
Frequencies 852 7 8 9 C
(Hz) 941 * 0 # D
- --------------------------------------------------------------------------------
</TABLE>
Table 4-1: Nominal DTMF Frequencies
1. Detect the presence of all 16 DTMF digits that are produced by different
phones on the market under a broad range of network conditions.
2. DTMF digit information is provided as soon as the minimum duration is
met. This information is called leading edge detection. This allows the
earliest possible response to the digit, such as stopping voice output.
3. The trailing edge of a DTMF digit must be detected. This allows the
system to delay any response (such as playing out voice) to the digit
until the user has released the DTMF key. The criteria selected for
trailing edge detection will debounce DTMF digits.
4. The DSP reports leading and trailing edge in the 8 ms block that they are
detected. DTMF events are not buffered.
-13-
<PAGE> 36
EVP-SRM (DSP) Software Design Specification 14
- ------------------------------------------------------------------------
4.3.2 Performance requirements:
Table 4-2 consists of performance requirements taken from EIA-464A and Bellcore
TR-TSY-000181. Also shown is D2's DTMF performance requirements, which is a
superset of the EIA and Bellcore requirements.
<TABLE>
- ---------------------------------------------------------------------------------------------
- ---------------------------------------------------------------------------------------------
<CAPTION>
Characteristic Bellcore EIA/TIA-464A D2
- ---------------------------------------------------------------------------------------------
<S> <C> <C> <C>
Frequency +/-1.5% must accept; +/-1.5% must accept; Configurable choice of
Deviation +/-3.5% must reject +/-3.5% must reject Four sets of must
accept/must reject:
+/-2.0% accept to +/-3.0%
reject
+/-2.5% accept to +/-3.5%
reject;
+/-3.0% accept to +/-4.0%
reject;
+/-3.5% accept to +/-4.5%
reject
- ---------------------------------------------------------------------------------------------
Minimum 40 ms must accept; 40 ms must accept Configurable from 24 to
Tone 23 ms must reject 80 ms
Duration
- ---------------------------------------------------------------------------------------------
Minimum 40 ms 40 ms Configurable from 24 to
Interdigital 80 ms
Interval
- ---------------------------------------------------------------------------------------------
Minimum 93 ms 93 ms Configurable from 48 to
Cycle Time 160
- ---------------------------------------------------------------------------------------------
Accept Levels 0 to -36 dBm must 0 to -25 dBm must 0 dBm to configurable
accept; -55 dBm accept minimum (-25 to -45
must reject dBm range)
- ---------------------------------------------------------------------------------------------
Twist (ratio of -8 to +4 dB -8 to +4 dB Separately configurable
high group positive and negative
power to low) twists:
+/-4, 6, 8, 10, and 12 dB
- ---------------------------------------------------------------------------------------------
</TABLE>
-14-
<PAGE> 37
EVP-SRM (DSP) Software Design Specification 15
- ------------------------------------------------------------------------
<TABLE>
- ---------------------------------------------------------------------------------------------
<S> <C> <C> <C>
Bellcore Fewer than 670 - Fewer than 20 talkoffs
talkoff tape total talkoffs; fewer (with default
than 330 talkoffs of configuration of 2.5% to
digits 0-9; fewer 3.5% frequency
than 170 talkoffs of deviation; 40 msec min
signals* and #. tone duration; +/-8 dB
twist; -45 dBm min
accept level)
- ---------------------------------------------------------------------------------------------
Mitel talkoff - - 0 talkoffs (with default
tape configuration)
- ---------------------------------------------------------------------------------------------
SNR 23 dB 15 dB 15 dB
- ---------------------------------------------------------------------------------------------
Impulse Noise Fewer than 14 Fewer than 10 Pass both Bellcore and
missed or split errors in 10,000 EIA/TIA-464A impulse
digits in Bellcore tones for EIA test noise requirements
Impulse Noise Tape #1; fewer than 500
No. 201 errors in 10,000
tones for test #2
- ---------------------------------------------------------------------------------------------
Echo 16 dB Signal-to- 10 dB Signal-to- Pass both Bellcore and
Echo ratio at 20 Echo ratio at 20 EIA/TIA-464A echo
ms; ms requirements
24 dB at 45 ms
- ---------------------------------------------------------------------------------------------
Dial Tone DTMF Detection in DTMF Detection Pass both Bellcore and
the presence of in the presence of EIA/TIA-464A
dial tone at -15 dial tone at -16 requirements for
dBm per dial tone dBm per dial tone detection of DTMF
frequency frequency digits in the presence of
dial tone
- ---------------------------------------------------------------------------------------------
</TABLE>
Table 4-2: DTMF Performance Requirements
Other performance requirements:
1. A leading edge of DTMF digit is signaled during the block in which the
minimum duration is met, and the trailing edge is signaled during the
block in which the minimum debounce interval is met.
2. Talk-down: DTMF detection must work reliably in the presence of echo (for
the maximum allowable output voice level) and with varying levels of DTMF
-15-
<PAGE> 38
EVP-SRM (DSP) Software Design Specification 16
- ------------------------------------------------------------------------
signals (due to network loss). D2's DTMF detector combined with the echo
must meet the performance requirements of Figure 4-1 in the presence echo
generated by playing pause-removed voice (male and female) at -18 dBm ASL
(averaged over 3 seconds) over a telephone circuit with 15 dB echo return
loss (ERL).
[Graph depicting DTMF Talk-down Acceptance Curve]
Figure 4-1: DTMF Talk-down Acceptance Curve
3. Debounce test: Long tones (generated by "hard" key presses) must not be
detected as multiple tones in the presence of echo interference or line
noise. Combined with the echo canceller, the DTMF detector is required to
reliably "debounce" all DTMF digits above -18 dBm in the presence of
voice levels below -15 dBm (ASL) and a telephone circuit with echo return
loss (ERL) of 15 dB.
4. Double-talk talk-off: Many voice processing hardware or semiconductor
manufacturers signficantly degrade the "talk-off" performance of their
detector in the presence of voice echo or sidetone to achieve a high
level of talk-down performance. This strategy is acceptable in a pure
digit-in-voice-out scenario, but for voice conferencing or voice
recognition applications, voice could be present in the both the transmit
and receive path. In such cases, the DTMF detector must be very robust
against "talk-off" in double-talk situations. The talk-off requirements
for D2's DTMF detector under double- talk is fewer than 66 talkoffs for
the Bellcore talk-off tape.
4.4 Tone Generation
The tone generation module can be programmed to generate any single, dual or
amplitude modulated tone required to meet international telecommunications
specifications. This functionality is provided by the GENF module, which
produces the sum or product of two independently generated sine waves as its
output. Each sine wave can be individually parameterized.
4.4.1 Functional requirements:
The GENF module is designed to generate a wide range of DTMF, Call Progress
Signals, MF R1/R2, and miscellaneous tones. In order to meet or exceed
-16-
<PAGE> 39
EVP-SRM (DSP) Software Design Specification 17
- ------------------------------------------------------------------------
international telecommunication specifications, GENF must meet or exceed the
following functional requirements.
1. Independent arguments shall be supplied for each frequency for dual tones
that GENF generates. Single tones are generated by specifying that one of the
dual tone's frequencies is 0 Hz.
2. Independent arguments shall be supplied for the carrier and modulation
frequencies for amplitude modulated tones that GENF generates.
3. Arguments shall be supplied that allow the frequency of a tone to be set
in the range of 0 to 4000 Hz in 1 Hz units. 4. Arguments shall be supplied that
allow the output power to be set in the range of +3 to -50 dBm in 0.5 dB steps.
5. Arguments shall be supplied that allow an amplitude modulated tone's
modulation percentage to be set in the range of 0 to 300% in 1% units.
6. The tone duration (make time) shall be specified in 1 ms units. Tone
durations shall be specified in the range of 0 to 8191 ms.
7. An unlimited tone duration shall be specified by setting the make
duration to -1.
8. The silence duration between tones (break time) shall be specified in 1
ms units. Silence durations shall be specified in the range of 0 to 8191 ms.
9. An unlimited silence duration shall be specified by setting the make
duration to -l and setting both frequencies of a dual tone to 0 Hz.
10. The GENF module shall allow tones to be generated that meet or exceed
EIA/TIA-464 requirement for DTMF and call progress tone generation.
11. The GENF module shall allow tones to be generated that meet or exceed
CCITT Blue Book Volume VI Fascicle VI.4 recommendations Q.3l0-Q.490 requirements
for MF R1 and R2 tone generation.
12. The GENF module shall generate tones with one to three unique caence
pairs (on/off pairs).
-17-
<PAGE> 40
EVP-SRM (DSP) Software Design Specification 18
- ------------------------------------------------------------------------
4.4.2 Performance Requirements
1. Frequency accuracy shall exceed 1 Hz.
2. Level accuracy shall exceed 0.5 dB.
3. Timing information shall exceed 1 ms accuracy.
4.5 Universal Tone Detector
4.5.1 Overview
The Universal Tone Detector (UTD) is a high configurable tone detector. By
changing parameters, this algorithm can classify a wide range of single and dual
tone call progress signals generated in a wide variety of countries.
4.5.2 General
Since different tones need different detection heuristics, and tones may have
multiple specifications, each tone is tagged with a tone category identifier.
------------------------------------------------
Tone Category Call Process Signal
------------------------------------------------
1 Modem
2 FAX CNG
3 Audible Ringback
4 Busy
5 Reorder or Congestion
6 Number Unobtainable
7 SIT
8 Dial tone
9 Unknown Tone
------------------------------------------------
Table 4-3: Tone Categories
In addition to specifying a tone category, the parameters include a value that
is returned to the application when the tone is detected. This parameter need
not be unique. This allows multiple specifications to report the same tone event
to the application.
UTD is table driven. Using this approach, the tone detector searches parameter
tables for a matching tone. When a tone matches, the tone code determines the
-18-
<PAGE> 41
EVP-SRM (DSP) Software Design Specification 19
- ------------------------------------------------------------------------
heuristics necessary to completely classify the tone. Also, the tones must be
specified in a way that a set of parameters corresponds to either a single tone,
a dual tone, or an amplitude modulated tone.
--------------------------
Code Tone Type
--------------------------
0 Single Tone
1 Dual Tone
2 Modulated Tone
--------------------------
Table 4-4: Call Progress Tone Types
4.5.3 General Functional Requirements
UTD functionally combines a single tone detector and a dual/modulated tone
detector into a single module. UTD combines the results of these detectors into
a single result.
UTD has the following requirements.
1. The DSP shall indicate that the first ringback has started after at least
400 ms of ringback like signal has been processed, as long as no other
tone type is early detected. If more than one type of tone is early
detected, the first ringback reporting shall be delayed until either
cadence information disqualifies the other types, or tone precedence is
used as a 'tie-breaker'.
2. The DSP shall indicate ringback has stopped when ringback is no longer
detected.
3. The DSP shall indicate a busy tone has been detected after the requisite
number of make and break intervals have been processed, and no other tone
category is still a candidate for detection.
4. The DSP shall indicate a reorder tone has been detected after the
requisite number of make and break intervals have been processed, and no
other tone category is still a candidate for detection.
5. The DSP shall indicate a number unobtainable tone has been detected after
the requisite number of make and break intervals have been processed, and
no other tone category is still a candidate for detection.
-19-
<PAGE> 42
EVP-SRM (DSP) Software Design Specification 20
- ------------------------------------------------------------------------
6. In the event that more than one tone is a candidate for detection,
detection is delayed until all characteristics that may disqualify any of
the candidates are tested (for example, waiting for multiple cadence
pairs to occur). If there is still more than one potential tone after all
differentiating features have been exhausted, then the tone with the
highest precedence is detected. Also, if the tone ceases prior to
singling out one candidate tone, then the tone with the highest
precedence is detected. Precedence is shown in Table 4-6.
7. The DSP shall supply an early detect flag. This flag shall be valid after
the detector has processed no more than 72 ms of a tone. If more than one
tone category is early detected, then the early detect flag shall
indicate the tone category with the highest precedence.
8. The DSP shall indicate that a modem has been detected if a single tone
falls within the specified frequencies for modem tones, the minimum make
interval has been exceeded while the average tone power is in excess of
the minimum power requirement, and no other tone category is still a
candidate for detection.
9. The DSP shall indicate that a FAX CNG tone has been detected if a single
tone falls within the specified frequencies for a CNG tone, the requisite
number of on/off cadences have been processed, and no other tone category
is still a candidate for detection.
10. The DSP shall indicate that a SIT tone has been detected if at least two
of the three segments of possible SIT tones have been detected for at
least the minimum interval in excess of the minimum power requirement.
11. The DSP shall indicate that an Unknown tone has been detected when it has
been determined that a tone has been detected that falls within the
specified frequencies for an Unknown tone, the minimum duration has been
exceeded, and the tone does not match and other category tones.
4.5.3.1 Tone Detector Performance Requirements
4.5.3.1.1 Single Tones
There are four types of parameters that shall be used to control single tone
detection. The variation of each parameter shall be limited by the constraints
listed in Table 4-5.
-20-
<PAGE> 43
EVP-SRM (DSP) Software Design Specification 21
- ------------------------------------------------------------------------
-------------------------------
Minimum Maximum
----------------------------------------------------
Frequency 300 Hz 3300 Hz
----------------------------------------------------
Bandwidth 0 Hz 1800 Hz
----------------------------------------------------
Duration 100 msec 32760 msec
----------------------------------------------------
Minimum -45 dBm 3 dBm
Power Level
----------------------------------------------------
Table 4-5: Single Tone Detection Constraints
The frequency detection range shall be specified the Frequency and Bandwidth
parameters. Figure 4-2 shows the relationship of these parameters. Note that the
bandwidth specification is symmetric about the center frequency.
The Frequency and Bandwidth parameters define a "must detect" range. The
detector shall not use frequency criteria to reject any tones which are within
the range specified Frequency/Bandwidth parameters. Tones whose frequencies are
outside but close to frequency range may be detected.
[Graph depicting frequency domain for a Single Tone]
Figure 4-2: Frequency Domain Representation of tone parameters for a Single Tone
If the Power Level of the detected parameter is greater than the minimum power
specified by the parameters, the signal shall not be rejected by Power Level
heuristics.
Duration parameters are used to set the allowable duration of a tone. Minimum
and maximum tone durations may be specified (make durations). Also, minimum and
maximum silence durations between tones may be specified.
4.5.3.1.2 Dual Tones
Dual tones are created by summing two sinusoids. Since each tone can be isolated
in the frequency domain, dual tones are specified as a pair of single tones.
Parameters for each tone of a dual pair use the same constraints as single
tones. Namely, frequency 1 is the center frequency of the lower tone, and
bandwidth1
-21-
<PAGE> 44
EVP-SRM (DSP) Software Design Specification 22
- ------------------------------------------------------------------------
specifies its frequency tolerance. The same is true for frequency2 and
bandwidth2 for the high tone. Figure 4-3 shows the definition of the frequency
and bandwidth parameters for a dual tone.
[Graph depicting frequency domain for a Dual Tone]
Figure 4-3: Frequency Domain Representation of Tone Parameters for a Dual Tone
Not all dual tones are detectable by UTD. A dual tone shall detected only when
the difference between the two component frequencies is greater than 10 Hz and
less than 230 Hz.
4.5.3.1.3 Amplitude Modulated Tones
Amplitude modulated tones are created by multiplying two sinusoids. When
analyzed in the frequency domain, a modulated tone looks like three tones.
Figure 4- 4 shows the frequency spectrum for a modulated tone.
The tone whose frequency is the average of the other tones is the carrier. The
other two tones can be referred to as side lobes. For amplitude modulated tones,
frequency1 and bandwidth1 specify the low sidelobe and its tolerance, while
frequency2 and bandwidth2 specify the high sidelobe and its tolerance.
[Graph depicting frequency domain for a Modulated Tone]
Figure 4-4: Frequency Domain Representation of Tone Parameters for an Amplitude
Modulated Tone
As with dual tones, not all modulated tones will be detected by UTD. Modulated
tones shall be detected if the difference between the carrier frequency and the
sidelobes is between 10 Hz and 230 Hz.
-22-
<PAGE> 45
EVP-SRM (DSP) Software Design Specification 23
- ------------------------------------------------------------------------
4.5.3.1.4 Precedence
By assigning a detection precedence to the classification process, tone
frequency ranges can overlap. When a tone's parameters fall into a range shared
by two or more signals. The signal is classified as the one with the highest
precedence.
------------------------------------
Precedence Call Progress Signal
------------------------------------
1 Modem
2 FAX CNG
3 Audible Ringback
4 Busy
5 Reorder or Congestion
6 Number
7 Unobtainable
8 SIT
Dial Tone
------------------------------------
Table 4-6: Tone Detection Precedence
Table 4-6 shows the precedence of typical tones that the UTD module detects.
Modem signals have the highest precedence, and Unknown tones have the lowest.
Therefore, the frequency range of unknown tones can safely overlap the other
tone ranges without causing tomes to be misclassified. If the range for Unknown
tones is allowed to be the maximum range allowed by the detector, any detected
tone that is unclassified would be designated as Unknown.
4.5.3.1.5 North American Call Progress Signal Detection
Function Requirements:
The tables below specify the frequencies, power levels, and cadence of the
Bellcore and EIA-464A call progress tones.
- --------------------------------------------------------------------------------
Frequency (Hz) Power Level (dBm)
- --------------------------------------------------------------------------------
Name 350 440 480 620 Per Frequency Combined
- --------------------------------------------------------------------------------
Audible Ring X X -22.5+/-1.5
- --------------------------------------------------------------------------------
Busy X X -27+/-1.5
- --------------------------------------------------------------------------------
Dial Tone X X -17.5 to -15 -13 to -14.5
- --------------------------------------------------------------------------------
Intercept X X -20+/-1.5
- --------------------------------------------------------------------------------
Reorder X X -27+/-1.5
- --------------------------------------------------------------------------------
Table 4-7: Call Progress Tone Frequency and Power Requirements
-23-
<PAGE> 46
EVP-SRM (DSP) Software Design Specification 24
- ------------------------------------------------------------------------
- --------------------------------------------------------------------------------
Audible ring repetition of the tone on for 0.8 to 2.2 seconds, and off
for 2.7 to 4.4 seconds
(ring-back)
- --------------------------------------------------------------------------------
Busy repetition of the tone on for 0.5+/-0.05 seconds, and off for
0.5+/-0.05 seconds
- --------------------------------------------------------------------------------
Dial steady uninterrupted
- --------------------------------------------------------------------------------
Intercept repetition of an alternating sequence of the two frequencies
each being on for 0.16 to 0.30 seconds with a total cycle time
of 0.5+/-0.05 seconds
- --------------------------------------------------------------------------------
Reorder repetition of the tone on for 0.25+/-0.025 seconds, and off for
0.25+/-0.025 seconds
(fast busy)
- --------------------------------------------------------------------------------
Table 4-8: Call Progress Tone Cadence
Performance Requirements
1. Frequency Deviation: Even though the generator is required to meet a
frequency tolerance per tone of +/-0.5%, the detector needs to allow for
a wider frequency tolerance due to variations in generators and line
distortions. The CP detector detects all tones whose component
frequencies deviate less than 1% from nominal.
2. Twist: The CP detector detects all tones whose twist is less than +/-4
dB.
3. Dynamic Range: The CP detector exhibits a minimum dynamic range of 25 dB.
4. Cadence: The CP detector must detect call progress tones whose cadence is
within +/-10%.
5. Talkoff: The CP detector makes no false detections in 12 hours of testing
with voice at -15 to -18 dBm ASL.
4.5.3.1.6 FAX CNG Tone Detection
The standard connection protocol for automatic connection of a FAX modem
requires that the calling FAX modem generate a calling tone (CNG). Hence for
incoming calls, the EVP software has to detect a CNG signal. When CNG is
detected, EVP alerts the Core Processor to redirect the call to a FAX machine or
a FAX modem embedded within the call processing system.
-24-
<PAGE> 47
EVP-SRM (DSP) Software Design Specification 25
- ------------------------------------------------------------------------
Functional Requirements:
Detect the presence of the FAX calling tone (CNG). A CNG signal is defined as
follows:
[Graph depicting fax calling tone]
Figure 4-5: Fax calling tone (CNG)
a) The CNG tone is within 38 Hz of nominal frequency.
b) The timing tolerance of a CNG tone is +/-15%.
c) The power of a CNG tone is between 0 and -43 dBm.
Performance Requirements:
1. The detector does not miss any CNG signals on a prerecorded tape
containing 50 CNG tone samples collected from 5 different FAX machines.
2. The detector does not miss any CNG signals from the same FAX machines
connected to a local CO with a noise level of less than -45 dBm.
3. The detector misses less than 0.5% of CNG signals (generated at -10 dBm)
when compressed voice is output at a level of -15 dBm or less (average
over 3 seconds) into a network whose ERL is greater than 15 dB.
4. The detector does not falsely detect more than 1 CNG tone per 5 hours of
voice (based on Bellcore recorded talk radio voice tapes.)
4.5.3.1.7 Modem Tone Specification
All answering modems that conform to the ITU V.25 answering sequence present a
2100 Hz tone 1.8 to 2.5 seconds after answering the telephone line. Figure 4-6
and Figure 4-7 show the timing of the answering tone (ANS). In Figure 4-6, the
2100 Hz tone reverses phase every t intervals. These phase reversals disconnect
echo cancelers and echo suppressors from the network. According to ITU G.164,
phase reversal shall be accomplished such that the phase is within 180+/-10
degrees in 1 ms
-25-
<PAGE> 48
EVP-SRM (DSP) Software Design Specification 26
- ------------------------------------------------------------------------
and that the amplitude of the 2100 Hz tone is not more than 3 dB below its
steady state value for more than 400 usec.
[Graph depicting tuning for answering Modem with Phase reversal]
Figure 4-6: Timing for Answering Modem with Phase Reversal
[Graph depicting timing for answering Modem without Phase reversal]
A timing diagram for an answering modem without phase reversal is shown in
Figure 4-7. The timing is identical with that of phase reversing tone except for
the reversal timing.
Figure 4-7: Timing for Answering Modem without Phase Reversal
Table 4-9 contains the nominal frequency, power, and duration requirements for
-------------------------------------------
Minimum Maximum Unit
-------------------------------------------------------------------
Frequency 2085 2115 Hz
-------------------------------------------------------------------
Duration 2.6 4.0 seconds
-------------------------------------------------------------------
Power -18.0 -6.0 dBm0
-------------------------------------------------------------------
generating modem tones as derived from V.25 and G.164.
Table 4-9: Modem Tone Generation Requirements
-26-
<PAGE> 49
EVP-SRM (DSP) Software Design Specification 27
- ------------------------------------------------------------------------
Performance Requirements:
1. The detector does not miss any modem answer tone on a pre-recorded tape
containing 50 modem answer tone samples collected from 5 different data
modems.
2. The detector does not miss any modem answer tone signals from the same
data modem connected via a local CO with a noise level of less than -45
dBm.
3. The detector does not miss more than 0.5% of modem answer tones
(generated at -10 dBm) when compressed voice is played at a level of - 15
dBm (ASL) or lower into a network connection with ERL greater than 15 dB.
4. The detector does not falsely detect the presence of a modem answer tone
more than once per 5 hours of voice (using Bellcore recorded talk radio
voice tapes).
5. There is no talkdown performance requirement. The near end is always
silent and does not interfere with far end modem ANS signals.
6. There shall be fewer than 1 talkoff in 5 hours of call classification
when the detector is programmed with the recommended parameters. Assuming
that each call is resolved within an average time of 10 seconds, there
shall be less than 1 talkoff in 1800 calls.
4.5.3.1.8 Three Tone Sequences
Most countries that generate Special Information Tones (SIT) use a three tone
sequence. SIT sequences are generated by various central offices or common
carrier switching points to indicate a problem with the dialed call. A SIT tone
sequence generally precedes a recorded voice announcement such as "the number
you have dialed is no longer in service..." and is provided specifically for the
purpose of detection of the problem type by an automated device.
There are two popular types of SIT sequences. The first type is used mainly it
Europe. It consists of a sequence of three tones of identical durations. The
second type is the one used in North America. There are several North American
SIT sequences that are encoded using various combinations of frequency and
duration for each of the three tones. The encoding has been standardized by
Bellcore.
-27-
<PAGE> 50
EVP-SRM (DSP) Software Design Specification 28
- ------------------------------------------------------------------------
Performance Requirements:
1. The UTD shall handle both types of sequences.
2. There is no talkdown performance requirement. The near end is always
silent and does not interfere with far end SIT signals.
3. There shall be fewer than 1 talkoff in 5 hours of voice when the detector
is programmed with the recommended parameters. Assuming that each voice
call is has an average of 2 seconds of voice, there shall be fewer than 1
talkoff in 9000 calls.
4.5.3.1.9 Unknown Tone
Any single tone, dual tone, amplitude modulated tone or single tone sequence
that is not classified as a CP, SIT, CNG or modem ANS tone, shall be reported as
an unknown tone.
Performance Requirements:
1. Talkdown performance requirement [TBD]
2. There shall be fewer than 1 talkoff in 5 hours of voice when the detector
is programmed with the recommended parameters (minimum tone duration 400
ms). Assuming that each voice call is has an average of 2 seconds of
voice, there shall be fewer than 1 talkoff in 9000 calls.
4.6 Multifrequency Tone Detection (MFD)
The MFD algorithm module detects the presence of R1, R2 Forward, and R2 Backward
Multifrequency (MF) tones under a broad range of network conditions and under
international telecommunications specifications.
-28-
<PAGE> 51
EVP-SRM (DSP) Software Design Specification 29
- ------------------------------------------------------------------------
4.6.1 Functional requirements:
Table 4-10, Table 4-11, and Table 4-12 specify the nominal frequencies for the
MF digits that must be detected.
-----------------------------------------------------------------------
F1(Hz) F2 (Hz)
900 1100 1300 1500 1700
----------------------------------------------------------
700 1 2 4 7 Spare
900 - 3 5 8 Spare
1100 - - 6 9 KP
1300 - - - 0 Spare
1500 - - - - ST
-----------------------------------------------------------------------
Table 4-10: Nominal MF R1 Frequencies and corresponding digit definitions
-----------------------------------------------------------------------
F1(Hz) F2 (Hz)
1500 1620 1740 1860 1980
----------------------------------------------------------
1380 1 2 4 7 11
1500 - 3 5 8 12
1620 - - 6 9 13
1740 - - - 10 14
1860 - - - - 15
-----------------------------------------------------------------------
Table 4-11: Nominal MF R2 Forward Frequencies and corresponding
combination numbers
-29-
<PAGE> 52
EVP-SRM (DSP) Software Design Specification 30
- ------------------------------------------------------------------------
-----------------------------------------------------------------------
F1(Hz) F2 (Hz)
1020 900 780 660 540
----------------------------------------------------------
1140 1 2 4 7 11
1020 - 3 5 8 12
900 - - 6 9 13
780 - - - 10 14
660 - - - - 15
-----------------------------------------------------------------------
Table 4-12: Nominal MF R2 Backward Frequencies and corresponding
combination numbers
1. Be configurable to detect either R1, R2 forward, or R2 backward MF digits
on a per-call basis.
2. Detect the presence of all 15 R1, 15 R2 Forward, and 15 R2 Backward
digits under a broad range of network conditions.
3. MF digit information is provided as soon as the minimum duration is met.
This information is called leading edge detection. This allows the
earliest possible response to the digit, such as in compelling
signalling.
4. The trailing edge of a MF digit must be detected. This allows the system
to delay any response (such as in compelled signalling) to the digit
until it is removed. The criteria selected for trailing edge detection
will debounce MF digits.
5. The DSP reports leading and trailing edge in the 8 ms block that they are
detected. MF events are not buffered.
4.6.2 Rl Detection Performance requirements:
Table 4-13 consists of MF Rl tone detection performance requirements taken from
CCITTJITU Q310-Q331 and Bellcore TR-NWT-000506. Also shown is D2's MF R1
performance requirements, which is a superset of the CCITT and Bellcore
requirements.
-30-
<PAGE> 53
EVP-SRM (DSP) Software Design Specification 31
- ------------------------------------------------------------------------
<TABLE>
<CAPTION>
- -------------------------------------------------------------------------------------------------------------------------------
Requirement
- -------------------------------------------------------------------------------------------------------------------------------
CHARACTERISTIC BELLCORE CCITT/ITU D2
- -------------------------------------------------------------------------------------------------------------------------------
<S> <C> <C> <C>
Frequency Deviation +/-(1.5%+ 5 Hz) must accept +/-1.5% must accept Configurable choice of three
sets of must accept
frequency tolerance:
+/-(1.5% + 5 Hz),
+/-(1.5% + 10 Hz),
+/-(1.5% + 15 Hz)
- -------------------------------------------------------------------------------------------------------------------------------
Tone Duration KP signal: >54 ms must <30 ms must accept Minimum duration is
accept; <30 ms must reject configurable in 4 ms steps,
<10 ms must reject from 28 ms up. Can be
-
All others: > 30 ms must configured for >30 ms must
accept; < 10 ms must reject accepts, < 10 ms must reject
- -------------------------------------------------------------------------------------------------------------------------------
Minimum Interdigital Must accept interdigital Must accept interdigital Minimum interdigital
Interval intervals > 25 ms. intervals > 20 ms interval is configurable in 4
- - ms steps. Can be configured
for > 20 ms accept; < 10 ms bridge
Must bridge interdigital - -
intervals < 10 ms
- -------------------------------------------------------------------------------------------------------------------------------
Minimum Cycle Time Up to 10 pulses per second - > 10 pulses per second
(100 ms cycle time) (< 100 ms cycle time)
- -------------------------------------------------------------------------------------------------------------------------------
Accept Levels 0 to -25 dBm must accept - Minimum power is
configurable from -25 dBm
< -35 dBm must reject to -45 dBm per frequency
-
- -------------------------------------------------------------------------------------------------------------------------------
Twist (ratio of high group < 6 dB twist must accept < 6 dB twist must accept < 6 dB twist must accept
power to low) - - -
- -------------------------------------------------------------------------------------------------------------------------------
SNR (white noise) 20 dB - 20 dB
- -------------------------------------------------------------------------------------------------------------------------------
Impulse Noise Fewer than 14 missed or - Fewer than 14 missed or
split digits in Bellcore Impulse split digits in Bellcore Impulse
Noise Tape No. 201 Noise Tape No. 201
- -------------------------------------------------------------------------------------------------------------------------------
Disturbing Frequencies Detection in the presence of - Detection in the presence of
2A-B and @b-A modulation 2A-B and @b-A modulation
products 28 dB below each products 28 dB below each
frequency component level frequency component level
of the signals. of the signals.
- -------------------------------------------------------------------------------------------------------------------------------
</TABLE>
Table 4-13: MFD R1 Detection Performance Requirements
4.6.3 R2 Detection Performance Requirements
Table 4-14 shows the MF R2 tone detection performance requirements taken from
CCITT/ITU Q400-490. The MFD module is required to pass all CCITT/ITU
requirements.
-31-
<PAGE> 54
EVP-SRM (DSP) Software Design Specification 32
- ------------------------------------------------------------------------
<TABLE>
- ------------------------------------------------------------------------------------------------------------------------------
CHARACTERISTICS CCITT/ITU REQUIREMENT CCITT/ITU REQUIREMENT
- ------------------------------------------------------------------------------------------------------------------------------
<S> <C> <C>
Frequency Deviation +/-10 Hz must accept Configurable choice of three sets of
must accept frequency tolerance:
+/-10 Hz,
+/-15 Hz,
+/-20 Hz
- ------------------------------------------------------------------------------------------------------------------------------
Tone Duration Must reject signals < 7 ms Must reject signals < 7 ms
- -
- ------------------------------------------------------------------------------------------------------------------------------
Minimum response time for R2 detect delay + generate delay < 70 ms detect delay + generate delay < 70 ms
compelled signalling - -
detect delay + decision delay + detect delay + decision delay +
generate delay < 80 ms generate delay < 80 ms
- -
- ------------------------------------------------------------------------------------------------------------------------------
Accept Levels -5 dBm0 to -31.5 dBm0 must detect; Minimum power is configurable from -
25 dBm to -45 dBm per frequency
-38.5 dBm0 must reject
- ------------------------------------------------------------------------------------------------------------------------------
Twist (ratio of high group power to < 5 dB twist must accept for adjacent < 5 dB twist must accept for adjacent
low) - -
frequencies; frequencies;
< 7 dB twist must accept for non- < 7 dB twist must accept for non-
- -
adjacent frequencies adjacent frequencies;
20 dB twist must reject 20 dB twist must reject
- ------------------------------------------------------------------------------------------------------------------------------
Disturbing Frequencies Must not falsely detect due to any one Must not falsely detect due to any one
or more valid R2 frequencies at -55 or more valid R2 frequencies at -55
dBm per frequency. dBm per frequency.
In the presence of a valid R2 tone, no In the presence of a valid R2 tone, no
missed detections and no false missed detections and no false
detections due to any of the remaining detections due to any of the remaining
frequencies at 20 dB below the highest frequencies at 20 dB below the highest
of the MF tone pair. of the MF tone pair.
Must not falsely detect due to: Must not falsely detect due to:
1. Any 1 or 2 pure sine waves, 1. Any 1 or 2 pure sine waves,
each at -38.5 dBm0, 300-3400 each at -38.5 dBm0, 300-3400
Hz. Hz.
2. Any 1 or 2 pure sine waves, 2. Any 1 or 2 pure sine waves,
each at -42 dBm, 300-3400 each at -42 dBm 300-3400
Hz. Hz.
3. Forward detector: Any 2 3. Forward detector: Any 2
pure sine waves, each at -5 pure sine waves, each at -5
dBm, 330-1150 Hz or 2130- dBm, 330-1150 Hz or 2130-
3400 Hz. 3400 Hz.
4. Backward detector: Any 2 4. Backward detector: Any 2
pure sine waves, each at -5 pure sine waves, each at -5
dBm, 1300-3400 Hz. dBm, 1300-3400 Hz.
- ------------------------------------------------------------------------------------------------------------------------------
Transmitted signal interference Must not falsely detect due to Must not falsely detect due to
generation of outgoing MF digits. generation of outgoing MF digits.
- ------------------------------------------------------------------------------------------------------------------------------
</TABLE>
-32-
<PAGE> 55
EVP-SRM (DSP) Software Design Specification 33
- ------------------------------------------------------------------------
Table 4-14: MFD R2 Detection Performance Requirement
4.7 MFcR2 compelled signalling
In order to pass the CCITT requirements for compelled signal timing, the
following additional requirements are made ON the MFD detector:
1. The MFD detector shall detect the leading edge of an R2 digit after
processing no more than 24 ms of the digit.
2. The MFD detector shall detect the trailing edge of an R2 digit after
processing no more than 16 ms of the silence following the digit.
5. CONFIGURATION PARAMETERS
The DSP uses various configuration parameters controlled by the Core Processor.
These configuration parameters specify frequencies, powers, durations, and
thresholds used for detection and generation of tones and voice data. This
section defines the various parameters and their format in DSP memory.
5.1 Global Parameters
Global Parameters are those that must be defined for the DSP as a whole. Table
5-1 lists the global parameters and their descriptions.
- --------------------------------------------------------------------------------
NAME Description
- --------------------------------------------------------------------------------
p0DBINA digital rms of a 0 dBm sine wave incident at A/D
for A-Law PCM
- --------------------------------------------------------------------------------
p0DBOUTA digital rms of a 0 dBm sine wave incident at D/A
for A-Law PCM
- --------------------------------------------------------------------------------
p0DBINM digital rms of a 0 dBm sine wave incident at A/D
for [mu]-Law PCM
- --------------------------------------------------------------------------------
p0DBOUTM digital rms of a 0 dBm sine wave incident at D/A
for [mu]-Law PCM
- --------------------------------------------------------------------------------
[tau]HANGOVER Maximum inactivity before speech flag resets
- --------------------------------------------------------------------------------
[tau]SUSTAIN Minimum duration of speech before sustained
- --------------------------------------------------------------------------------
Table 5-1: global parameters
-33-
<PAGE> 56
EVP-SRM (DSP) Software Design Specification 34
- ------------------------------------------------------------------------
Legal parameter values:
1. p0DBINA is a 14-bit code that represents the 0 dBm power level of a 1 kHz
sine wave at the network interface for A-Law channels.
2. p0DBOUTA is a 14-bit code that represents DSP power level required to
generate a 0 dBm signal at the network interface for A-Law channels.
3. p0DBINM is a 14-bit code that represents the o dBm power level of a 1 kHz
sine wave at the network interface for [mu]-Law channels.
4. p0DBOUTM is a 14-bit code that represents DSP power level required to
generate a 0 dBm signal at the network interface for [mu]-Law channels.
5. tHANGOVER is a parameter that sets the maximum time, [tau]HANG-OVER, that
the speech sustained flag may be asserted while voice activity is absent.
The maximum time is given by the following formula: [tau]HANGOVER*8msec.
6. tSUSTAIN is a parameter that sets the minimum duration, [tau]SUSTAIN,
that a voice activity must be present before it is considered sustained
speech. The duration is given by the following formula: tSUSTAIN=
[tau]SUSTAIN*8msec.
5.2 DTMF Detection Parameters
DTMF detection is configured on a per-channel basis using a set of DTMF
Collection Specifications. Each Collection Specification contains all
configurable parameters for DTMF detection. There are 35 default Collection
Specifications, and are referenced by ID, numbered 1 to 35 (Collection ID #0 is
reserved to mean "use the previous default collection specification"). There
also is one 'working' Collection Specification per timeslot.
The DSP maintains the following context for each channel:
o ID of it's current default DTMF Collection Specification
o It's working' DTMF Collection Specification, which is the one used for
detection
5.2.1 DTMF Collection Specifications
DTMF Collection Specifications contain the following fields:
-34-
<PAGE> 57
EVP-SRM (DSP) Software Design Specification 35
- ------------------------------------------------------------------------
1. k: The number of digits to collect before initial report: 1 to 16
2. N: The total number of digits to collect: 1 to 40
3. MIN_POWER: The minimum allowable power per frequency (a value of 0 = - 25
dBm; a value of 21 = -45 dBm)
4. MIN_MAKE: The minimum duration of a valid DTMF digit, in ms (0 to 255).
5. MIN_BREAK: The minimum interdigital silence duration, in ms (9 to 255).
6. IDTO: Inter-digit Timeout. A timeout will be reported if the silence
between two DTMF digits exceeds IDTO seconds. Range is 0 seconds
(disables) to 255 seconds.
7. PSC: Permanent Signal Condition. A timeout will be reported if the
duration of a DTMF digit exceeds PSC. Range is 0 seconds (disables) to
255 seconds.
8. FDTO: First Digit Timeout. A timeout will be reported if the time to
collect the first digit exceeds FDTO. Range is 0 seconds (disables) to
255 seconds.
9. TDTO: Total Digit Timeout. A timeout will be reported if the time to
collect all digits exceeds TDTO. Range is 0 seconds (disables) to 255
seconds.
10. ED: End Digit. Detection of this DTMF digit ends DTMF collection (if the
ED bit in the Control Word is set).
11. CD: Cancel Digit. Detection of this DTMF digit causes the DSP to delete
all collected digits and restart DTMF detection (if the CD bit in the
Control Word is set).
12. POS_TWIST: Maximum allowable ratio of high tone power to low tone power.
Choices are 0 (2 dB), 1(4dB), 2(6 dB), 3 (8 dB), 4 (10 dB), and 5 (12 dB)
13 NEG-TWIST: Maximum allowable ratio of low tone power to high tone power.
Choices are 0 (2 dB), 1 (4 dB), 2 (6 dB), 3 (8 dB), 4 (10 dB), and 5 (12
dB)
-35-
<PAGE> 58
EVP-SRM (DSP) Software Design Specification 36
- ------------------------------------------------------------------------
14. CW: Control Word - a 8-bit mask with the following format:
----------------------------------------------------------
7 6 5 4 3 2 1 0
----------------------------------------------------------
DE P UE UC RD IN FT
----------------------------------------------------------
Table 5-2: Control Word Bit Definitions
o bit 1,0: FT = frequency tolerance:
00 = 2.0% must accept / 3.0% must reject
01 = 2.5% must accept / 3.5% must reject
10 = 3.0% must accept / 4.0% must reject
11 = 3.5% must accept / 4.5% must reject
o bit 2:IN = initial notification. If this bit is set, the DSP will make
the initial report when k digits are collected.
o bit 3:RD = report durations. If this bit is set, the DSP will report on
and off durations for each digit detected. Durations will have a
granularity of 8 ms.
o bit 4:UC = use cancel code. If this bit is set, the DSP will reset DTMF
collection when the cancel code is detected.
o bit 5:UE = use end code. If this bit is set, the DSP will end DTMF
collection when the end code is detected.
o Bit 6:P = PCM type: This is how the Core Processor configures the PCM
type for this channel.
1 = ALaw
0 = [mu]Law
o bit 7: DE = detection edge:
1 = leading edge detection
0 = trailing edge detection
The size in bits and the range of each field in the Collection Specifications is
shown in Table 5-3. Table 5-4 shows the format of each channel's DTMF parameter
context. The 'Default CS ID' field contains the ID for one channel's default
collection spec. Words 2-7 of Table 5-4 contain the channel's working Collection
Specification, and are the exact format of the default Collection Specifications
(which are each 6 words long).
-36-
<PAGE> 59
EVP-SRM (DSP) Software Design Specification 37
- ------------------------------------------------------------------------
- --------------------------------------------------------------------------------
Field Units unsigned Size (bits) Range
- --------------------------------------------------------------------------------
k number of digits unsigned 4 1 to 16
N number of digits unsigned 6 1 to 40
MIN_POWER (-25 -#) dBm unsigned 5 0 to 20
MIN_MAKE ms unsigned 8 0 to 255
MIN_BREAK ms unsigned 8 0 to 255
IDTO s unsigned 8 0 to 255
PSC s unsigned 8 0 to 255
FDTO s unsigned 8 0 to 255
TDTO s unsigned 8 0 to 255
ED DTMF digit unsigned 4 0 to 15
CD DTMF digit unsigned 4 0 to 15
POS TWIST 2*(# + 2) dB unsigned 4 0 to 4
NEG_TWIST 2*(# + 2)dB unsigned 4 0 to 4
CW 8-bit mask bit mask 8 0 to 255
- --------------------------------------------------------------------------------
87 bits
6 words
---------------------------
Table 5-3:DTMF Collection Specification Parameter Units
<TABLE>
===========================================================================================================
<CAPTION>
High Byte Low Byte
===========================================================================================================
Word 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
========= -----------------------------------------------------------------------------------------------------------
<S> <C> <C>
1 | | Default CS ID
-----------------------------------------------------------------------------------------------------------
2 | k | | N
-----------------------------------------------------------------------------------------------------------
3 | MIN_POWER | MIN_MAKE
-----------------------------------------------------------------------------------------------------------
4 MIN_BREAK | CW
-----------------------------------------------------------------------------------------------------------
5 IDTO | PSC
-----------------------------------------------------------------------------------------------------------
6 FDTO | TDTO
-----------------------------------------------------------------------------------------------------------
7 POS_TWIST | NEG_TWIST | ED | CD
- ----------------------------------------------------------------------------------------------------------------------
</TABLE>
Table 5-4: Internal DTMF parameter channel context
5.2.2 DTMF Detection Parameter Memory Usage
For N channels of DTMF, the total memory usage for DTMF channel context and
Collection Specifications is N*7+35*6+ = 210+7N 16-bit words. For all 63
channels, this is 651 words. For 30 channels, this is 420 words.
-37-
<PAGE> 60
EVP-SRM (DSP) Software Design Specification 38
- ------------------------------------------------------------------------
5.3 MF Detection Parameters
MF detection is configured on a per-channel basis using a set of MF Collection
Specifications. These Collection Specifications each contain all configurable
parameters for MF detection. There are 35 default Collection Specifications, and
are referenced by ID, numbered 1 to 35. there also is one 'working' Collection
Specification per timeslot.
The DSP maintains the following context for each channel:
o ID of it's current default MF Collection Specification
o It's 'working' MF Collection Specification, which is the one used for
detection
5.3.1 MF Collection Specifications
MF Collection Specifications contain the following fields:
1. TD: (T)ype of MF tones to (D)etect (a 2-bit field):
00b = not defined
01b = R1
10b = R2 Forwards
11b = R2 Backwards
2. k: The number of digits to collect before initial report: 1 to 16
3. N: The total number of digits to collect: 1 to 40
4. MIN_POWER: The minimum allowable power per frequency (a value of 0 = - 25
dBm; a value of 21 = -45 dBm)
5. MIN_MAKE: The minimum duration of a valid MF digit, in ms (0 to 255).
6. MIN_BREAK: The minimum interdigital silence duration, in ms (0 to 255).
7. IDTO: Inter-digit Timeout. A timeout will be reported if the silence
between two MF digits exceeds IDTO seconds. Range is 0 seconds (disables)
to 255 seconds.
8. PSC: Permanent Signal Condition. A timeout will be reported if the
duration of an MF digit exceeds PSC. Range is 0 seconds (disables) to 255
seconds.
-38-
<PAGE> 61
EVP-SRM (DSP) Software Design Specification 39
- ------------------------------------------------------------------------
9. FDTO: First Digit Timeout. A timeout will be reported if the time to
collect the first digit exceeds FDTO. Range is 0 seconds (disables) to
255 seconds.
10. TDTO: Total Digit Timeout. A timeout will be reported if the time to
collect all digits exceeds TDTO. Range is 0 seconds (disables) to 255
seconds.
11. ED: End Digit. Detection of this MF digit ends MF collection.
12. CD: Cancel Digit. Detection of this MF digit causes the DSP to delete all
collected digits and restart MF detection.
13. CW: Control Word - an 8-bit mask with the following format:
----------------------------------------------------
7 6 5 4 3 2 1 0
----------------------------------------------------
DE P UE UC RD IN FT
----------------------------------------------------
Table 5-5: Control Word Bit Definitions
o bit 1,0: FT = must accept frequency tolerance:
00 = +/-(1.5%+10) Hz for R1; +/-10 Hz for R2
01 = +/-(1.5%+15) Hz for R1; +/-15 Hz for R2
10 = +/-(1.5%+20) Hz for R1; +/-20 Hz for R2
11 = not defined
o bit 2: IN = initial notification. If this bit is set, the DSP will
make the initial report when k digits are detected.
o bit 3: RD = report durations. If this bit is set, the DSP will
report on and off durations for each digit detected. Durations
will have a granularity of 8 ms.
o bit 4: UC = use cancel code. If this bit is set, the DSP will end
MF collection when the end code is detected.
o bit 5: UE = use end code. If this bit is set, the DSP will end MF
collection when the end code is detected.
o Bit 6: P = PCM type:
1 = Alaw
0 = [mu]Law
-39-
<PAGE> 62
EVP-SRM (DSP) Software Design Specification 40
- ------------------------------------------------------------------------
o bit 7: DE = detection edge:
1 = leading edge detection
0 = trailing edge detection
14. TT, ISTT, IS: These fields are ignored in this state. They are included
to allow the same Collection Specification format be used for MfcR2
signalling.
The size in bits and the range of each field in the Collection Specifications is
shown in Table 5-6. Table 5-7 shows the format of each channel's MF parameter
context. The 'Default CS ID' field contains the ID for this channel's default
collection spec. Words 2-7 of Table 5-7 contain this channel's working
Collection Specification, and are the exact format of the default Collection
Specifications (which are each 6 words long).
- --------------------------------------------------------------------------------
Field Units unsigned Size (bits) Range
- --------------------------------------------------------------------------------
TT type of MF unsigned 2 0 to 3
TD type of MF unsigned 2 0 to 3
k number of digits unsigned 4 1 to 16
N number of digits unsigned 6 1 to 40
MIN_POWER (-25 - #) dBm unsigned 5 0 to 20
MIN_MAKE ms unsigned 8 0 to 255
MIN_BREAK ms unsigned 8 0 to 255
IDTO s unsigned 8 0 to 255
PSC s unsigned 8 0 to 255
FDTO s unsigned 8 0 to 255
TDTO s unsigned 8 0 to 255
ISTT state transition fa unsigned 4 0 to 10
IS state unsigned 4 0 to 5
ED DTMF digit unsigned 4 0 to 15
CD DTMF digit unsigned 4 0 to 15
CW 8-bit mask bit mask 8 0 to 255
- --------------------------------------------------------------------------------
91 bits
6 words
---------------------
Table 5-6: MF Collection Specification Parameter Units
-40-
<PAGE> 63
EVP-SRM (DSP) Software Design Specification 41
- ------------------------------------------------------------------------
<TABLE>
===========================================================================================================
<CAPTION>
High Byte Low Byte
===========================================================================================================
Word 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
========= -----------------------------------------------------------------------------------------------------------
<S> <C> <C>
1 | | Default CS ID
-----------------------------------------------------------------------------------------------------------
2 TT | TD | k | | N
-----------------------------------------------------------------------------------------------------------
3 | MIN_POWER | MIN_MAKE
-----------------------------------------------------------------------------------------------------------
4 MIN_BREAK | CW
-----------------------------------------------------------------------------------------------------------
5 IDTO | PSC
-----------------------------------------------------------------------------------------------------------
6 FDTO | TDTO
-----------------------------------------------------------------------------------------------------------
7 ISTT | IS | ED | CD
- ----------------------------------------------------------------------------------------------------------------------
</TABLE>
Table 5-7: Internal MF parameter channel context
5.3.2 MF Detection Parameter Memory Usage
For N channels of MF Detection, the total memory usage for MF channel context
and Collection Specifications is N*7+35*6 = 210+7N 16-bit words. For all 63
channels, this is 651 words. For 30 channels, this is 420 words.
5.4 Call Progress Detection Parameters
Call progress detection is configured using CP Tone Groups and CP Collection
Specifications. CP Tone Groupos reference CP Tone Specifications, which each
describe a tone to detect. CP Collection Specifications contain other detection
parameters, such as timeouts and PCM type.
5.4.1 CP Tone Groups
There are 35 CP Tone Groups, which allow for 35 separate groupings of tones to
be configured at any one time. The CP Tone Groups are referenced by ID, which
number from 1 to 35.
Each CP Tone Group is thirty 16-bit words long, with each word containing the ID
of a CP Tone Specification. This allows for a maximum of thirty CP Tone
Specification Ids. If a particular CP Tone Group has less than thirty CP Tone
Specifications, then the CP Tone Specification IDs occupy the first part of the
CP Tone Group, and the remaining words are '0.'
-41-
<PAGE> 64
EVP-SRM (DSP) Software Design Specification 42
- ------------------------------------------------------------------------
Although the CP Tone Group only needs 9 bits to store each CP Tone Specification
ID, 16 bits are reserved for each CP Tone Specification ISD. This is done so the
DSP can replace these fields with 16-bit addresses.
An example CP Tone Group, as it would exist in the DSP's memory, follows. In
this example, 26 CP Tone Specifications are used:
-42-
<PAGE> 65
EVP-SRM (DSP) Software Design Specification 43
- ------------------------------------------------------------------------
<TABLE>
===========================================================================================================
<CAPTION>
High Byte Low Byte
===========================================================================================================
Word 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
========= -----------------------------------------------------------------------------------------------------------
<S> <C>
----------------------------------------------------------------------------------------------------------
1 CP Tone Specification ID #1
----------------------------------------------------------------------------------------------------------
2 CP Tone Specification ID #2
----------------------------------------------------------------------------------------------------------
3 CP Tone Specification ID #3
----------------------------------------------------------------------------------------------------------
4 CP Tone Specification ID #4
----------------------------------------------------------------------------------------------------------
5 CP Tone Specification ID #5
----------------------------------------------------------------------------------------------------------
6 CP Tone Specification ID #6
----------------------------------------------------------------------------------------------------------
7 CP Tone Specification ID #7
----------------------------------------------------------------------------------------------------------
8 CP Tone Specification ID #8
----------------------------------------------------------------------------------------------------------
9 CP Tone Specification ID #9
----------------------------------------------------------------------------------------------------------
10 CP Tone Specification ID #10
----------------------------------------------------------------------------------------------------------
11 CP Tone Specification ID #11
----------------------------------------------------------------------------------------------------------
12 CP Tone Specification ID #12
----------------------------------------------------------------------------------------------------------
13 CP Tone Specification ID #13
----------------------------------------------------------------------------------------------------------
14 CP Tone Specification ID #14
----------------------------------------------------------------------------------------------------------
15 CP Tone Specification ID #15
----------------------------------------------------------------------------------------------------------
16 CP Tone Specification ID #16
----------------------------------------------------------------------------------------------------------
17 CP Tone Specification ID #17
----------------------------------------------------------------------------------------------------------
18 CP Tone Specification ID #18
----------------------------------------------------------------------------------------------------------
19 CP Tone Specification ID #19
----------------------------------------------------------------------------------------------------------
20 CP Tone Specification ID #20
----------------------------------------------------------------------------------------------------------
21 CP Tone Specification ID #21
----------------------------------------------------------------------------------------------------------
22 CP Tone Specification ID #22
----------------------------------------------------------------------------------------------------------
23 CP Tone Specification ID #23
----------------------------------------------------------------------------------------------------------
24 CP Tone Specification ID #24
----------------------------------------------------------------------------------------------------------
25 CP Tone Specification ID #25
----------------------------------------------------------------------------------------------------------
26 CP Tone Specification ID #26
----------------------------------------------------------------------------------------------------------
27 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
----------------------------------------------------------------------------------------------------------
28 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
----------------------------------------------------------------------------------------------------------
29 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
----------------------------------------------------------------------------------------------------------
30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- ---------------------------------------------------------------------------------------------------------------------
</TABLE>
Table 5-8: Example CP Tone Group
-43-
<PAGE> 66
EVP-SRM (DSP) Software Design Specification 44
- ------------------------------------------------------------------------
Although there is wasted space associated with a CP Tone Group with less than 30
CP Tone Specifications, there is an advantage to fixed-length CP Tone Groups: it
is much easier to address, delete, add, and replace CP Tone Groups during run
time when they are a fixed length.
5.4.2 CP Tone Specifications
There are two types of CP Tone Specifications: Normal and SIT. Normal CP Tone
Specifications are 21 words long. Although SIT Tone Specifications are only 18
words long, the DSP needs 28 words of space after translating to values used by
the Universal Tone Detector.
The DSP can handle up to 10 unique Normal CP Tone Specifications per CP Tone
Group (10*35=350 Normal CP Tone Specifications), and up to one unique SIT CP
Tone Specification per CP Tone Group (1*35=SIT CP Tone Specifications).
-44-
<PAGE> 67
EVP-SRM (DSP) Software Design Specification 45
- ------------------------------------------------------------------------
CP Tone Specifications are referenced by ID, numbered 1 to 385. The first 350
are Normal CP Tone Specifications, and the last 35 (IDs #351 - #385) are SIT CP
Tone Specifications.
Table 5-9 and Table 5-10 show the format and definitions for all fields in
Normal CP Tone Specifications and SIT CP Tone Specifications. See Section 4.5
for more information on the format of tones detected by UTD.
- --------------------------------------------------------------------------------
Word Value Units Range
- --------------------------------------------------------------------------------
1 Tone Category Category Number 1 to 9
2 Tone Type Tone Type 0 to 2
3 Return Value Return Code 0 to 32767
4 Required Cadences Cadence Number 0 to 32767
5 Frequency 1 Hz 300 to 3300
6 Frequency 1 Deviation Hz 0 to 1500
7 Frequency 2 Hz 0 to 1500
8 Frequency 2 Deviation Hz 300 to 3300
9 Min Make 1 ms 100 to 32767
10 Max Make 1 ms 100 to 32767
11 Min Break 1 ms 0, 100 to 32767
12 Max Break 1 ms 0, 100 to 32767
13 Min Make 2 ms 0, 100 to 32767
14 Max Make 2 ms 0, 100 to 32767
15 Min Break 2 ms 0, 100 to 32767
16 Max Break 2 ms 0, 100 to 32767
17 Min Make 3 ms 0, 100 to 32767
18 Max Make 3 ms 0, 100 to 32767
19 Min Break 3 ms 0, 100 to 32767
20 Max Break 3 ms 0, 100 to 32767
21 Min Power dBm 0 to -45
- --------------------------------------------------------------------------------
Table 5-9: Normal CP Tone Specification format
-45-
<PAGE> 68
EVP-SRM (DSP) Software Design Specification 46
- ------------------------------------------------------------------------
- --------------------------------------------------------------------------------
Word Value Units Range
- --------------------------------------------------------------------------------
1 Tone Category Category Number 6
2 SIT Type SIT Type 1, 2
3 Return Value Return Code 0 to 32767
4 Frequency 1 Cadence Number 300 to 3300
5 Bandwidth 1 Hz 0 to 1500
6 Frequency 2 Hz 300 to 3300
7 Bandwidth 2 Hz 0 to 1500
8 Frequency 3 Hz 300 to 3300
9 Bandwidth 3 Hz 0 to 1500
10 Frequency 4 Hz 300 to 3300
11 Bandwidth 4 Hz 0 to 1500
12 Frequency 5 Hz 300 to 3300
13 Bandwidth 5 Hz 0 to 1500
14 Short Min ms 0, 100 to 32767
15 Short Max ms 0, 100 to 32767
16 Long Min ms 0, 100 to 32767
17 Long Max ms 0, 100 to 32767
18 Min Power dBm 0 to -45
19 Reserved -- --
20 Reserved -- --
21 Reserved -- --
22 Reserved -- --
23 Reserved -- --
24 Reserved -- --
25 Reserved -- --
26 Reserved -- --
27 Reserved -- --
28 Reserved -- --
- --------------------------------------------------------------------------------
Table 5-10: SIT CP Tone Specification format
-46-
<PAGE> 69
EVP-SRM (DSP) Software Design Specification 47
- ------------------------------------------------------------------------
5.4.3 CP Collection Specifications
Each CP Collection Specification contains the following parameters:
1. ID: This is a unique identifier for a default collection specification,
numbered 1 to 35.
2. P: The type of PCM to use on this channel:
1 = ALaw
0 = [mu]Law
3. PSC: Permanent Signal Condition" 0 (disables) to 127 seconds (7 bits
unsigned)
4. TC: Tone Cessation Reporting:
1 = Report when a tone is no longer present (falling edge reported)
0 = Don't report when a tone is no longer present (no falling edge
reported)
5. FDTO: First Digit Timeout 0 (disables) to 127 seconds (7 bits unsigned)
The formal of the CP Detection Collection Specification is shown in Table 5-11.
note that the ID is not contained in the formal. For default collection
specifications, the ID is simply the index of this collection specification in
the block of memory that contains all default collection specifications.
<TABLE>
===========================================================================================================
<CAPTION>
High Byte Low Byte
===========================================================================================================
Word 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
========= -----------------------------------------------------------------------------------------------------------
<S> <C>
1 P | PSC | TC | FDTO
- ----------------------------------------------------------------------------------------------------------------------
</TABLE>
Table 5-11: CP Detection Collection Specification format
5.4.4 CP Detection Channel Context
The DSP maintains the following context for each channel:
o Current working CP Collection Specification, which is the one used for
detection
o ID of its current default CP Collection Specification
o ID of the CP Tone Group to use for this channel
-47-
<PAGE> 70
EVP-SRM (DSP) Software Design Specification 48
- ------------------------------------------------------------------------
Table 5-12 shows the format of each channel's CP Detect parameter context.
<TABLE>
===========================================================================================================
<CAPTION>
High Byte Low Byte
===========================================================================================================
Word 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
========= -----------------------------------------------------------------------------------------------------------
<S> <C>
1 P | PSC | TC | FDTO
- ----------------------------------------------------------------------------------------------------------------------
2 Default CP Collection Spec ID | CP Tone Group ID
- ----------------------------------------------------------------------------------------------------------------------
</TABLE>
Table 5-12: CP Detection Channel Context
5.4.5 CP Detection Parameter Memory Usage
For 30 channels of Call Progress Detection, the total memory usage for the CP
Detection Parameters in 9475 16-bit words. Table 5-13 shows a breakdown of this
memory usage.
<TABLE>
- ------------------------------------------------------------------------------------------------
<CAPTION>
Section Number of entries Size per entry Memory Usage
- ------------------------------------------------------------------------------------------------
<S> <C> <C> <C>
Channel context 30 2 60
Default Collection Specifications 35 1 35
CP Tone Groups 35 30 1050
Normal CP Tone Specifications 350 21 7350
SIT CP Tone Specifications 35 28 980
- ------------------------------------------------------------------------------------------------
Total Memory Usage: 9475
</TABLE>
Tabel 5-13: CP Detection Parameter Memory Usage
5.5 Tone Generation Parameters
Tone Generation uses four types of structures to convey what tone (or tones) is
(are) to be generated: Simple Tone Specifications, Special Tone Specifications,
Special Case Templates, and User-Defined Tone Groups:
o SIMPLE TONE SPECIFICATIONS: These are used to generate tones that are
single, dual, or amplitude modulated, with one to three cadences, and
unchanging frequency and power.
o SPECIAL CASE TONE TIMPLATES: These are used to generate tones with up to
four frequencies, or with time varying frequency or power levels.
o SPECIAL TONE SPECIFICATIONS: These are grouping of Special Case Tone
Templates that are to be generated in order. This allows for generation
of complex tones (e.g. 'bong' or SIT tones).
-48-
<PAGE> 71
EVP-SRM (DSP) Software Design Specification 49
- ------------------------------------------------------------------------
o USER-DEFINED TONE GROUPS: These are a collection of Simple Tone
Specifications and Special Tone Specifications, grouped together to
define a related set of tones (e.g. a group of tones that defines a
country's tone plan).
Figure 5-8 shows this hierarchy.
------------------------
Simple Tone
|--------- Specification (1 of 512)
------------------- | ------------------------
User-Defined Tone | Simple Tonen
Group (1 of 64) ----------| Specification
------------------- | ------------------------
| Simple Tonegen
| specification
| ------------------------
(up to 64)
------------------- | ------------------------
User-Defined Tone | Special Tone
Group |--------- Specification (1 of 64) ----|
------------------- | ------------------------ |
| Special Tone |
| Specification |
| ------------------------ |
| Special Tone |
|---------- Specification |
| ------------------------ |
| Special Tone |
|---------- Specification |
------------------------ (up to 5)
|
------------------------ |
Special Case Tone |
Template (1 of 64) ----|
------------------------ |
Special Case Tone |
Template ----|
------------------------
Special Case Tone
Template
------------------------
Figure 5-8: Tone Generation Parameter hierarchy
The following sections show the format and definitions of the fields contained
in each level of tone specification.
5.5.1 Simple Tone Specifications
There are 512 Simple Tone Specifications, which allows for an average of 14 to
15 unique simple tones per country (assuming 35 countries).
-49-
<PAGE> 72
EVP-SRM (DSP) Software Design Specification 50
- ------------------------------------------------------------------------
Each Simple Tone Specification has the following characteristics:
o A Simple Tone Specification is referenced by ID, which corresponds to the
order in which it occurs in memory (ID = 1 to 512).
o To allow for easy addition and deletion of Simple Tone Specifications,
each Simple Tone Specification will be a fixed length of 10 words (16
bits/word).
o Simple Tone Specifications are used to generated single, dual, and
amplitude modulated tones, with unchanging frequency and power levels,
with one to three cadence pairs.
Table 5-14 shows the format for Simple Tone Specifications.
<TABLE>
-----------------------------------------------------------------------------------------------------------
<CAPTION>
High Byte Low Byte
-----------------------------------------------------------------------------------------------------------
Word 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
========= ===========================================================================================================
<S> <C>
1 Repeat Count (0 = repeat indefinitely)
- ----------------------------------------------------------------------------------------------------------------------
2 T | Frequency 1 (HZ)
- ----------------------------------------------------------------------------------------------------------------------
3 Frequency 2 (Hz)
- ----------------------------------------------------------------------------------------------------------------------
4 Power 1 | Power 2, or modulation %
- ----------------------------------------------------------------------------------------------------------------------
5 make 1 (ms)
- ----------------------------------------------------------------------------------------------------------------------
6 break 1 (0 for continuous)
- ----------------------------------------------------------------------------------------------------------------------
7 make 2 (0 for single cadenced tone)
- ----------------------------------------------------------------------------------------------------------------------
8 break 2
- ----------------------------------------------------------------------------------------------------------------------
9 make 3 (0 for double cadenced tone)
- ----------------------------------------------------------------------------------------------------------------------
10 break 3
- ----------------------------------------------------------------------------------------------------------------------
</TABLE>
Table 5-14: Simple Tone Specification Format
o T is the Type of tone:
T = 0: single/dual tone. Low byte in word #4 contains the
power of the second frequency.
T = 1: amplitude modulated tone. Low byte in word #4 contains the
modulation percentage (in %). Frequency 1 is the carrier frequency,
and Frequency 2 is the modulation frequency.
o Units for Power 1 and Power 2 are 0.5 dBm. Allowable values are +6 to -
100, which allows for +3 to -50 dBm.
-50-
<PAGE> 73
EVP-SRM (DSP) Software Design Specification 51
- ------------------------------------------------------------------------
5.5.1.1 Special Tone Specifications
are handled using Special Tone Specifications.
There are 64 Special Tone Specifications, which allows for an average of 1 to 2
unique special tones per country (assuming 35 countries).
Each Special Tone Specification has the following characteristics:
o A Special Tone Specification is referenced by ID, which corresponds to
the order in which it occurs in memory. (ID = 513 to 576)
o To allow for easy addition and deletion of Special Tone Specifications,
each Special Tone Specification will be a fixed length of 5 words (16
bits/word).
o Special Tone Specifications are used to generated tones that have
changing frequencies, cadences or power levels, and tones with more than
two frequencies.
Table 5-15 shows the format for Special Tone Specifications.
<TABLE>
-----------------------------------------------------------------------------------------------------------
<CAPTION>
High Byte Low Byte
-----------------------------------------------------------------------------------------------------------
Word 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
========= ===========================================================================================================
<S> <C>
1 R | Special Case Template ID #1
- ----------------------------------------------------------------------------------------------------------------------
2 Special Case Template ID #2 (0xFFFF if none)
- ----------------------------------------------------------------------------------------------------------------------
3 Special Case Template ID #3 (0xFFFF if none)
- ----------------------------------------------------------------------------------------------------------------------
4 Special Case Template ID #4 (0xFFFF if none)
- ----------------------------------------------------------------------------------------------------------------------
5 Special Case Template ID #5 (0xFFFF if none)
- ----------------------------------------------------------------------------------------------------------------------
</TABLE>
Table 5-15: Special Tone Specification Format
o R is the repeat flag:
R = 0: generate each of the Special Case Tone Templates in order,
then silence.
R = 1: generate each of the Special Case Tone Templates in order,
then repeat.
-51-
<PAGE> 74
EVP-SRM (DSP) Software Design Specification 52
- ------------------------------------------------------------------------
5.5.2 Special Case Tone Templates
Special Case Tone Templates are used when generating special tones using Special
Tone Specifications, defined in Section 5.5.1.1 above.
Special Case Tone Templates define tones with one to four frequencies, at
different power levels. The first one or two frequencies can vary in frequency,
and the tone power can be exponentially decayed. The tone also has a cadence and
a repeat count defined.
Each Special Case Tone Template is ten 16-bit words long, and has the format
shown in Table 5-16.
<TABLE>
-----------------------------------------------------------------------------------------------------------
<CAPTION>
High Byte Low Byte
-----------------------------------------------------------------------------------------------------------
Word 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
========= ===========================================================================================================
<S> <C>
1 T1 | Frequency 2 (Hz)
-----------------------------------------------------------------------------------------------------------
2 Frequency 2 (Hz)
-----------------------------------------------------------------------------------------------------------
3 T2 | Frequency 3 (Hz) () if not tripe/quadruple tone)
-----------------------------------------------------------------------------------------------------------
4 Frequency 4 (Hz)
-----------------------------------------------------------------------------------------------------------
5 Power 1 | Power 2, or modulation %
-----------------------------------------------------------------------------------------------------------
6 Power 3 | Power 4, or modulation %
-----------------------------------------------------------------------------------------------------------
7 delta frequency 1(Hz/s) | delta frequency 2 (Hz/s)
-----------------------------------------------------------------------------------------------------------
8 repeat count (0 = infinite)
-----------------------------------------------------------------------------------------------------------
9 make time (ms) () for continuous)
-----------------------------------------------------------------------------------------------------------
10 break time (ms)
- ----------------------------------------------------------------------------------------------------------------------
</TABLE>
Table 5-16: Special Case Tone Template Format
o Tl and T2 are the types for the first and second frequency pairs:
T1 = 0: single/dual tone. Low byte in word #5 contains the power of
Frequency 2.
T1 = 1: amplitude modulated tone. Low byte in word #4 contains the
modulation percentage (in %). Frequency 1 is the carrier frequency,
and Frequency 2 is the modulation frequency.
T2 = 0: single/dual tone. Low byte in word #6 contains the power of
Frequency 4.
-52-
<PAGE> 75
EVP-SRM (DSP) Software Design Specification 53
- ------------------------------------------------------------------------
T2 = 1: amplitude modulated tone. Low byte in word #6 contains the
modulation percentage (in %). Frequency 3 is the carrier frequency,
and Frequency 4 is the modulation frequency.
o Units for Power 1, 2, 3, and 4 are 0.5 dBm. Allowable values ARE +6 to
-100, which allows for +3 to -50 dBm.
o Decay constant affects all tones. This is an exponential decay, which
uses the following formula:
A(t) = Ao * e(-8t/[tau]), where:
A(t) = tone amplitude at time t
Ao = initial tone amplitude
t = time in ms
[tau]= decay constant in 8 ms units
o Delta frequency 1 and delta frequency 2 affect Frequency 1 and Frequency
2, respectively. This changes the generated frequency every 8 ms by the
rate specified in Hz/s. Continuous phase is maintained.
There is a unique ID associated with each Special Case Tone Template. There can
be a maximum of 64 Special Case Templates defined at any given time, and they
are referenced by ID, numbered 577-641.
5.5.3 User-defined Tone Groups
Tone specifications and can be grouped together to form User-defined Tone
Groups. Each Tone Group contains the IDs of up to 64 Simple and/or Special tone
specifications. This allows tone generation commands to outpulse tones, using 6
bit numbers (which correspond to a tone specification's location within a tone
group).
There are up to 64 Tone Groups, and each is referenced by Tone Group ID (0 to
63).
-53-
<PAGE> 76
EVP-SRM (DSP) Software Design Specification 54
- ------------------------------------------------------------------------
The format of User-defined Tone Groups is as follows:
<TABLE>
-----------------------------------------------------------------------------------------------------------
<CAPTION>
High Byte Low Byte
-----------------------------------------------------------------------------------------------------------
Word 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
========= ===========================================================================================================
<S> <C>
Tone 0 0 0 0 0 0 0 Tone Specification ID #1
-------------------------------------------------------------------
Tone 1 0 0 0 0 0 0 Tone Specification ID #2 ( or 0)
-------------------------------------------------------------------
Tone 2 0 0 0 0 0 0 Tone Specification ID #3 ( or 0)
-------------------------------------------------------------------
0 0 0 0 0 0 Tone Specification ID #4 ( or 0)
-------------------------------------------------------------------
0 0 0 0 0 0
-------------------------------------------------------------------
Tone 63 0 0 0 0 0 0 Tone Specification ID #64 ( or 0)
- ----------------------------------------------------------------------------------------------------------------------
</TABLE>
Table 5-17: User-defined Tone Group Format
5.5.3.1 User-defined Tone Groups for DTMF. MF generation
Four User-defined Tone Groups are reserved for DTMF, MFR1, R2 Forwards and R2
Backwards tone generation. These tone groups have only 16 Tone Specification
IDs, and therefore the individual tone specifications can be referenced using 4
bit numbers (which correspond to a tone specification's index within a tone
group).
These special user-defined Tone Groups have the following IDs:
-----------------------------------------------------------------
Tonegen Group Tone Type User-Defined Tonegen Group ID
-----------------------------------------------------------------
DTMF 0
MFR1 1
MFR2 Forwards 2
MFR2 Backwards 3
-----------------------------------------------------------------
Table 5-18: IDs for reserved User-defined Tone Groups
5.5.4 Tone Generation Parameter Memory Usage
The total DSP memory usage for the Tone Generation Parameters is 10176 16-bit
words, and is organized as follows.
-54-
<PAGE> 77
EVP-SRM (DSP) Software Design Specification 55
- ------------------------------------------------------------------------
<TABLE>
- --------------------------------------------------------------------------------
<CAPTION>
16-bit words per Number of Memory
Section ID Specification Specifications Usage
numbering
- --------------------------------------------------------------------------------
<S> <C> <C> <C> <C>
Simple Tone 0 to 511 10 512 5120
Specifications
Special Case 512 to 575 10 64 640
Templates
Special Tone 576 to 640 5 64 320
Specifications
Tone Groups 0 to 63 64 64 4096
- --------------------------------------------------------------------------------
</TABLE>
Table 5-19: Tone Generation Parameter Memory Usage
5.6 MFcR2 Signalling Parameters
MFcR2 signalling is configured on a per-channel basis using several sets of
configuration parameters:
o MF Collection Specifications are used for detection parameters.
o User-defined Tone Groups are used for generation parameters.
o State Transition Tables contain all configurable information regarding
the appropriate Actions and State Transitions in response to any Event.
o Actions each contain a one or more Processes.
o Processes are a set of atomic functions that are required to perform the
MFR2 protocol.
The DSP maintains the following context for each channel:
o ID of its current default Collection Specification
o Its 'working' Collection Specification, which is the one used for
detection
-55-
<PAGE> 78
EVP-SRM (DSP) Software Design Specification 56
- ------------------------------------------------------------------------
5.6.1 MF Collection specifications
The MF Collection Specifications defined in Section MF Collection Specifications
are also used for MFcR2 signalling. Three fields that were ignored in the MF
Detect state are now defined:
1. TT: (T)ype of MF tones to (T)ransmit (a 2-bit field). This specifies
which User-defined Tone Group to use for tone generation. See Section
User-defined Tone Groups for DTMF, MF generation for details:
00b = not used (DTMF)
01b = R1
lOb = R2 Forwards
11b = R2 Backwards
2. ISTT: Initial State Transition Table D. This specifies which state
transition table to use for MF forward compelled signalling (1 to 10; 0 =
unconfigured).
3. S: Initial State. This specifies the starting state within the state
transition table for MF Forward compelled signalling (1 to 5; 0 =
unconfigured).
Table 5-20 shows the format of each channel's MFcR2 parameter context. The
'Default CS ID' field contains the ID for this channel's default collection
spec. Words 2-7 contain this channel's working Collection Specification, and are
the exact format of the default Collection Specifications (which are each 6
words long).
<TABLE>
-----------------------------------------------------------------------------------------------------------
<CAPTION>
High Byte Low Byte
-----------------------------------------------------------------------------------------------------------
Word 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
========= ===========================================================================================================
<S> <C>
1 | | Default CS ID
-----------------------------------------------------------------------------------------------------------
2 TT | TD | k | | N
-----------------------------------------------------------------------------------------------------------
3 MIN_POWER | MIN_MAKE
-----------------------------------------------------------------------------------------------------------
4 MIN_BREAK | CW
-----------------------------------------------------------------------------------------------------------
5 IDTO | PSC
-----------------------------------------------------------------------------------------------------------
6 FDTO | TDTO
-----------------------------------------------------------------------------------------------------------
7 ISTT | IS | ED | CD
- ----------------------------------------------------------------------------------------------------------------------
</TABLE>
Table 5-20: Internal MRcR2 parameter channel context
-56-
<PAGE> 79
EVP-SRM (DSP) Software Design Specification 57
- ------------------------------------------------------------------------
5.6.2 MFcR2 State Transition Tables
MFcR2 Forward signalling is implemented using a programmable state machine. When
a channel begins forward signalling, it is given an initial State Transition
Table, and an initial State within that table. The State Transition Table
contains all States needed to implement a given country-specific MFcR2 protocol.
Each State defines the appropriate Actions and State Transitions to be executed
due to the detection of all Events.
- --------------------------------------------------------------------------------
State Event
0 1 2 3 4 . . 13 14 15
- --------------------------------------------------------------------------------
1 1A (A/ST) (A/ST) (A/ST) (A/ST) . . (A/ST) (A/ST) (A/ST)
- --------------------------------------------------------------------------------
2 1A (A/ST) (A/ST) (A/ST) (A/ST) . . (A/ST) (A/ST) (A/ST)
- --------------------------------------------------------------------------------
3 1A (A/ST) (A/ST) (A/ST) (A/ST) . . (A/ST) (A/ST) (A/ST)
- --------------------------------------------------------------------------------
4 1A (A/ST) (A/ST) (A/ST) (A/ST) . . (A/ST) (A/ST) (A/ST)
- --------------------------------------------------------------------------------
5 1A (A/ST) (A/ST) (A/ST) (A/ST) . . (A/ST) (A/ST) (A/ST)
- --------------------------------------------------------------------------------
Table 5-21: MFcR2 State Transition Table Format
Each field in the state transition table is defined as follows:
1. State: There are 5 states in each State Transition Table, numbered 1 to
5.
2. Event 0: This column contains the initial actions (IA) to be performed
when transitioning to a particular state.
3. Events 1-15: These columns define the actions (A) and state transitions
(ST) to execute when the MF digits 1-15 are detected.
4. IA, A: These entries contain the ID of an Action to be performed
5. ST: This is a state to transition to, numbered 1 to 5. If ST = 0, there
is no state transition required upon detection of this Event in this
State. If ST is nozero, transition to that state and execute the Initial
Action for that state.
Each State Transition Table is referenced by State Transition Table ID, numbered
1 to 10.
-57-
<PAGE> 80
EVP-SRM (DSP) Software Design Specification 58
- ------------------------------------------------------------------------
5.6.3 Actions
Actions consist of an Action ID, the number of Processes in this Action, and a
list of Processes that are executed in the order. Actions are referenced by
Action ID, numbered 1 to 200. Actions are all 50 bytes long. Processes are
variable length, depending on the process ID, in one byte increments.
The format of the Actions is as follows:
[Table depicting MFcR2 Action Format]
Table 5-22: MFcR2 Action Format
5.6.4 Processes
Processes are the atomic building block for MFcR2 signalling. The set of defined
processes allows for construction of any potential actions that need to be
performed for all variations of MFcR2 signalling.
The following table shows the process ID, name, length (process ID plus process
data), and format for each process.
<TABLE>
- --------------------------------------------------------------------------------------------------------------------
<CAPTION>
PID Process Name Length Format (each <field> Description
(bytes) is 1 byte)
- --------------------------------------------------------------------------------------------------------------------
<S> <C> <C> <C> <C>
1 I: Ignore 1 <1> Ignore this event
- --------------------------------------------------------------------------------------------------------------------
2 E: Error 1 <2> Report severe error
condition
- --------------------------------------------------------------------------------------------------------------------
3 STRSWC: Switch Current 2 <3><new string Switch current digit string
String index> to the one given
- --------------------------------------------------------------------------------------------------------------------
4 SETDIG: Set digit index 2 <4><new digit Set digit index in current
index> string to the one given
- --------------------------------------------------------------------------------------------------------------------
5 OFFDIG: Offset digit 2 <5><offset> Adjust digit index in
index current string by the offset
given
- --------------------------------------------------------------------------------------------------------------------
6 INCDIG: Add one to digit 1 <6>
index
- --------------------------------------------------------------------------------------------------------------------
</TABLE>
-58-
<PAGE> 81
EVP-SRM (DSP) Software Design Specification 59
- ------------------------------------------------------------------------
<TABLE>
- --------------------------------------------------------------------------------------------------------------------
<S> <C> <C> <C> <C>
7 STTSWC: Switch state 4 <7><new STT><start Switch to new state
transition table state><execute initial transition table and new
state action> state in that table.
Optionally run the initial
action in that state.
- --------------------------------------------------------------------------------------------------------------------
8 PATMTC: Patten Match N+2 <8><number digits = Determine if the last N
N><digit 1><digit digits match this pattern.
2>..<digit N> If true, execute the next
process. If false, execute
(N <=[TBD]) the process after that.
- --------------------------------------------------------------------------------------------------------------------
9 SNDDIG: Send digit 2 <9><digit> If <digit> = <end digit>,
then report collected digits
to controller
- --------------------------------------------------------------------------------------------------------------------
10 SNDAT: Send digit at 2 <10><digit index> Send digit at digit index
given digit index <digit index> in current
string
- --------------------------------------------------------------------------------------------------------------------
11 REPORT: Report to 2 <11><Report ID> Send the <Report ID>
controller report to the controller
- --------------------------------------------------------------------------------------------------------------------
12 RESET: Reset protocol 12 <12> Reset the protocol. Restart
in the initial state given in
the working collection
spec.
- --------------------------------------------------------------------------------------------------------------------
13 NOP 1 <13> No operation (**THIS IS A
DUPLICATION OF THE
IGNORE PROCESS)
- --------------------------------------------------------------------------------------------------------------------
14 ERROR: kill the call 1 <14> send no status, discard
collected digit, go to idle
- --------------------------------------------------------------------------------------------------------------------
15 STORE 1 <15> Save digit in collected
digit string
- --------------------------------------------------------------------------------------------------------------------
16 CHKCNT 1 <16> Is the number of collected
digits = number
requested? If true,
execute the next process.
If false, execute the
process after that.
- --------------------------------------------------------------------------------------------------------------------
17 REPDIG 1 <17> Report collected digits to
controller
- --------------------------------------------------------------------------------------------------------------------
</TABLE>
-59-
<PAGE> 82
EVP-SRM (DSP) Software Design Specification 60
- ------------------------------------------------------------------------
<TABLE>
- --------------------------------------------------------------------------------------------------------------------
<S> <C> <C> <C> <C>
18 CLREND 1 <18> Store digit in collected
digit string. If collection
complete, send end flag
and report digit to
controller
- --------------------------------------------------------------------------------------------------------------------
19 REENTER 2 <19><reenter count> Counter is initially 0 when
MFcR2 begins. If Counter
< Reenter Count,
increment Counter,
execute the next process,
and skip the process after
that. If Counter = Reenter
Count, skip the next
process and execute the
process after that.
- --------------------------------------------------------------------------------------------------------------------
20- Reserved -- -- --
127
- --------------------------------------------------------------------------------------------------------------------
</TABLE>
Table 5-23: Process Definitions
5.6.5 MFcR2 Signalling Parameter Memory Usage
The total memory usage for the MFcR2 Signalling Parameters is 8820 16-bit words,
and is distributed as shown in Table 5-24.
-60-
<PAGE> 83
EVP-SRM (DSP) Software Design Specification 61
- ------------------------------------------------------------------------
[Table depicting MFcR2 Signalling Parameter Memory Usage]
Table 5-23: MFcR2 Signalling Parameter Memory Usage
6. DSP Time and Space Requirements
Currently, the time and space requirements are being tabulated in a separate
document. They will be included here in a future release of this document.
Table 6-1: DSP C54x MIPS Requirements by State
Table 6-2: DSP Memory Requirements
Table 6-3: Glossary of DSP Software Module Names
-61-
<PAGE> 84
EVP-SRM (DSP) Software Design Specification 62
- ------------------------------------------------------------------------
7. Command Messages
Commands from the Core Processor are used to update all parameters and
configurations, run diagnostic tests, and drive the state transitions for the
major states in Section 3.4.
7.1 Command String Format
The Core Processor issues commands to the DSPs using the first timeslot on the
first buffered serial port using point-to-point HDLC protocol. Each command
consists of a variable length command string, which is composed of the following
fields: a command type (CMD_type) command subtype (CMD_subtype), the channel
number (CMD_channel), the message length in bytes (CMD_length), and command
parameters (CMD_params).
o CMD_type and CMD_subtype are each 4 bits long, and together they combine
for the first byte of all command messages. CMD_type is in the high
nibble.
o CMD_channel is one byte long for commands that are channel specific; for
commands that have no associated channel, the CMD_channel field is 0
bytes long (not present).
o CMDJength is one byte long for all command messages
o The CMD_params field's length is variable, N one byte increments. For
certain CMD3ype / CMD_subtype combinations, the CMD_params field is 0
bytes long (not present).
The command string shall have one of the following structures, depending on
whether the CMD_channel field is present:
--------------------------------------------------------
1 CMD_type | CMD_subtype
--------------------------------------------------------
2 CMD_channel
--------------------------------------------------------
3 CMD_length
--------------------------------------------------------
4+ CMD_params
--------------------------------------------------------
Table 7-1: Command structure when CMD channel is present
-62-
<PAGE> 85
EVP-SRM (DSP) Software Design Specification 63
- ------------------------------------------------------------------------
--------------------------------------------------------
1 CMD_type CMD_subtype
--------------------------------------------------------
2 CMD_length
--------------------------------------------------------
3+ CMD_params
--------------------------------------------------------
Table 7-2: Command structure when CMD_channel is not present
7.2 Command Message Definitions
Table 7-3 shows the legal values for the CMD_type field.
-----------------------------------------------------------------------
CMD type (HEX) Function Description
-----------------------------------------------------------------------
0x0 IDLE Enter IDLE state
-----------------------------------------------------------------------
0x1 Diagnostic Test Execute diagnostics
-----------------------------------------------------------------------
0x2 DTMF Detection DTMF detection
command
-----------------------------------------------------------------------
0x3 MF Detection MF detection command
-----------------------------------------------------------------------
0x4 CP Detection CP detection command
-----------------------------------------------------------------------
0x5 Tone Generation Tone generation
command
-----------------------------------------------------------------------
0x6 MFcR2 Signalling MFcR2 signalling
command
-----------------------------------------------------------------------
0x7 - 0xF Not Used Reserved for future
expansion
-----------------------------------------------------------------------
Table 7-3: Legal CMD_type values.
Defined values for the CMD_subtype field are dependent on the CMD_type function.
Similarly, the defined values for the CMD_params field are dependent on the
CMD_type and CMDE_subtype values. The following subsections define all legal
combinations of CMD_subtype and CMD_params for each CMD_type.
7.2.1 IDLE (0x0) Commands
-63-
<PAGE> 86
EVP-SRM (DSP) Software Design Specification 64
- ------------------------------------------------------------------------
The IDLE command tells the DSP to place one (or all) channels in the IDLE state.
Table 7-4 describes the meanings of all IDLE commands. Note that if CMD_subtype
= 0, then all channels are to enter the IDLE state.
---------------------------------------------------------------------
Field Length Value Description
---------------------------------------------------------------------
CMD type 4 bits 0x0 IDLE type
---------------------------------------------------------------------
CMD subtype 4 bits 0x00 -0x3F Channel to enter
IDLE state (0=all
channels)
---------------------------------------------------------------------
CMD channel 0 bytes - Not present
(channel is in
CMD subtype
field)
---------------------------------------------------------------------
CMD length 1 byte 0x02 Length of this
message
---------------------------------------------------------------------
CMD params 0 bytes (none)
Not present
---------------------------------------------------------------------
Table 7-4; IDLE (x0x) commands
7.2.2 DIAGNOSTIC TEST (0x1) Commands
The run-time DSP image performs the following diagnostic tests:
1. Version: The DSP will supply the checksum and DSP software version upon
request.
2. TDM Loopback: The DSP will transmit on a given channel the received data
from that (or another) channel. If the DSP is commanded to do TDM
loopback with the HDLC channel, an error status is generated.
3. HDLC Echo: The HDLC Module will transmit back to the 860 whatever it
receives.
4. Timer Test: The DSP will set a timer for a duration which a known number
of frame syncs should be detected.
-64-
<PAGE> 87
EVP-SRM (DSP) Software Design Specification 65
- ------------------------------------------------------------------------
5. Performance Measure: The DSP will supply an abstract number indicating
the amount of idle time on the DSP for the last loop of the CSM.
08/05/97 CONFIDENTIAL
D2 Technologies Inc., Santa Barbara, CA 93101 tel: 805-564-3424
-65-
<PAGE> 88
EVP-SRM (DSP) Software Design Specification 66
- ------------------------------------------------------------------------
The following tables show the formats for the various runtime diagnostic test
commands.
7.2.2.1 DIAGNOSTIC TEST - Version (0x10) Command
Upon receipt of this command, the DSP will respond with a diagnostic status
containing the checksum and software version of the DSP code. CMD_channel is 0,
and there is no CMD_params section.
--------------------------------------------------------------------
Field Length Value Description
--------------------------------------------------------------------
CMD_type 4 bits 0x1 DIAGNOSTIC TEST
type
--------------------------------------------------------------------
CMD_subtype 4 bits 0x0 Version subtype
--------------------------------------------------------------------
CMD_channel 1 byte 0x00 Command is not
channel specific
--------------------------------------------------------------------
CMD_length 1 byte 0x03 Length of this message
--------------------------------------------------------------------
CMD_params 0 bytes (none) 0-length CMD_params
section
--------------------------------------------------------------------
Table 7-5: DIAGNOSTIC TEST - Version (0x10) Command
7.2.2.2 DIAGNOSTIC TEST - TDM Loopback (0x11) Command
Upon receipt of this command, the DSP will copy the data input on a given TDM
channel to the output on another TDM channel. If one of the commanded TDM
channels is an HDLC channel, then an error status is sent. CMD_channel contains
the input TDM channel to use, and CMD_params contains the output TDM channel to
use.
---------------------------------------------------------------------
Field Length Value Description
---------------------------------------------------------------------
CMD type 4 bits 0x1 DIAGNOSTIC TEST type
---------------------------------------------------------------------
CMD subtype 4 bits 0x1 TDM Loopback subtype
---------------------------------------------------------------------
CMD channel 1 byte 0x01 to Input TDM channel to use
0x3F
---------------------------------------------------------------------
-66-
<PAGE> 89
EVP-SRM (DSP) Software Design Specification 67
- ------------------------------------------------------------------------
---------------------------------------------------------------------
CMD length 1 byte 0x04 Length of this message
---------------------------------------------------------------------
CMD params 1 byte 0x01 to Output TDM channel to
0x3F use
---------------------------------------------------------------------
7.2.2.3 DIAGNOSTIC TEST - HDLC Echo (0x12)Command
Upon receipt of this command, the HDLC module will transmit back to the 860
whatever it receives. CMD_channel is 0, and there is no CMD-params section.
-----------------------------------------------------------------------------
Field Length Value Description
-----------------------------------------------------------------------------
CMD type 4 bits 0x1 DIAGNOSTIC TEST type
-----------------------------------------------------------------------------
CMD subtype 4 bits 0x2 HDLC Echo subtype
-----------------------------------------------------------------------------
CMD channel 1 byte 0x00 Command is not channel specific
-----------------------------------------------------------------------------
CMD length 1 byte 0x03 Length of this message
-----------------------------------------------------------------------------
CMD params 0 bytes (none) 0-length CMD_params section
-----------------------------------------------------------------------------
7.2.2.4 DIAGNOSTIC TEST - Measure Performance (0x13) Command
Upon receipt of this command, the DPS will provide a perforance indicator which
will represent the amount of idle time on the DSP for the last loop of the CSM.
CMD_channel is 0, and there is no CMD-params section.
-----------------------------------------------------------------------------
Field Length Value Description
-----------------------------------------------------------------------------
CMD type 4 bits 0x1 DIAGNOSTIC TEST type
-----------------------------------------------------------------------------
CMD subtype 4 bits 0x3 Measure Performance subtype
-----------------------------------------------------------------------------
CMD channel 1 byte 0x00 Command is not channel specific
-----------------------------------------------------------------------------
CMD length 1 byte 0x03 Length of this message
-----------------------------------------------------------------------------
CMD params 0 bytes (none) 0-length CMD_params section
-----------------------------------------------------------------------------
Table 7-6: DIAGNOSTIC TEST - TDM Loopback (0x11) Command
7.2.2.3 DIAGNOSTIC TEST - HDLC Echo (0x12) Command
-67-
<PAGE> 90
EVP-SRM (DSP) Software Design Specification 68
- ------------------------------------------------------------------------
Upon receipt of this command, the HDLC module will transmit back to the 860
whatever it receives. CMD_channel is 0, and there is no CMD_params section.
TABLE 7-7: DIAGNOSTIC TEST - HDLC ECHO (0X13) COMMAND
Upon receipt of this command, the DSP will provide a performance indicator which
will represent the amount of idle time on the DSP for the last loop of the CSM.
CMD_channel is 0, and there is no CMD_params section.
-----------------------------------------------------------------------------
Field Length Value Description
-----------------------------------------------------------------------------
CMD type 4 bits 0x1 DIAGNOSTIC TEST type
-----------------------------------------------------------------------------
CMD subtype 4 bits 0x3 Measure Performance subtype
-----------------------------------------------------------------------------
CMD channel 1 byte 0x00 Command is not channel specific
-----------------------------------------------------------------------------
CMD length 1 byte 0x03 Length of this message
-----------------------------------------------------------------------------
CMD params 0 bytes (none) 0-length CMD_params section
-----------------------------------------------------------------------------
Table 7-8: DIAGNOSTIC TEST - Measure Performance (0x13) Command
7.2.3 DTMF Detection (0x2) Commands
For the DTMF CMD_type, the values for CMD_subtype are as follows:
1. CMD_type = COLLECTION SPECIFICATION DOWNLOAD (0x0)
2. CMD_subtype = SETUP (0x1)
3. CMD_subtype = EXECUTION (0x2)
The format of each command follows.
7.2.3.1 DTMF/COLLECTION SPECIFICATION DOWNLOAD (0x20)
For this command, the CMD_params field contains an ID of the Collection
Specification, followed by all DTMF Collection Specification parameters. Upon
receipt of this command, the DSP will copy the values to the default DTMF
Collection Specification with this ID.
Table 7-9 shows the format of the DTMF/COLLECTION SPECIFICATION DOWNLOAD
command.
-68-
<PAGE> 91
EVP-SRM (DSP) Software Design Specification 69
- ------------------------------------------------------------------------
-----------------------------------------------------------------------------
Field Length Value Description
-----------------------------------------------------------------------------
CMD _type 4 bits 0x2 DTMF DETECTION type
-----------------------------------------------------------------------------
CMD _subtype 4 bits 0x1 Collection Specification Download
-----------------------------------------------------------------------------
CMD _channel 1 byte 0x00 Command is not channel specific
-----------------------------------------------------------------------------
CMD _length 1 byte 0x0E Length of this message
-----------------------------------------------------------------------------
CMD _params 11 bytes * All Collection Specification values
-----------------------------------------------------------------------------
Table 7-9: ASDF REMOVE CMD_CHANNEL
DTMF/COLLECTION SPECIFICATION
DOWNLOAD (0x20) Command
Table 7-10 shows the format of the CMD_params section of this command. See
Section 5.2.1 for field definitions.
- --------------------------------------------------------------------------------
Bits
- ---------------------===========================================================
Byte 76543210
=====================-----------------------------------------------------------
0 Collection Spec ID
- --------------------------------------------------------------------------------
1 CW | k
- --------------------------------------------------------------------------------
2 DE | N
- --------------------------------------------------------------------------------
3 P | FT | MIN_POWER
- --------------------------------------------------------------------------------
4 MIN_MAKE
- --------------------------------------------------------------------------------
5 MIN_BREAK
- --------------------------------------------------------------------------------
6 IDTO | PSC
- --------------------------------------------------------------------------------
7 FDTO
- --------------------------------------------------------------------------------
8 TDTO
- --------------------------------------------------------------------------------
9 POS_TWIST | NEG_TWIST
- --------------------------------------------------------------------------------
10 ED | CD
- --------------------------------------------------------------------------------
Table 7-10: CMD _params section format for DTMF/COLLECTION SPECIFICATION
DOWNLOAD (0x20) Command
-69-
<PAGE> 92
EVP-SRM (DSP) Software Design Specification 70
- ------------------------------------------------------------------------
7.2.3.1 DTMF/SETUP (0x21)
The DTMF/SETUP command is used to configure a given channel and to start
executing DTMF detection on that channel. The format of the DTMF/SETUP command
follows:
-------------------------------------------------------------------------
Field Length Value Description
-------------------------------------------------------------------------
CMD _type 4 bits 0x2 DTMF
-------------------------------------------------------------------------
CMD _subtype 4 bits 0x1 SETUP
-------------------------------------------------------------------------
CMD _channel 1 byte 0x01 - 0x3F Channel
-------------------------------------------------------------------------
CMD _length 1 byte (N+3) Length of this message
-------------------------------------------------------------------------
CMD _params N bytes *see below *see below
-------------------------------------------------------------------------
Table 7-11: DTMF/SETUP (0x21) Command Format
The CMD _params section of the DTMF/SETUP command consists of an execution flag
(EX), the default collection spec identifier to use (ID, and the number of
digits to collect (N). Optionally, the CMD _params section contains other
collection spec parameters. These parameters each have their own parameter ID (1
byte long), and parameter filed (1 byte long). The format of the CMD _params
section for this command follows:
----------------------------------------------------
Byte Bits
====================================================
7 6 5 4 3 2 1
----------------------------------------------------
0 EX | ID
----------------------------------------------------
1 | N
----------------------------------------------------
2+ optional param ID / param pairs
----------------------------------------------------
Table 7-12:
o If the EX bit is 1, then execution is to start after processing
this command. Otherwise, the DSP will wait for an execution
command separately, and maintain the configuration specified in
this command.
o If the ID field is 0, use the previous configuration. If there is
no previous configuration, then the DSP will generate an error
status. If the ID field is nonzero, then configure this channel
with this ID's default collection spec.
-70-
<PAGE> 93
EVP-SRM (DSP) Software Design Specification 71
- ------------------------------------------------------------------------
o N ranges from 1 to 40. The DSP will generate an error status if N
is outside this range.
If optional parameters are included in the DTMF/SETUP command, then the DSP will
update the working copy of the collection spec for this channel with the
parameters. The allowable values for each optional parameter follows:
------------------------------------------------------------------------
Parameter ID Parameter(s), bit locations
------------------======================================================
(1 byte) 7654321
==================------------------------------------------------------
0 | k
------------------------------------------------------
1 | MIN_POWER
------------------------------------------------------
2 MIN_MAKE
------------------------------------------------------
3 MIN_BREAK
------------------------------------------------------
4 CW
------------------------------------------------------
5 IDTO
------------------------------------------------------
6 PSC
------------------------------------------------------
7 PFTO
------------------------------------------------------
8 TDTO
------------------------------------------------------
9 POS_TWIST | NEG_TWIST
------------------------------------------------------
10 ED | CD
------------------------------------------------------
11-255 Reserved
------------------------------------------------------------------------
Table 7-13: ASDF UPDATE TABLE FOR NEW FORMAT Parameter ID/Parameter
definitions for DTMF/SETUP command
7.2.3.3 DTMF/EXECUTE (0x22)
The DTMF/EXECUTE is used to change the execution status only for a given
channel. The format of the DTMF/EXECUTE command follows:
-71-
<PAGE> 94
EVP-SRM (DSP) Software Design Specification 72
- ------------------------------------------------------------------------
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD _type 4 bits 0x2 DTMF DETECTION type
- --------------------------------------------------------------------------------
CMD _subtype 4 bits 0x3 EXECUTE subtype
- --------------------------------------------------------------------------------
CMD _channel 1 byte 0x01 - 0x3F Channel
- --------------------------------------------------------------------------------
CMD _length 1 byte 0x04 Length of this message = 4 bytes
- --------------------------------------------------------------------------------
CMD _params 1 byte 0x00, 0x01, or 0x02 START, STOP, ABORT
- --------------------------------------------------------------------------------
Table 7-14: ASDF UPDATE TABLE FOR CORRECT SUBTYPE
DTMF/EXECUTE (0x22) Command Format
o If CMD _params = 0x00 (START), the DSP will start DTMF collection
with the current configuration on the channel specified by CMD
channel.
o If CMD _params = 0x01 (STOP), the DSP will stop DTMF collection on
the channel specified by CMD _params = 0x02 (ABORT), the DSP will
stop DTMF collcection on the channels specified by CMD _channel,
and discard any previously unreported digits detected.
7.2.4 MF Detection (0x3) Commands
For the MF CMD _type, the values for CMD _subtype are as follows:
1. CMD _subtype = COLLECTION SPECIFICATION DOWNLOAD (0x0)
2. CMD _subtype = SETUP (0x1)
3. CMD _subtype = EXECUTION (0x2)
The format of each command follows.
-72-
<PAGE> 95
EVP-SRM (DSP) Software Design Specification 73
- ------------------------------------------------------------------------
7.2.4.1 MF/COLLECTION SPECIFICATION DOWNLOAD (0x30)
For this command, the CMD _params field contains an ID of the Collection
Specification, followed by all MF Collection Specification parameters. Upon
receipt of this command, the DSP will copy the values to the default MF
Collection Specification with this ID.
Table 7-15 shows the format of the MF/COLLECTION SPECIFICATION DOWNLOAD Command.
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD _type 4 bits 0x3 MF DETECTION type
- --------------------------------------------------------------------------------
CMD _subtype 4 bits 0x0 Collection Specification Download
- --------------------------------------------------------------------------------
CMD _channel 0 bytes - Command is not channel specific
- --------------------------------------------------------------------------------
CMD _length 1 byte 0x0F Length of this message
- --------------------------------------------------------------------------------
CMD _params 13 bytes * All Collection Specification values
- --------------------------------------------------------------------------------
Table 7-15: MF/COLLECTION SPECIFICATION DOWNLOAD (0x30) Command
Table 7-16 shows the format of the CMD _params section of this command. See
Section 5.2.1 for field definitions.
---------------------------------------------------------------------------
Bits
-------------==============================================================
(1 byte) 7 6 5 4 3 2 1 0
=============--------------------------------------------------------------
0 Collection Spec ID
--------------------------------------------------------------
1 TT | TD | K
--------------------------------------------------------------
2 | N
--------------------------------------------------------------
3 | MIN_POWER
--------------------------------------------------------------
4 MIN_MAKE
--------------------------------------------------------------
5 MIN_BREAK
--------------------------------------------------------------
6 CW
--------------------------------------------------------------
7 IDTO
--------------------------------------------------------------
8 PSC
--------------------------------------------------------------
9 FDTO
--------------------------------------------------------------
10 TDTO
--------------------------------------------------------------
11 ISTT | IS
--------------------------------------------------------------
12 ED | CD
---------------------------------------------------------------------------
Table 7-16: CMD _params section format for MF/COLLECTION SPECIFICATION
DOWNLOAD (0x30) Command
-73-
<PAGE> 96
EVP-SRM (DSP) Software Design Specification 74
- ------------------------------------------------------------------------
7.2.4.2 MF/SETUP (0x31)
The MF/SETUP command is used to configure a given channel and to start executing
MF detection on that channel. The format of the MF/SETUP command follows:
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD _type 4 bits 0x3 MF
CMD _subtype 4 bits 0x1 SETUP
CMD _channel 1 byte 0x01 -0x3F Length of this message
CMD _length 1 byte *see below *see below
CMD _params *see below *see below All Collection Specification values
Table 7-17: MF/SETUP (0x31) Command Format
The CMD _params section of the MF/SETUP command consists of an execution flag
(EX), default collection spec identifier to use (ID), and the number of digits
to collect (N). Optionally, the CMD _params section contains other parameters.
These optional parameters each have their own parameter ID (1 byte long), and
parameter field (1 byte long). The format of the CMD _params section for this
command follows:
-------------------------------------------------------------------
Byte Bits
===================================================================
7 6 5 4 3 2 1 0
-------------------------------------------------------------------
0 EX |
-------------------------------------------------------------------
1 | N
-------------------------------------------------------------------
2+ optional param ID / param paris
-------------------------------------------------------------------
Table 7-18
o If the EX bit is 1, then execution is to start after processing
this command. Otherwise, the DSP will wait for an execution
command separately, and maintain the configuration specified in
this command.
o If the ID field is 0, use the previous configuration. If there is
no previous configuration, then the DSP will generate an error
status. If the ID field is nonzero, then configure this channel
with this ID's default collection spec.
o N ranges from 1 to 40. The DSP will generate an error status if N
is outside this range.
-74-
<PAGE> 97
EVP-SRM (DSP) Software Design Specification 75
- ------------------------------------------------------------------------
If optional parameters are included in the MFR1/SETUP command, then the DSP will
update the working copy of the collection spec for this channel with the
parameters.
The allowable values for each optional parameter follows:
<TABLE>
- ------------------------------------------------------------------------------------------------
<CAPTION>
16-bit words per Number of Memory
Section ID numbering Specification Specifications Usage
================================================================================================
<S> <C> <C> <C> <C>
Simple Tone Specifications 0 to 511 10 512 5120
- ------------------------------------------------------------------------------------------------
Special Case Templates 512 to 575 10 64 640
- ------------------------------------------------------------------------------------------------
Special Tone Specifications 576 to 640 5 64 320
- ------------------------------------------------------------------------------------------------
Tone Groups 0 to 63 64 64 4096
- ------------------------------------------------------------------------------------------------
</TABLE>
Table 7-19: Parameter ID/Parameter definitions for MF/SETUP command
Again, see Section 5.2.1 for field definitions.
7.2.4.3 MF/EXECUTE (0x33)
The MF/EXECUTE command is used to change the execution status only for a given
channel. The format of the MF/EXECUTE command follows:
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD _type 4 bits 0x3 MF DETECTION type
CMD _subtype 4 bits 0x3 EXECUTE subtype
CMD _channel 1 byte 0x01 - 0x3F Channel
CMD _length 1 byte 0x04 Length of this message = 4 bytes
CMD _params 1 byte 0x00, 0x01, or 0x02 START, STOP, ABORT
Table 7-20: MF/EXECUTE (0x33) Command Format
o If CMD _params = 0x00 (START), the DSP will start MF collection
with the current configuration on the channel specified by CMD
_channel.
o If CMD _params = 0x01 (STOP), the DSP will stop MF collection on
the channel specified by CMD _channel, and report any previously
unreported digits detected.
o If CMD _params = 0x02 (ABORT), the DSP will stop MF collection on
the channels specified by CMD _channel, and discard any previously
unreported digits detected.
-75-
<PAGE> 98
EVP-SRM (DSP) Software Design Specification 76
- ------------------------------------------------------------------------
7.2.5 CP Detection (0x4) Commands
For the Call Progress CMD _type, the values for CMD _subtype are as follows:
1. CMD _subtype = SETUP (0x0)
2. CMD _subtype = EXECUTION (0x1)
3. CMD _subtype = COLLECTION SPEC DOWNLOAD (0x2)
4. CMD _subtype = NORMAL CP TONE SPEC DOWNLOAD (0x3)
5. CMD _subtype = SIT CP TONE SPEC DOWNLOAD (0x4)
6. CMD _subtype = TONE GROUP DOWNLOAD (0x5)
The format of each CMD _subtype follows.
7.2.5.1 CP Detection/SETUP (0x40)
The CP Detection/SETUP command is used to configure a given channel and to start
executing CP Detection on that channel. The format of this command is as
follows:
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD _type 4 bits 0x4 CP Detection
CMD _subtype 4 bits 0x0 SETUP
CMD _channel 1 byte 0x01 - 0x3F Channel
CMD _length 1 byte 6, 8, 10, 12, or 14 Message Length
CMD _params 1 byte *see below *see below
Table 7-21: CP Detection /SETUP (0x40) Command Format
The CMD _params section of the CP Detection/SETUP command has the following
format:
Parameter(s), bit locations
----------------- ---------------------------------------------------------
Word 7 6 5 4 3 2 1 0
----------------- ---------------------------------------------------------
1 EX
---------------------------------------------------------
2 CP Collection Spec ID
---------------------------------------------------------
3 CP Tone Group ID
---------------------------------------------------------
4 Optional Param ID 1
---------------------------------------------------------
-76-
<PAGE> 99
EVP-SRM (DSP) Software Design Specification 77
- ------------------------------------------------------------------------
---------------------------------------------------------
5 Param 1
---------------------------------------------------------
6 Optional Param ID 2
---------------------------------------------------------
7 Param 2
---------------------------------------------------------
8 Optional Param ID 3
---------------------------------------------------------
9 Param 3
---------------------------------------------------------
10 Optional Param ID 4
---------------------------------------------------------
11 Param 4
---------------------------------------------------------------------------
Table 7-22: CP Detection /SETUP CMD _params section
o Word 1: EX is an execution flag:
EX = 1: start executing CP Detection after configuring on this
channel
EX = 0: configure this channel, but do not start executing
o Word 2: CP Collection Spec ID:
CP Collection Spec ID nonzero: This is the new default
collection spec. All working values are reinitialized to
these defaults. CP Collection Speci ID = 0, then error. At
startup, default is set to 0.
o Word 3: CP Tone Group ID: This is the tone group to use on this
channel.
o Word 4-11:
These are the optional parameters, which allow for
modification of the working copy of the collection
specification. Table 7-23 shows the format of each optional
Parameter ID/Parameter pair.
- ----------------------------------------- --------------------------------------
Parameter ID Parameter
- ----------------------------------------- --------------------------------------
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
- ----------------------------------------- --------------------------------------
0 0 P
- ----------------------------------------- --------------------------------------
0 1 PSC
- ----------------------------------------- --------------------------------------
1 0 TC
- ----------------------------------------- --------------------------------------
1 1 FDTO
- ----------------------------------------- --------------------------------------
Table 7-23: CP Detection/SETUP Param ID/Param values
7.2.5.2 CP Detection/EXECUTE (0x41)
The CP Detection/EXECUTE command is used to change the execution status only for
a given channel. The format of the CP Detection/EXECUTE command follows:
-77-
<PAGE> 100
EVP-SRM (DSP) Software Design Specification 78
- ------------------------------------------------------------------------
- -------------------------------------------------------------------------------
Field Length Value Description
- -------------------------------------------------------------------------------
CMD _type 4 bits 0x4 CP Detection
CMD _subtype 4 bits 0x1 EXECUTE
CMD _channel 1 byte 0x01 - 0x3F Channel
CMD _length 1 byte 0x04 Message Length
CMD _params 1 byte 0x00 or 0x01 START (0) OR STOP (1)
Table 7-24: CP Detection/EXECUTE (0x42) Command Format
o If CMD _params = 0x01 (START), the DSP will start CP Detection
with the current configuration on the channel specified by CMD
_channel.
o If CMD _params = 0x01 (STOP), the DSP will stop CP Detection on
the channel specified by CMD _channel.
7.2.5.3 CP Detect/COLLECTION SPEC DOWNLOAD (0x42)
For this command, the CMD _params field contains an ID of the Collection
Specification, followed by all CP Detection Collection Specification parameters.
Upon receipt of this command, the DSP will copy the values to the default CP
Detect Collection Specification with this ID.
Table 7-25 shows the format of the CP Detection/COLLECTION SPEC DOWNLOAD
command.
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD _type 4 bits 0x4 CP Detect
CMD _subtype 4 bits 0x2 Collection Spec Download
CMD _channel 1 byte 0x00 Command is not channel specific
CMD _length 1 byte 0x06 Length of this message
CMD _params 3 bytes * All Collection Specification values
Table 7-25: CP Detect/COLLECTION SPECIFICATION DOWNLOAD (0x42)
Command Format
Shows the format of the CMD _params section of this command.
-78-
<PAGE> 101
EVP-SRM (DSP) Software Design Specification 79
- ------------------------------------------------------------------------
-----------------------------------------------------------------------
Bits
---------------- ======================================================
Byte 7 6 5 4 3 2 1 0
------------------------------------------------------
1 Collection Spec ID
------------------------------------------------------
2 P PSC
------------------------------------------------------
3 TC FDTO
-----------------------------------------------------------------------
Table 7-26: CP Detect/COLLECTION SPECIFICATION DOWNLOAD Command CMD _params
Section Format
7.2.5.4 CP Detection NORMAL CP TONE SPEC DOWNLOAD (0x43)
For this command, the CMD _params field contains an ID of the Normal CP Tone
Specification, followed by all fields in the Normal CP tone Specification. Upon
receipt of this command, the DSP will copy the values to the default Normal CP
Tone Specification with this ID, then do any preprocessing needed to enable
detection of this tone.
shows the format of the CP Detection NORMAL CP TONE SPEC DOWNLOAD command.
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD _type 4 bits 0x4 CP Detect
- --------------------------------------------------------------------------------
CMD _subtype 4 bits 0x3 Normal CP Tone Spec download
- --------------------------------------------------------------------------------
CMD _channel 1 byte 0x00 Command is not channel specific
- --------------------------------------------------------------------------------
CMD _length 1 byte 0x2F Length of this message
- --------------------------------------------------------------------------------
CMD _params 44 bytes * Tone Specification ID and values
- --------------------------------------------------------------------------------
Table 7-27: CP Detect/NORMAL CP TONE SPEC DOWNLOAD (0x43)
Command Format
[TBD] Need to add format of CMD _params section for this command
7.2.5.5 CP Detection SIT CP TONE SPEC DOWNLOAD (0x44)
For this command, the CMD _params field contains an ID of the SIT CP Tone
Specification, followed by all fields in the SIT CP Tone Specification. Upon
receipt of this command, the DSP will copy the values to the default SIT CP Tone
Specification with this ID, then do any preprocessing needed to enable detection
of this tone.
-79-
<PAGE> 102
EVP-SRM (DSP) Software Design Specification 80
- ------------------------------------------------------------------------
shows the format of the CP Detect/ SIT CP TONE SPEC DOWNLOAD Command.
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD _type 4 bits 0x4 CP Detect
- --------------------------------------------------------------------------------
CMD _subtype 4 bits 0x4 SIT CP Tone Spec download
- --------------------------------------------------------------------------------
CMD _channel 1 byte 0x00 Command is not channel specific
- --------------------------------------------------------------------------------
CMD _length 1 byte 0x2F Length of this message
- --------------------------------------------------------------------------------
CMD _params 44 bytes * Tone Specification ID and values
- --------------------------------------------------------------------------------
Table 7-28: CP Detect/SIT CP TONE SPEC DOWNLOAD (0x44) Command Format
[TBD] Need to add format of CMD _params section for this command
7.2.5.6 CP Detection TONE GROUP DOWNLOAD (0x45)
For this command, the CMD _params field contains an ID of the Tone Group,
followed by all fields in the Tone Group. Upon receipt of this command, the DSP
will copy the values to the Tone Group with this ID, then do any preprocessing
needed to enable detection of tones in this group.
shows the format of the CP Detect/TONE GROUP DOWNLOAD (0x45) command.
Table 7-29: CP Detect/TONE GROUP DOWNLOAD (0x45)
Command Format
[TBD] Need to add format of CMD _params section for this command
7.2.6 Tone Generation (0x5) Commands
For the Tone Generation CMD _type, the values for CMD _subtype are as follows:
1. CMD _subtype = TRANSMIT TONE (0x0)
2. CMD _subtype = OUTPULSE DIGITS (0x1)
3. CMD _subtype = STOP EXECUTION (0x2)
4. CMD _subtype = DOWNLOAD SIMPLE TONE SPEC (0x3)
5. CMD _subtype = DOWNLOAD SPECIAL CASE TEMPLATE (0x4)
6. CMD _subtype = DOWNLOAD SPECIAL TONE SPEC (0x5)
-80-
<PAGE> 103
EVP-SRM (DSP) Software Design Specification 81
- ------------------------------------------------------------------------
7. CMD _subtype = DOWNLOAD USER-DEFINED TONE GROUP (0x6)
7.2.6.1 Tone Generation TRANSMIT TONE (0x50)
The Tone Generation TRANSMIT TONE command is used to generate singular tones (as
opposed to outpulsing a series of tones). When the DSP processes this command,
it will begin generating the tone specified in the command. Upon completion of
the tone (if not infinite duration), the DSP will generate silence to the
channel. The format of this command is shown below.
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD _type 4 bits 0x5 Tone Generation
- --------------------------------------------------------------------------------
CMD _subtype 4 bits 0x0 Transmit Tone
- --------------------------------------------------------------------------------
CMD _channel 1 byte 1-63 Channel
- --------------------------------------------------------------------------------
CMD _length 1 byte 5 Length of this message
- --------------------------------------------------------------------------------
CMD _params 2 bytes 1-64 Tone Group ID
1-64 Tone Index
- --------------------------------------------------------------------------------
Table 7-30: Tone Generation TRANSMIT TONE (0x50) Command Format
7.2.6.2 Tone Generation OUTPULSE DIGITS (0x51)
The Tone Generation OUTPULSE DIGITS command is used to generate a series of
tones from one Tone Group. When the DSP processes this command, it will begin
outpulsing the tones specified in the command. Upon completion of the tones, the
DSP will generate silence to the channel. If the Report Completion flag (RC) is
set, the DSP will also report tone completion.
If the Tone Group specified in this command is 0-3 (special DTMF, MFR1, MFR2-
Forwards and MFR2-Backwards Tone Groups), then the tones are specified in 4 bit
numbers (0 to 15). Otherwise, they are specified in 8 bit numbers. The format of
this command is shown below.
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD _type 4 bits 0x5 Tone Generation
- --------------------------------------------------------------------------------
CMD _subtype 4 bits 0x1 Outpulse Digits
- --------------------------------------------------------------------------------
CMD _channel 1 byte 1-63 Channel
- --------------------------------------------------------------------------------
CMD _length 1 byte *see below Length of this message
- --------------------------------------------------------------------------------
CMD _params *see below *see below *see below
- --------------------------------------------------------------------------------
Table 7-31: Tone Generation OUTPULSE DIGITS (0x50) Command Format
-81-
<PAGE> 104
EVP-SRM (DSP) SOFTWARE Design Specification 82
- ------------------------------------------------------------------------
The format of the CMD _params section for this command is shown below.
----------------------------------------------------------------------
(DTMF, MFR1, MFR2 Tone Groups)
----------------------------------------------------------------------
Byte 7 6 5 4 3 2 1 0
======================================================================
1 Tone Group = 0, 1, 2, or 3
-------------------------------------------------------
2 RC Number of Digital (1 to 40)
-------------------------------------------------------
3 Tmake in ms (if 0, default = 50 ms)
-------------------------------------------------------
4 Tbreak in ms (if 0, default = 50 ms)
-------------------------------------------------------
5 digit 1 digit 2
-------------------------------------------------------
6 digit 3 digit 4
7 - -
- -
<=24 - -
---------------------------- --------------------------
<=44
--------------
-------------------------------------------------------------
(User-Defined Tone Groups)
-------------------------------------------------------------
7 6 5 4 3 2 1 0
-------------------------------------------------------------
Tone Group: 4 to 63
-------------------------------------------------------------
RC | Number of Digits (1 to 40)
------- -----------------------------------------------------
Tmake in ms (if 0, default = 50 ms)
-------------------------------------------------------------
Tbreak in ms (if o, default = 50 ms)
-------------------------------------------------------------
digit 1
--------------- ---------------------------------------------
digit 2
--------------- ---------------------------------------------
digit 3
--------------- ---------------------------------------------
-
--------------- ---------------------------------------------
-
--------------- ---------------------------------------------
-
--------------- ---------------------------------------------
-
-------------------------------------------------------------
Table 7-32: CMD _params section format for
Tone Generation/OUTPULSE DIGITS (0x51) Command
7.2.6.3 Tone Generation STOP EXECUTION (0x52)
The Tone Generation STOP EXECUTION command is used to cease tone generation.
When it processes this command, the DSP will transition to the IDLE state on the
given channel. The format of this command is shown below.
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD _type 4 bits 0x5 Tone Generation
- --------------------------------------------------------------------------------
CMD _subtype 4 bits 0x2 Stop Execution
- --------------------------------------------------------------------------------
CMD _channel 1 byte 1-63 Channel
- --------------------------------------------------------------------------------
CMD _length 1 byte 3 Length of this message
- --------------------------------------------------------------------------------
CMD _params 0 bytes - No parameters
- --------------------------------------------------------------------------------
Table 7-33: Tone Generation STOP EXECUTION (0x52) Command Format
7.2.6.4 Tone Generation DOWNLOAD SIMPLE TONE SPEC (0x53)
The Tone Generation DOWNLOAD SIMPLE TONE SPEC command is used to update Simple
Tone Specifications. When it processes this command, the DSP will copy the
parameters to the location of the Simple Tone Spec with the commanded ID.
The format of this command is shown below.
-82-
<PAGE> 105
EVP-SRM (DSP) Software Design Specification 83
- ------------------------------------------------------------------------
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD _type 4 bits 0x5 Tone Generation
- --------------------------------------------------------------------------------
CMD _subtype 4 bits 0x3 Download Simple Tone Spec
- --------------------------------------------------------------------------------
CMD _channel 0 bytes - No Channel
- --------------------------------------------------------------------------------
CMD _length 1 byte 24 Length of this message
- --------------------------------------------------------------------------------
CMD _params 22 bytes - Simple Tone Spec ID and values
- --------------------------------------------------------------------------------
Table 7-34: Tone Generation DOWNLOAD SIMPLE TONE SPEC (0x53) Command
[TBD] need to add format of CMD _params section for this command
-83-
<PAGE> 106
EVP-SRM (DSP) Software Design Specification 84
- ------------------------------------------------------------------------
7.2.6.6 Tone Generation DOWNLOAD SPECIAL TONE SPEC (0x52)
The Tone Generation DOWNLOAD SPECIAL TONE SPEC command is used to update Special
Tone Specifications. When it processes this command, the DSP will copy the
parameters to the location of the Special Tone Specification with the commanded
ID.
The format of this command is shown below.
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD type 4 bits 0x5 Tone Generation
- --------------------------------------------------------------------------------
CMD subtype 4 bits 0x5 Download Special Tone Spec
- --------------------------------------------------------------------------------
CMD channel 0 bytes - No Channel
- --------------------------------------------------------------------------------
CMD length 1 byte 12 Length of this message
- --------------------------------------------------------------------------------
CMD _params 10 bytes - Special Tone Spec ID and values
- --------------------------------------------------------------------------------
Table 7-36: Tone Generation DOWNLOAD SPECIAL TONE SPECIFICATION
(0x55)
Command Format
[TBD] need to add format of CMD_params section for this command
7.2.6.7 TONE GENERATION DOWNLOAD USER-DEFINED TONE GROUP (0X56)
The tone Generation DOWNLOAD USER-DEFINED TONE GROUP command is used to update
User-defined tone Groups. When it processes this command, the DSP will copy the
parameters to the location of the User-defined Tone Group with this commanded
ID.
The format of this command is shown below.
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD type 4 bits 0x5 Tone Generation
- --------------------------------------------------------------------------------
CMD Subtype 4 bits 0x6 Download User-defined Tone Group
- --------------------------------------------------------------------------------
CMD channel 0 bytes - No Channel
- --------------------------------------------------------------------------------
-84-
<PAGE> 107
EVP-SRM (DSP) Software Design Specification 85
- ------------------------------------------------------------------------
- --------------------------------------------------------------------------------
CMD length 1 byte 132 Length of this message
- --------------------------------------------------------------------------------
CMD _params 130 - User-defined tone Group ID and values
- --------------------------------------------------------------------------------
Table 7-37: Tone Generation DOWNLOAD USER-DEFINED TONE GROUP (0x56)
Command Format
[TBD] need to add format of CMD-params section for this command
7.2.7 MFcR2 Signalling (0x6) Commands
For the MF cR2 CMD _type, the values for CMD _subtype are as follows:
1. CMD_subtype = COLLECTION SPECIFICATION DOWNLOAD (0x0)
2. CMD_subtype = SETUP (0x1)
3. CMD_subtype = EXECUTION (0x2)
The format of each command follows:
7.2.7.1 MFCR2/COLLECTION SPECIFICATION DOWNLOAD (0X60)
For this command, the CMD _params field contains an ID of the Collection
Specification, followed by all MF Collection Specification parameters. Upon
receipt of this command, the DSP will copy the values to the default MF
Collection Specification with this ID.
Table 7-38 shows the format of the MFcR2/COLLECTION SPECIFICATION DOWNLOAD
command.
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD type 4 bits 0x6 MFcR2 Signalling
- --------------------------------------------------------------------------------
CMD subtype 4 bits 0x0 Collection Specification Download
- --------------------------------------------------------------------------------
CMD channel 0 bytes - Command is not channel specific
- --------------------------------------------------------------------------------
CMD length 1 byte 0x0F Length of this message
- --------------------------------------------------------------------------------
CMD _params 13 bytes * All Collection Specification values
- --------------------------------------------------------------------------------
Table 7-38: MFcR2/COLLECTION SPECIFICATION DOWNLOAD (0x60) Command
-85-
<PAGE> 108
EVP-SRM (DSP) Software Design Specification 86
- ------------------------------------------------------------------------
Table 7-39 shows the format of the CMD _params section of this command. See
Sections 5.2.1 and 5.3.1 for field definitions.
- --------------------------------------------------------------------------------
Bits
- --------------------------------------------------------------------------------
Byte 7 6 5 4 3 2 1 0
- --------------------------------------------------------------------------------
0 Collection Spec ID
- --------------------------------------------------------------------------------
1 TT TD k
- --------------------------------------------------------------------------------
2 N
- --------------------------------------------------------------------------------
3 MIN POWER
- --------------------------------------------------------------------------------
4 MIN_MAKE
- --------------------------------------------------------------------------------
5 MIN_BRAKE
- --------------------------------------------------------------------------------
6 CW
- --------------------------------------------------------------------------------
7 IDTO
- --------------------------------------------------------------------------------
8 PSC
- --------------------------------------------------------------------------------
9 FDTO
- --------------------------------------------------------------------------------
10 TDTO
- --------------------------------------------------------------------------------
11 ISTT IS
- --------------------------------------------------------------------------------
12 ED CD
- --------------------------------------------------------------------------------
Table 7-39: CMD_params section format for MFcR2 / COLLECTION
SPECIFICATION
DOWNLOAD (0x30) Command
7.2.7.2 MFcR2/SETUP (0x61)
The MFcR2/SETUP command is used to configure a given channel and to start
executing MFcR2 signalling on that channel. The format of the MFcR2/SETUP
command follows:
-86-
<PAGE> 109
EVP-SRM (DSP) Software Design Specification 87
- ------------------------------------------------------------------------
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD type 4 bits 0x6 MFcR2
- --------------------------------------------------------------------------------
CMD subtype 4 bits 0x1 SETUP
- --------------------------------------------------------------------------------
CMD channel 0 byte 0x01 - 0x3F Channel
- --------------------------------------------------------------------------------
CMD length 1 byte *see below Length of this message
- --------------------------------------------------------------------------------
CMD_params *see below *see below *see below
- --------------------------------------------------------------------------------
Table 7-40: MFcR2/SETUP (0x61) Command Format
The CMD_params section of the MFcR2/SETUP command consists of the default
collection spec identifier to use (ID, and the number of digits to collect (N).
Optionally, the CMD _params section contains other parameters. These optional
parameters each have their own parameter ID (1 byte long), and parameter field
(1 byte long). The format of the CMD _params section for this command follows:
- --------------------------------------------------------------------------------
Bits
- --------------------------------------------------------------------------------
Byte 7 6 5 4 3 2 1 0
- --------------------------------------------------------------------------------
0 EX ID
- --------------------------------------------------------------------------------
1 N
- --------------------------------------------------------------------------------
2+ optional param ID / param pairs
- --------------------------------------------------------------------------------
Table 7-41
o The EX bit is disabled for MFcR2 signalling. This is because there is
other information that is needed before signalling can begin. The DSP
will wait for an execute command separately, and maintain the
configuration specified in this command.
o If the ID field is 0, use the previous configuration. If there is no
previous configuration, then the DSP will generate an error status. If
the ID field is nonzero, then configure this channel with this ID's
default collection spec.
-87-
<PAGE> 110
EVP-SRM (DSP) Software Design Specification 88
- ------------------------------------------------------------------------
o N ranges from 1 to 40. The DSP will generate an error status if N is
outside this range.
If optional parameters are included in the MFcR2/SETUP command, then the DSP
will update the working copy of the collection spec for this channel with the
parameters. The allowable values for each optional parameter follows:
- --------------------------------------------------------------------------------
Bits
- --------------------------------------------------------------------------------
Byte 7 6 5 4 3 2 1 0
- --------------------------------------------------------------------------------
0 Collection Spec ID
- --------------------------------------------------------------------------------
1 TT TD k
- --------------------------------------------------------------------------------
2 N
- --------------------------------------------------------------------------------
3 MIN POWER
- --------------------------------------------------------------------------------
4 MIN_MAKE
- --------------------------------------------------------------------------------
5 MIN_BRAKE
- --------------------------------------------------------------------------------
6 CW
- --------------------------------------------------------------------------------
7 IDTO
- --------------------------------------------------------------------------------
8 PSC
- --------------------------------------------------------------------------------
9 FDTO
- --------------------------------------------------------------------------------
10 TDTO
- --------------------------------------------------------------------------------
11 ISTT IS
- --------------------------------------------------------------------------------
12 ED CD
- --------------------------------------------------------------------------------
Table 7-42: Parameter ID/Parameter definitions for MFcR2/SETUP command
Again, see Sections 5.2.1 and MF Collection Specifications for field
definitions.
7.2.7.3 MFCR2/EXECUTE (0X63)
-88-
<PAGE> 111
EVP-SRM (DSP) Software Design Specification 89
- ------------------------------------------------------------------------
The MFcR2/EXECUTE command is used to start executing either forwards or
backwards compelled signalling for a given channel. If this is a start execution
command, then this command also contains other information needed to execute.
The format of the MF/EXECUTE command follows:
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
CMD type 4 bits 0x6 MFcR2 Signalling
- --------------------------------------------------------------------------------
CMD subtype 4 bits 0x3 EXECUTE
- --------------------------------------------------------------------------------
CMD channel 1 byte 0x01 - 0x3F Channel
- --------------------------------------------------------------------------------
CMD length 1 byte *see below *see below
- --------------------------------------------------------------------------------
CMD _params 1 byte *see below *see below
- --------------------------------------------------------------------------------
Table 7-40: MFcR2/SETUP (0x61) Command Format
For this CMD type / CMD _subtype, the CMD_params field format is defined by the
first byte in the CMD _params section. The defined values are as follows:
o CMD_params = 0x00: Start executing Forward Signalling. Additional data is
present in the CMD_params section for this command -- see below.
o CMD_params = 0x01: Start executing Backward Signalling. No other
information is needed. CMD_params is 1 btye long.
o CMD_params = 0x02: Stop executing MFcR2 signalling. No other information
is needed. CMD_params is 1 byte long.
o CMD_params = 0x03: Reset execution of MFcR2 signalling. No other
information is needed. CMD_params is 1 byte long.
Each of the different formats for CMD_params are defined below:
7.2.7.3.1 MFcR2/EXECUTE - Start Forward Signalling
For this command, the CMD_params section contains the digit strings that
will be requested by the backwards register. The CMD_params section has
the following format:
-89-
<PAGE> 112
EVP-SRM (DSP) Software Design Specification 90
- ------------------------------------------------------------------------
- --------------------------------------------------------------------------------
Bits
- --------------------------------------------------------------------------------
Byte 7 6 5 4 3 2 1 0
- --------------------------------------------------------------------------------
0 0 0 0 0 0 0 0 0
- --------------------------------------------------------------------------------
2 Number of digit strings
- --------------------------------------------------------------------------------
3 Length of first string
- --------------------------------------------------------------------------------
4 first string of digits - 4 bits each
- -------- (Round up to the nearest byte)
5
- --------------------------------------------------------------------------------
* Length of second string
- --------------------------------------------------------------------------------
* Second string of digits - 4 bits each
- --------
*
- --------------------------------------------------------------------------------
Length of next string
- --------------------------------------------------------------------------------
<=31 Last string of digits - 4 bits each
- --------------------------------------------------------------------------------
Table 7-44: CMD_params format for MFcR2/EXECUTE -- Start Forward Signalling
Command
7.2.7.3.2 MFcR2/EXECUTE - Start Backward Signalling
For this command, the CMD_params section contains the backward signalling
flag. The number of digits to collect, next digit, and cancel digit
information is all contained in the collection specification.
- --------------------------------------------------------------------------------
Bits
- --------------------------------------------------------------------------------
Byte 7 6 5 4 3 2 1 0
- --------------------------------------------------------------------------------
0 0 0 0 0 0 0 0 1
- --------------------------------------------------------------------------------
Table 7-45: CMD_params format for MFcR2/EXECUTE -- Start Backward Signalling
Command
7.2.7.3.3 MFcR2/EXECUTE - Stop MFcR2 Signalling
-90-
<PAGE> 113
EVP-SRM (DSP) Software Design Specification 91
- ------------------------------------------------------------------------
- --------------------------------------------------------------------------------
Bits
- --------------------------------------------------------------------------------
Byte 7 6 5 4 3 2 1 0
- --------------------------------------------------------------------------------
0 0 0 0 0 0 0 1 0
- --------------------------------------------------------------------------------
Table 7-46: CMD_params format for MFcR2/EXECUTE -- Stop MFcR2 Signalling
Command
7.2.7.3.4 MFcR2/EXECUTE - Reset MFcR2 Signalling
For this command, the CMD_params section contains the reset flag. Upon
receipt of this command, the DSP will cease MFcR2 signalling, discard any
collected digits, and restart MFcR2 signalling.
-91-
<PAGE> 114
EVP-SRM (DSP) Software Design Specification 92
- ------------------------------------------------------------------------
- --------------------------------------------------------------------------------
Bits
- --------------------------------------------------------------------------------
Byte 7 6 5 4 3 2 1 0
- --------------------------------------------------------------------------------
0 0 0 0 0 0 0 1 1
- --------------------------------------------------------------------------------
Table 7-47: CMD_params format for MFcR2/EXECUTE -- Reset <FcR2 Signalling
Command
8. Status Messages
8.1 Status String Format
The DSPs send status to the Core Processor using the first timeslot on the first
buffered serial port using point-to-point HDLC protocol. Each status message
consists of a variable length status string, which is composed of the following
fields: a status type (STAT_type), status subtype (STAT-subtype), the channel
number (STAT_channel), the message length in bytes (STAT_length), and status
parameters (STAT_params).
o The STAT_type and STAT_subtype fields are each 4 bits long, and combine
for the first byte of all status messages. STAT_type is in the high
nibble.
o STAT_channel is one byte long for status messages that are channel
specific; for status messages that have no associates channel, the
STAT_channel field is 0 bytes long (not present).
o STAT_length is one byte long for all status messages.
o The Stat_params field's length is variable, in one byte increments. Note
that for certain STAT_type/STAT_subtype combinations, the STAT_params
field is 0 bytes long (not present).
The status string shall have one of the following structures, depending on
whether the STAT_length field is present:
-92-
<PAGE> 115
EVP-SRM (DSP) Software Design Specification 93
- ------------------------------------------------------------------------
-----------------------------------------------------
1 STAT_type STAT_subtype
-----------------------------------------------------
2 STAT_channel
-----------------------------------------------------
3 STAT_length
-----------------------------------------------------
4+ STAT-params
-----------------------------------------------------
Table 8-1: Status structure when STAT_channel is present
-----------------------------------------------------
1 STAT_type STAT_subtype
-----------------------------------------------------
2 STAT_length
-----------------------------------------------------
3+ STAT-params
-----------------------------------------------------
Table 8-2: Status structure when STAT_channel is present
8.2 Status Message Definitions
Table 8-3 shows the legal values for the STAT_type field.
- --------------------------------------------------------------------------------
STAT_type(HEX) Function Description
- --------------------------------------------------------------------------------
0x0 IDLE Confirmation of entering IDLE state
0x1 Diagnostic Test Confirmation/results of diagnostics
0x2 DTMF Detection DTMF detection status
0x3 MFR1 Detection MFR1 detection status
0x4 CP Detection CP detection status
0x5 Tone Generation Tone generation status
0x6 MFcR2 Signalling MFcR2 signalling status
0x7 - 0xF Not Used Reserved for future expansion
- --------------------------------------------------------------------------------
Table 8-3: Legal STAT_type values.
Defined values for the STAT_subtype field are dependent on the STAT-type
function. Similarly, the defined values for the STAT_params field are dependent
on the STAT_type and STAT_subtype values. the following subsections define all
legal combinations STAT_subtype and STAT_params for each STAT_type.
8.2.1 IDLE (0x0) Status
-93-
<PAGE> 116
EVP-SRM (DSP) Software Design Specification 94
- ------------------------------------------------------------------------
Table 8-4 describes the meanings of all IDLE status messages. STAT_subtype
contains the channel number of the channel that has entered the IDLE state (0
for all channels).
- --------------------------------------------------------------------------------
Field Length Value Description
- --------------------------------------------------------------------------------
STAT type 4 bits 0x0 IDLE type
- --------------------------------------------------------------------------------
STAT subtype 4 bits 0x00 - 0x3F Channel that entered IDLE state (0 = all
channels
- --------------------------------------------------------------------------------
STAT channel 0 bytes - Not present (channel is in STAT subtype
field)
- --------------------------------------------------------------------------------
STAT length 1 byte 0x02 Length of this message
- --------------------------------------------------------------------------------
STAT _params 0 byte (none) Not present
- --------------------------------------------------------------------------------
Table 8-4: IDLE status
8.2.2 DIAGNOSTIC TEST Status
Table 8-5 describes the meanings of all DIAGNOSTIC TEST status messages.
- --------------------------------------------------------------------------------
STAT_type STAT_subtype STAT_params Description
- --------------------------------------------------------------------------------
0x1 0x0 TBD TBD
0x1 TBD TBD
0x2 TBD TBD
0x3 TBD TBD
. TBD .
0x3F TBD TBD
- --------------------------------------------------------------------------------
Table 8-5: DIAGNOSTIC TEST status
8.2.3 DTMP Detection (0x2) Status Messages
For the DTMF STAT_type, the values for STAT_subtype are as follows:
1. STAT_subtype=DIGIT Report (without times) (0x0)
2. STAT_subtype=DIGIT REPORT (with times) (0x1)
-94-
<PAGE> 117
EVP-SRM (DSP) Software Design Specification 95
- ------------------------------------------------------------------------
3. STAT_subtype=ERROR (0x2)
The format of each status message follows.
8.2.3.1 DTMF/DIGIT REPORT (WITHOUT TIMES) (0X20)
For this status message, the STAT_params field contains the event flags, the
number of digits detected, and the digits detected.
<TABLE>
<CAPTION>
Byte Field Value Description
========== =============== =================== ====================================
<S> <C> <C> <C>
1 type/subtype 0x20 DTFM/DIGIT REPORT (without times)
---------- --------------- ------------------- ------------------------------------
2 channel # 1-63 STAT_channel
---------- --------------- ------------------- ------------------------------------
3 length < = 24 STAT_length
---------- --------------- ------------------- ------------------------------------
4 parameters Event Flags *See below
---------- --------------- ------------------- ------------------------------------
5 Number of Digits n = 0 to 40
---------- --------------- ------------------- ------------------------------------
6 Digit 1/2 4 bits per digit
---------- --------------- ------------------- ------------------------------------
. Digit 3/4
---------- --------------- ------------------- ------------------------------------
. .
---------- --------------- ------------------- ------------------------------------
< = 25 Digit n-1/n
---------- --------------- ------------------- ------------------------------------
</TABLE>
Table 8-6
The event flags are defined as follows:
- --------------------------------------------------------------------------------
Bits
7 6 5 4 3 2 1 0
================================================================================
0 RA ED CD TDTO PSC IDTO FDTO
- --------------------------------------------------------------------------------
Table 8-7
o FDTO: First digit timeout occurred
o IDTO: Inter digit timeout occurred
o PSC: Permanent signal condition occurred
-95-
<PAGE> 118
EVP-SRM (DSP) Software Design Specification 96
- ------------------------------------------------------------------------
o TDTO: Total digit timeout occurred
o CD: Cancel digit detected
o ED: End digit detected
o RA: Resource Attached
8.2.3.2 DTMF/DIGIT REPORT (WITH TIMES) (0X21)
For this status message, the STAT_params field contains the event flags, the
number of digits detected, the digits detected, and the start and stop times for
the detected digits. Times will be reported in units of 1 ms, but will have a
granularity of 8 ms.
<TABLE>
<CAPTION>
Byte Field Value Description
========= ================ ==================== ============================================
<S> <C> <C> <C>
1 type/subtype 0x21 DTFM/DIGIT REPORT (with times)
- --------- ---------------- -------------------- --------------------------------------------
2 channel # 1-63 STAT_channel
- --------- ---------------- -------------------- --------------------------------------------
3 length < = 24 STAT_length
- --------- ---------------- -------------------- --------------------------------------------
4 parameters Event Flags *See below
- --------- ---------------- -------------------- --------------------------------------------
5 Number of Digits n = 0 to 40
- --------- ---------------- -------------------- --------------------------------------------
6 Digit 1/2 Digits 1 and 2; four bits per digit
- --------- ---------------- -------------------- --------------------------------------------
7 Make 1 (high byte) Duration
- --------- -------------------- --------------------------------------------
8 Make 1 (low byte)
- --------- -------------------- --------------------------------------------
9 Break 1 (high byte) Duration of ms of first interdigit silence
- --------- -------------------- --------------------------------------------
10 Break 1 (low byte)
- --------- -------------------- --------------------------------------------
. Make 2 (high byte) Duration of ms of digit 1
- --------- -------------------- --------------------------------------------
. Make 2 (low byte)
- --------- -------------------- --------------------------------------------
. Break 2 (high byte) Duration of ms in first interdigit silence
- --------- -------------------- --------------------------------------------
. Break 2 (low byte)
- --------- -------------------- --------------------------------------------
. Digit 3/4
- --------- -------------------- --------------------------------------------
. Make 3 (high byte)
- --------- ---------------- -------------------- --------------------------------------------
. .
- --------- ---------------- -------------------- --------------------------------------------
<=365 .
- --------- ---------------- -------------------- --------------------------------------------
</TABLE>
-96-
<PAGE> 119
EVP-SRM (DSP) Software Design Specification 97
- ------------------------------------------------------------------------
Table 8-8
8.2.3.3 DTMF/DIGIT ERROR (0X22)
For this status message, the STAT_params field contains the error type.
Byte Field Value Description
========= =============== ============== ===================================
1 type/subtype 0x22 DTFM/DIGIT REPORT (without times)
- --------- --------------- -------------- -----------------------------------
2 channel # 1-63 STAT_channel
- --------- --------------- -------------- -----------------------------------
3 length 4 STAT_length
- --------- --------------- -------------- -----------------------------------
4 parameters Error Code *See below
- --------- --------------- -------------- -----------------------------------
Table 8-9
Asdf add error codes
8.2.4 MF Detection (0x3) Status Messages
For the MF STAT_type, the values for STAT_subtype are as follows:
1. STAT_subtype = DIGIT REPORT (without times) (0x0)
2. STAT_subtype = DIGIT REPORT (with times) (0x1)
3. STAT_subtype = ERROR (0x3)
The format of each status message follows.
8.2.4.1 MF/DIGIT REPORT (WITHOUT TIMES) (0X30)
For this status message, the STAT_params field contains the event flags, the
number of digits detected, and the digits detected.
Byte Field Value Description
========= ============ ================== ====================================
1 type/subtype 0x30 DTFM/DIGIT REPORT (without times)
- --------- ------------ ------------------ ------------------------------------
2 channel # 1-63 STAT_channel
- --------- ------------ ------------------ ------------------------------------
3 length < = 24 STAT_length
- --------- ------------ ------------------ ------------------------------------
4 parameters Event Flags *See below
- --------- ------------ ------------------ ------------------------------------
5 Number of Digits n = 0 to 40
- --------- ------------ ------------------ ------------------------------------
6 Digit 1/2 4 bits per digit
- --------- ------------ ------------------ ------------------------------------
-97-
<PAGE> 120
EVP-SRM (DSP) Software Design Specification 98
- ------------------------------------------------------------------------
- --------- ------------ ------------------ ------------------------------------
. Digit 3/4
- --------- ------------ ------------------ ------------------------------------
. .
- --------- ------------ ------------------ ------------------------------------
<=25 Digit n-1/n
- --------------------------------------------------------------------------------
Table 8-10
The event flags are defined as follows:
-------------------------------------------
Bits
7 6 5 4 3 2 1 0
===========================================
0 RA ED CD TDTO PSC IDTO FDTO
-------------------------------------------
Table 8-11
o FDTO: First digit timeout occurred
o IDTO: Inter digit timeout occurred
o PSC: Permanent signal condition occurred
o TDTO: Total digit timeout occurred
o CD: Cancel digit detected
o ED: End digit detected
o RA: Resource Attached
8.2.4.2 MF/DIGIT REPORT (WITH TIMES) (0X31)
For this status message, the STAT_params field contains the event flags, the
number of digits detected, the digits detected, and the start and stop times for
the detected digits.
<TABLE>
<CAPTION>
Byte Field Value Description
=================================================================================================================
<S> <C> <C> <C>
1 type/subtype 0x21 MF/DIGIT REPORT (with times)
- -----------------------------------------------------------------------------------------------------------------
</TABLE>
-98-
<PAGE> 121
EVP-SRM (DSP) Software Design Specification 99
- ------------------------------------------------------------------------
<TABLE>
- -----------------------------------------------------------------------------------------------------------------
<S> <C> <C> <C>
2 channel # 1-63 STAT_channel
- ---------- --------------------- --------------------------- --------------------------------------------------
3 length < = 24 STAT_length
- ---------- --------------------- --------------------------- --------------------------------------------------
4 parameters Event Flags *See below
- ---------- --------------------- --------------------------- --------------------------------------------------
5 Number of Digits n = 0 to 40
- ---------- --------------------- --------------------------- --------------------------------------------------
6 Digit 1/2 Digits 1 and 2; four bits per digit
- ---------- --------------------- --------------------------- --------------------------------------------------
7 Make 1 (high byte) Duration in ms of digit 1
- ---------- --------------------------- --------------------------------------------------
8 Make 1 (low byte)
- ---------- --------------------------- --------------------------------------------------
9 Break 1 (high byte) Duration of ms of first interdigit silence
- ---------- --------------------------- --------------------------------------------------
10 Break 1 (low byte)
- ---------- --------------------------- --------------------------------------------------
. Make 2 (high byte) Duration of ms of digit 1
- ---------- --------------------------- --------------------------------------------------
. Make 2 (low byte)
- ---------- --------------------------- --------------------------------------------------
. Break 2 (high byte) Duration of ms in first interdigit silence
- ---------- --------------------------- --------------------------------------------------
. Break 2 (low byte)
- ---------- --------------------------- --------------------------------------------------
. Digit 3/4
- ---------- --------------------------- --------------------------------------------------
. Make 3 (high byte)
- ---------- --------------------- --------------------------- --------------------------------------------------
. .
- ---------- --------------------- --------------------------- --------------------------------------------------
<=365 .
- -----------------------------------------------------------------------------------------------------------------
</TABLE>
Table 8-12
8.2.4.3 MF/DIGIT ERROR (0X32)
For this status message, the STAT_params field contains the error type.
<TABLE>
<CAPTION>
Byte Field Value Description
=================================================================================================================
<S> <C> <C> <C>
1 type/subtype 0x32 MF/ERROR
- ---------- --------------------- --------------------------- --------------------------------------------------
2 channel # 1-63 STAT_channel
- ---------- --------------------- --------------------------- --------------------------------------------------
3 length 4 STAT_length
- ---------- --------------------- --------------------------- --------------------------------------------------
4 parameters Error Code *See below
- -----------------------------------------------------------------------------------------------------------------
</TABLE>
Table 8-13
-99-
<PAGE> 122
EVP-SRM (DSP) Software Design Specification 100
- ------------------------------------------------------------------------
Asdf add error codes
8.2.5 CP Detection (0x4) Status Messages
For the CP DETECTION STAT_type, the values for STAT_subtype are as follows:
1. STAT_subtype = TONE DETECTED (0x0)
2. STAT_subtype = EVENT (0x1)
3. STAT_subtype = ERROR (0x2)
The format of each status message follows.
8.2.5.1 CP DETECT/TONE DETECTED (0X40)
For this status message, the STAT_params field contains the return value for the
tone detected.
Byte Field Value Description
================================================================================
1 type/subtype 0x40 CP Detect/TONE DETECTED
- -------- --------------------- ---------------- ------------------------------
2 channel # 1-63 STAT_channel
- -------- --------------------- ---------------- ------------------------------
3 length < = 24 STAT_length
- -------- --------------------- ---------------- ------------------------------
4 parameters RET_VAL Return value for detected tone
- --------------------------------------------------------------------------------
Table 8-14
8.2.5.3 CP DETECT/EVENT (0X41)
For this status message, the STAT_params field contains the event flag mask.
Byte Field Value Description
================================================================================
1 type/subtype 0x41 CP Detect/EVENT
- -------- --------------------- ---------------- ------------------------------
2 channel # 1-63 STAT_channel
- -------- --------------------- ---------------- ------------------------------
3 length 4 STAT_length
- -------- --------------------- ---------------- ------------------------------
4 parameters Event Flag ID *See below
- --------------------------------------------------------------------------------
Table 8-15
The event flag ID values are defined as follows:
-100-
<PAGE> 123
EVP-SRM (DSP) Software Design Specification 101
- ------------------------------------------------------------------------
Event ID Description
0 PSC timeout flag
1 TDTO flag
2 Tone cessation flag
3 Resource attached
Table 8-16
8.2.5.3 CP DETECT/ERROR (0X42)
For this status message, the STAT_params field contains the event flag mask.
Byte Field Value Description
================================================================================
1 type/subtype 0x42 CP Detect/ERROR
- -------- --------------------- ------------------ ----------------------------
2 channel # 1-63 STAT_channel
- -------- --------------------- ------------------ ----------------------------
3 length 4 STAT_length
- -------- --------------------- ------------------ ----------------------------
4 parameters number of errors number of errors
- -------- --------------------- ------------------ ----------------------------
5 error ID
- -------- --------------------- ------------------ ----------------------------
6 <error value> .
- -------- --------------------- ------------------ ----------------------------
error ID .
- -------- --------------------- ------------------ ----------------------------
. .. .
- --------------------------------------------------------------------------------
Table 8-17
The error IDs and error values are defined as follows:
- --------------------------------------------------------------------------------
Error ID Length Error Name Error value
- --------------------------------------------------------------------------------
0x0 1 Collection spec does not exist <none>
- --------------------------------------------------------------------------------
0x1 2 Tone group does not exist <tone group ID>
- --------------------------------------------------------------------------------
0x2 2 Tone specification does not exist <tone spec ID>
- --------------------------------------------------------------------------------
0x3 1 Algorithm not configured <none>
- --------------------------------------------------------------------------------
0x4 1 Max channels exceeded <none>
- --------------------------------------------------------------------------------
-101-
<PAGE> 124
EVP-SRM (DSP) Software Design Specification 102
- ------------------------------------------------------------------------
- --------------------------------------------------------------------------------
0x5 1 Illegal channel <none>
- --------------------------------------------------------------------------------
0x6- reserved
0xFF
- --------------------------------------------------------------------------------
Table 8-18
8.2.6 Tone Generation (0x5) Status Messages
For the Tone Generation STAT_type, the values for STAT_subtype are as follows:
1. STAT_subtype = OUTPULSE COMPLETE (0x0)
2. STAT_subtype = ERROR (0x1)
The format of each status message follows
8.2.6.1 TONE GENERATION/OUTPULSE COMPLETE (0X50)
The DSP may be required to report completion of an outpulsing of tones.
The format of the Tone Generation/OUTPULSE COMPLETE status message is as
follows:
- --------------------------------------------------------------------------------
Byte Field Value Description
================================================================================
1 type/subtype 0x50 Tone Gen/OUTPULSE
COMPLETE
- --------------------------------------------------------------------------------
2 channel # 1-63 STAT channel
- --------------------------------------------------------------------------------
3 length 3 STAT length
- --------------------------------------------------------------------------------
Table 8-19
8.2.6.2 TONE GENERATION/ERROR (0X51)
For this status message, the STAT_params field contains the event flag mask.
-102-
<PAGE> 125
EVP-SRM (DSP) Software Design Specification 103
- ------------------------------------------------------------------------
- --------------------------------------------------------------------------------
Byte Field Value Description
================================================================================
1 type/subtype 0x51 Tone Generation/ERRORS
- --------------------------------------------------------------------------------
2 channel # 1-63 STAT channel
- --------------------------------------------------------------------------------
3 length 4+ STAT length
- --------------------------------------------------------------------------------
4 parameters Error ID *see below
- --------------------------------------------------------------------------------
Error ID
- --------------------------------------------------------------------------------
Table 8-20
The error ID values are defined as follows:
-------------------------------------------------------
Error ID Description
-------------------------------------------------------
0x0 Tone specification does not exist
-------------------------------------------------------
0x1 Algorithm not configured
-------------------------------------------------------
0x2 Illegal channel
-------------------------------------------------------
0x3-0xFF Reserved
-------------------------------------------------------
Table 8-21
8.2.7 MFcR2 Signalling (0x6) Status Messages
For the MFcR2 STAT_type, the values for STAT_subtype are as follows:
1. STAT_subtype = DIGIT REPORT (0x0)
2. STAT_subtype = ERROR (0x3)
The format of each states message follows.
8.2.7.1 MFCR2/DIGIT REPORT (0X60)
For this status message, the STAT_params field contains the event flags, the
number of digits detected, and the digits detected.
-103-
<PAGE> 126
EVP-SRM (DSP) Software Design Specification 104
- ------------------------------------------------------------------------
- --------------------------------------------------------------------------------
Byte Field Value Description
================================================================================
1 type/subtype 0x60 MFcR2/DIGIT REPORT
- --------------------------------------------------------------------------------
2 channel # 1-63 STAT channel
- --------------------------------------------------------------------------------
3 length <= 24 STAT length
- --------------------------------------------------------------------------------
4 parameters Event Flags *see below
- --------------------------------------------------------------------------------
5 Number of n = 0 to 40
Digits
- -------- -----------------------------------------------
6 Digit 1/2 4 bits per digit
- -------- -----------------------------------------------
Digit 3/4
- -------- -----------------------------------------------
- -------- -----------------------------------------------
<= 25 Digit n-1/n
- --------------------------------------------------------------------------------
Table 8-22
The event flags are defined as follows:
---------------------------------------------------
Bits
7 6 5 4 3 2 1 0
---------------------------------------------------
0 RA ED CD TDTO PSC IDTO FDTO
---------------------------------------------------
Table 8-23
o FDTO: First digit timeout occurred
o IDTO: Inter digit timeout occurred
o PSC: Permanent signal condition occurred
o TDTO: Total digit timeout occurred
o CD: Cancel digit detected
o ED: End digit detected
o RA: Resource Attached
-104-
<PAGE> 127
EVP-SRM (DSP) Software Design Specification 105
- ------------------------------------------------------------------------
8.2.7.2 MFCR2/ERROR (0X32)
For this status message, the STAT_params field contains the error type.
- --------------------------------------------------------------------------------
Byte Field Value Description
================================================================================
1 type/subtype 0x62 MFcR2/ERROR
- --------------------------------------------------------------------------------
2 channel # 1-63 STAT channel
- --------------------------------------------------------------------------------
3 length 4 STAT length
- --------------------------------------------------------------------------------
4 parameters Error Code *see below
- --------------------------------------------------------------------------------
Table 8-24
-105-
<PAGE> 1
EXHIBIT 10.3
SOFTWARE LICENSE AND MAINTENANCE AGREEMENT
This Software license and maintenance agreement ("Agreement") is
entered into effective as of August 4, 1997 (the "Effective Date") by and
between D2 Technologies, Inc., a California corporation with offices at 104 West
Anapamu Street, Santa Barbara, CA 93101 ("D2"), and Summa Four Inc., a Delaware
corporation with offices at 25 Sundial Avenue, Manchester, New Hampshire
03103-7251 ("LICENSEE").
WHEREAS, D2 has previously developed certain software and designs
capable of performing certain voice processing functions;
WHEREAS, LICENSEE is developing a product which requires certain
software functions and designs capable of performing certain voice processing
functions;
WHEREAS, D2 desires to license to LICENSEE certain of its software
technology for use in connection with Licensee's products:
WHEREAS, D2 is further willing to provide certain maintenance and
support services to LICENSEE in relation to such software technology;
NOW THEREFORE, in consideration of the mutual promises and covenants
contained herein, the parties agree as follows:
1. DEFINITIONS
1.1 "Licensed Technology" shall mean software licensed to LICENSEE
by D2 as listed in Exhibit A.
1.2 "DSP" shall mean digital signal processing.
1.3 "Runtime License Fee" shall have the meaning set forth in
Article 2.2(iii).
1.4 "Specifications" shall mean D2's specifications of the
Licensed Technology which are attached hereto as Exhibit A.
1.5 "Update" shall mean a new release of a software product which
typically includes bug fixes and/or minor feature changes, but does not include
substantial new functionality.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 2
1.6 "New Version" in this Agreement shall mean a new release of
Licensed Technology that provides significant performance enhancements,
including new releases of software product optimized for different members of
the same DSP processor family which is based on the same core architecture and
instruction set.
1.7 "Defect" shall mean any failure of Licensed Technology to meet
the Specification as a result of a material failure (including an error or "bug"
that is material) of the Licensed Technology. "Material" is defined as priority
A, B, and C in Article 6.3.
1.8 "Source Code" shall mean all computer programming instructions
relating to a software product in a form readable by humans and typically
prepared by a programmer. Source Code includes associated procedural code,
comments, utilities, tools, notes, data diagrams and related and supporting
technical documentation.
1.9 "Object Code" shall mean software code resulting from the
translation or processing of Source Code by a computer into machine language or
intermediate code, which thus is in a form that would not be convenient to human
understanding of the program logic, but which is appropriate for execution or
interpretation by a computer.
1.10 "Licensed Source Code" shall mean Source Code for Licensed
Technology.
1.11 "Licensee Product" shall mean the product being developed by
LICENSEE as described in Exhibit B, which utilizes Licensed Technology. LICENSEE
shall own all rights, title and interest in Licensee Product. D2 shall have no
rights to Licensee Product.
1.12 "End User" shall mean a person or business entity that
purchases, leases or otherwise properly obtains the right to use or distribute a
Licensee Product directly from LICENSEE or through one or more intermediaries.
2. LICENSED TECHNOLOGY
2.1 Ownership. Subject to the rights granted to LICENSEE in this
Agreement, D2 owns all right, title and interest in and to the Licensed
Technology. Notwithstanding the foregoing, LICENSEE shall retain all right,
title and interest in and to modifications to the Licensed Source Code made by
LICENSEE pursuant to the license in Article 2.2 below, subject always to D2's
ownership rights in the underlying Licensed Technology.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 3
2.2 License to LICENSEE.
(i) Subject to the terms and conditions of this
Agreement, D2 hereby grants LICENSEE a perpetual non-exclusive, worldwide
license, to use Licensed Technology in Object Code format only as an
incorporated part of the Licensee Product. For this purpose, LICENSEE may also
modify, create derivative works, of and reproduce and have reproduced the
Licensed Technology, and to develop, use, market and distribute (directly or
through third parties) Licensed Technology, or modifications or derivative works
of the Licensed Technology created by or for LICENSEE.
(ii) In consideration for the right to modify,
develop and completely own derivative works of the Licensed Technology set forth
in Article 2.2 (i) above, LICENSEE shall pay D2 a license fee (the "Development
License Fee") as set forth in Exhibit C. Final acceptance testing shall be
completed by the parties according to Article 4 of this Agreement.
(iii) LICENSEE shall pay D2 a license fee
("Runtime License Fee") as set forth in Exhibit C for each copy of the Licensed
Technology that LICENSEE distributes to end users directly or through third
parties for such end-user's use in connection with Licensee's Product. The
Runtime License Fee shall be paid by LICENSEE quarterly for Licensee Products
which have been paid for by Licensee's end-user customer in the prior quarter.
To the extent Licensee accepts returns or is required to provide refunds to its
customers (and to the extent additional Licensee Products are delivered to
customers for warranty or maintenance/support purposes), such circumstances will
either entitle Licensee to obtain a credit against future Runtime License Fees
owed or, in the case of warranty/maintenance or support deliveries, no Runtime
License Fees shall be due at all.
(iv) LICENSEE is also granted a limited
non-transferable non-exclusive license to Licensed Source Code to perform
software maintenance functions according the terms set forth in Article 7 of
this Agreement.
(v) D2 shall provide LICENSEE with master copies
of the Licensed Technology, in Source Code and Object Code format, promptly
after such software has been completed, tested and approved for release by D2
and Licensee. In any event, D2 shall deliver all Licensed Technology completely
tested and approved for performance in accordance with the specifications.
2.3 End User License. LICENSEE shall ensure that all Licensed
Technology distributed by LICENSEE shall be subject to a shrink-wrap agreement
or other end user agreement which contains a provision substantially similar to
the provision set forth in Exhibit D.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 4
3. ADDITIONAL TECHNOLOGY LICENSE
3.1 New Functions. In the event that LICENSEE requires any
additional functionality or technology substantially different from those set
forth in Exhibit A or otherwise made available by D2 to other Licensees, D2
shall license such additional functionality or technology to LICENSEE at D2's
then best price to its other Licensees. Such additional technology licenses
shall be subject to the same terms of this agreement except for an amendment to
the product specification and price schedule of Exhibits A and C. Any other new
licensing terms shall be negotiated in advance and included in said amendment.
3.2 Different Processors.
(A) "Supported Processors": If D2 offers or plans to
offer all or part of Licensed Technology on a processor ("Supported Processor")
different from the Texas Instruments (TI) TMS320C54x family of processors, D2
shall make available to LICENSEE such new versions of Licensed Technology under
the same terms of this Agreement subject to the license fees as follows:
(i) The development license fees for any part or
all of Licensed Technology for each "Supported Processor" shall be 50% of that
for the TMS320C54x processor family as listed in Exhibit C.
(ii) The per-processor runtime license fees for
any "Supported Processor" shall be the same as that specified in Exhibit C for
the TI TMS320C54x.
(iii) The runtime license fee CAP in exhibit C
shall be cumulative across the TI TMS320C54x, TMS32OC55x, TMS330C6x, and other
TI processors based on the same core processor architecture. For processors
other than the TI processors listed in this Article 3.2A(iii) ("additional
supported processors"), the runtime license fee CAP and buy-out license fee in
Exhibit C shall be increased by 25% for each "additional supported processor."
The CAP for Licensed Technology shall be cumulative across all "Supported
Processors" (including "additional supported processors") utilized by LICENSEE.
If the cumulative inflation index (according to government published Consumer
Price Index) exceeds 25% from the effective date of this Agreement to the time
when D2 makes available Licensed Technology for an "additional supported
processor", D2 and LICENSEE agree to negotiate in good faith reasonable
incremental runtime license fees for Licensed Technology used in such
"additional supported processor.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 5
(B) "Unsupported Processors". If LICENSEE requires versions of
Licensed Technology on a processor other than the "Supported Processors", D2
agrees to negotiate in good faith with LICENSEE an agreement to develop such a
version of Licensed Technology. Such an agreement shall include appropriate
development license fees and runtime license fees as well as special engineering
service fees.
4. ACCEPTANCE
Upon delivery of the Licensed Technology to Licensee, D2 will have
tested and verified that such Licensed Technology shall perform in accordance
with an acceptance specification agreed to by D2 and LICENSEE. The acceptance
specification shall be completed no later than 90 days after the effective date
of this Agreement and shall be attached to this agreement as Exhibit F. Upon
successful completion of the acceptance testing, LICENSEE shall make the final
"Development License Fee" payment described in Exhibit C LICENSEE shall, within
thirty (30) days after delivery of any Licensed Technology, either accept such
Licensed Technology or reject such Licensed Technology because of nonconformance
with the Specifications. LICENSEE shall provide D2 with written notification of
any rejection of Licensed Technology which explains the basis for such
rejection. If completion of testing is precluded or delayed due to performance
deficiencies, incompatibilities or other Defects in the Licensed Technology, D2
shall immediately and without any additional payment, correct such Defects.. All
corrected versions of the Licensed Technology shall be subject to the acceptance
procedures set forth above in this Article 4.
5. REPORTS, AUDITS
5.1 Reports. Within thirty days after the end of each calendar
quarter during the term of this Agreement, LICENSEE shall provide D2 with
written reports setting forth the number of LICENSEE Products containing the
Licensed Technology that were licensed to end users by LICENSEE in such calendar
quarter as more particularly described in Article 2.2 (iii) above.
5.2 Audits. LICENSEE shall maintain records of its distribution of
Licensee Products containing the Licensed Technology, for a period of one year
after the date on which LICENSEE distributes the Products to which such records
pertain. D2 may audit such records by engaging an independent public audit firm,
approved in advance by Licensee, upon thirty days written notice, provided that
(i) no more than one such audit may be made in any twelve month period, (ii) D2
may only audit LICENSEE's records for a particular time period once, and (iii)
D2 shall be responsible for ensuring that the auditor executes and abides by
LICENSEE's confidentiality agreement.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 6
6. MAINTENANCE AND SUPPORT
6.1 Maintenance and Support Obligation, Fees. On the date of
expiry of the Warranty period defined in Article 8.3, and on any anniversary of
the expiry date, LICENSEE may in its sole discretion pay D2 a "Maintenance and
Support Fee" according to Exhibit C. In return for payment of such fee, D2 shall
provide LICENSEE with the maintenance and support set forth in this Article 6
for a period of twelve months (the "Contract Year"). In any event, D2 shall
provide support and maintenance services to Licensee during the Warranty period
in breadth and scope which is no less than the support and maintenance services
described in this Article. D2 shall make available to LICENSEE the maintenance
and support services according to the terms of this Article 6 for a minimum of
five years after Acceptance of Licensed Technology.
6.2 Maintenance. Maintenance to be provided by D2 to LICENSEE
shall include without limitation the following services;
(i) D2 shall update and maintain the Licensed
Technology throughout the term of this Agreement. It is intended that D2 shall
release at least 1 Update or New Version release during each 12 month calendar
year. Upon the releases of any Update or New Version of the Licensed Technology
(including manuals), D2 shall promptly notify and deliver to LICENSEE such
Update or New Version.
(ii) D2 will initially deliver to LICENSEE one
(1) copy of any Updates or New Versions to the Licensed Technology and one (1)
set of corresponding manuals for each copy of the Licensed Technology for which
LICENSEE has paid the appropriate development license fees and maintenance fees
pursuant to Exhibit C as soon as such Updates or New Versions and corresponding
manuals become available and shall maintain such Updates or New Versions
throughout this agreement.
6.3 Error Correction. If D2 becomes aware of any Defect in the
Licensed Technology, D2 shall promptly provide LICENSEE with written notice of
such Defect. D2 shall have no obligation to actively monitor the Licensed
Technology for Defects after such software has been accepted by LICENSEE. D2
shall work diligently to promptly correct Defects in accordance with the
following schedule; "days" shall mean calendar days.
ERROR PRIORITY (1) RESPONSE (2) CLOSURE (3)
Emergency (A) 24 hours 7 days
Critical (B) 2 days 14 days
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 7
Non-Critical (C) 30 days Next Update
or
New Version
(1) Priority:
-A- Catastrophic product or module Defects that
do not have a viable detour or work around available.
-B- Defects that have been substantiated as
a serious inconvenience to LICENSEE or an End User. This includes any priority A
Defect for which a viable detour or work around is available.
-C- All other problems that LICENSEE and an End
User can easily avoid for which there is no urgency for a resolution.
(2) Response: Response consists of providing, as
appropriate, one of the following to the LICENSEE: an existing correction; A new
correction; a viable detour or work around; a request for more information to
complete analysis of the problem, or a plan on how the problem will be
corrected.
(3) Closure: Closure consists of providing a final
correction or work around of the problem including an Update and revised or new
Documentation as necessary.
If D2 fails to correct Defects according to the schedule specified in
this Article 6, LICENSEE shall deduct from future runtime license fees, as
specified in Exhibit C, a "late fee" for each day past the deadline in the
schedule of this section. The "late fee" shall equal to 50% (fifty percent) of
the runtime license fees paid to D2 for the previous two calendar quarters
equally divided over 180 (one hundred eighty) days. In the event LICENSEE has
selected the Buy-out option in the runtime license fee schedule of Exhibit C,
then the "late fee" for each day past the deadline shall be 50% (fifty percent)
of the Buy-out fee equally divided over 1095 (one thousand and ninety five)
days; and this "late fee" shall be paid to LICENSEE each calendar month until
the error is corrected either by D2 or LICENSEE.
6.4 Support. D2 will provide the following support to LICENSEE
throughout the Warranty period and for those subsequent years for which support
has been purchased by Licensee:
(i) D2 will assist LICENSEE in determining if
problems encountered by LICENSEE are caused by programming errors in the
Licensed Technology.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 8
(ii) D2 will answer questions concerning the
installation of Licensed Technology.
(iii) D2 will assist LICENSEE in resolving
LICENSEE's problems, if any, arising from the normal usage of the Licensed
Technology.
(iv) D2 shall appoint a qualified technical staff
as the "Technical Contact" to co-ordinate all support and maintenance services.
The "Technical Contact" shall be available to LICENSEE during D2's normal
business hours; in the event that appointed "Technical Contact" is not
available, a back-up "Technical Contact" shall be temporarily assigned and
LICENSEE shall be notified.
6.5 Notification and Cooperation by LICENSEE. To obtain support
from D2 under this Article 6, LICENSEE shall provide D2 with written notice
which will contain a description of the problem for which LICENSEE is seeking
support. D2 shall have no obligation to correct problems which are due to
modifications to Licensed Technology performed by LICENSEE; provided, that if D2
agrees to correct such problems it shall charge its then current time and
materials rates, which shall be payable by LICENSEE within thirty days after
invoicing by D2. LICENSEE agrees to provide D2 with access to LICENSEE's
equipment and computer systems on a temporary basis and as needed to allow D2 to
reproduce, correct and verify the correction of the problem reported by LICENSEE
or otherwise identified by D2.
7. LIMITED SOURCE CODE LICENSE AND PROTECTION
7.1 Source Code delivery. D2 shall, after acceptance of Licensed
Technology by LICENSEE and within fifteen days after receiving such a request
from LICENSEE deliver a copy of the fully commented Source Code for the then
current version of the Licensed Technology and information needed for compiling
and building the Licensed Technology Object Code to LICENSEE. Thereafter, D2
shall automatically deliver a copy of the fully commented Licensed Source Code
for the then current version of the Licensed Technology within fifteen days
after the release of any Updates or New Versions of the Licensed Technology.
7.2 Source Code Access Conditions. The following events shall
constitute "Source Code Access Conditions": (i) D2's insolvency, general
assignment for the benefit of creditors, or ceasing to do business, or (ii) D2's
failure or inability to meet its warranty, maintenance and support obligations
under Article 6, or its warranty obligations under Article 8.3, within fifteen
days after written notice by LICENSEE to D2 of D2's failure to meet such
obligations, or (iii) termination of this Agreement by LICENSEE pursuant to
Articles 9.3 and 9.4, or (iv) as needed by LICENSEE for fault isolation.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 9
7.3 Use of Licensed Source Code. After "Source Code Access
Conditions" is met, LICENSEE shall have the right to use, modify, reproduce and
have reproduced Object Code from Licensed Source Code to develop, use, market,
distribute, and to maintain and support the Licensed Technology in the Licensee
Product. LICENSEE shall not have any right to develop new DSP technology or
derivative DSP technology with the Licensed Source Code.
7.4 Confidentiality and security.
(A) General. LICENSEE acknowledges and agrees that the
Licensed Source Code constitutes the confidential and proprietary trade secrets
of D2, and that LICENSEE's protection thereof is essential to this Agreement and
a condition of LICENSEE's use and possession of the Licensed Source Code.
LICENSEE shall retain in strict confidence any and all elements of the Licensed
Source Code and use the Licensed Source Code only as expressly licensed herein.
LICENSEE agrees that it will under no circumstances distribute or in any way
disseminate or disclose the Licensed Source Code to third parties, except as
expressly provided in this Article 7. LICENSEE shall be relieved of this
obligation of confidentiality to the extent that such information was in the
public domain at the time it was disclosed or has become in the public domain
through no fault of LICENSEE.
(B) Security. LICENSEE agrees to use the Licensed Source
Code under carefully controlled conditions for the purposes set forth in this
Agreement, and to inform all employees who are given access to the Licensed
Source Code by LICENSEE that such materials are confidential trade secrets of D2
and are licensed to LICENSEE as such. LICENSEE shall restrict access to the
Licensed Source Code to those employees and Contractors of LICENSEE who have
agreed to be bound by a confidentiality obligation which incorporates the
protections and restrictions substantially as set forth herein, and who have a
need to know in order to carry out the purposes of this Agreement. D2 shall be
made a third party beneficiary of any such agreements, and shall have the right
to directly enforce the terms of those agreements, and of this Agreement,
insofar as such enforcement relates to the Licensed Source Code.
(C) LICENSEE agrees to notify D2 promptly in the event of
any breach of its security under conditions in which it would appear that the
Licensed Source Code were prejudiced or exposed to loss. LICENSEE shall, upon
request of D2, take all other reasonable steps necessary to recover any
compromised trade secrets disclosed to or placed in the possession of LICENSEE
by virtue of this Agreement. The cost of taking such steps shall be borne solely
by LICENSEE.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 10
(D) Remedies. LICENSEE acknowledges that any breach of
any of its obligations under this Article 7 is likely to cause or threaten
irreparable harm to D2, and accordingly, LICENSEE agrees that in such event, D2
shall be entitled to equitable relief to protect its interest therein, including
but not limited to preliminary and permanent injunctive relief, as well as money
damages.
(E) Hardware.
(i) Two (2) computers, as identified in Exhibit
E, may be used as the Development Computer and Back-up Computer. The Back-up
Computer may be used as the Development Computer during any time when the
Development Computer is inoperative because it is malfunctioning or undergoing
repair, maintenance or other modification.
(ii) LICENSEE may at any time notify D2 in
writing of any changes, such as replacements or additions, that LICENSEE wishes
to make to Development and Back-up Computers for specific Licensed Source Code.
D2 will prepare an amended Exhibit E as required to cover such changes, and such
changes shall become effective after execution of the amended Exhibit E by
LICENSEE.
(iii) Upon request, LICENSEE shall furnish to D2 a
statement, certified by an authorized representative of LICENSEE, listing the
location, type and serial number of all Development and Back-up Computers
hereunder and stating that the use by LICENSEE of the Licensed Source Code
subject to this Agreement has been reviewed and that the Licensed Source Code is
being used solely on the Development Computer (or temporarily on Back-up
Computer) for such Licensed Source Code in full compliance with the provisions
of this Agreement.
(F) Third Party Contractors. LICENSEE may appoint a third
party contractor ("Contractor") to assist the LICENSEE in LICENSEE's
modification of the Licensed Source Code as authorized hereunder; provided that
any such Contractor's access to and use of the Licensed Source Code shall only
be permitted pursuant to a signed written agreement between LICENSEE and such
Contractor giving the Contractor rights no broader than those granted LICENSEE
in this Agreement, but limited to the sole purpose of assisting the LICENSEE,
and including provisions incorporating the additional requirements set forth
below:
(i) Any claim, demand or right of action arising
on behalf of a Contractor from furnishing to it or use by it of Licensed Source
Code shall be solely against LICENSEE, and LICENSEE hereby indemnifies D2
against any such claims.
(ii) Contractor shall agree to the same
responsibilities and obligations and other restrictions pertaining to the use of
Licensed Source Code as those undertaken by LICENSEE under this Agreement.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 11
(iii) Contractor may not retain any copy of the
Licensed Source Code or any modification or derivative work thereof and, upon
completion of the project for which Contractor was permitted access to the
Licensed Source Code or termination of this Agreement, shall return or destroy
(i) all copies of Licensed Source Code furnished to such Contractor or made by
such Contractor and (ii) all copies of any modifications or derivative works
made by such Contractor based on such Licensed Source Code copies stored in any
computer memory or storage medium, and Contractor's computer shall be removed
from Exhibit E if such computer was listed as a Development Computer. A writing
executed by an officer of Contractor shall be provided to D2 certifying that the
Contractor has returned or destroyed all copies of the Licensed Source Code in
its possession or control.
(iv) Unless Contractor obtains a license for the
Licensed Source Code from D2, Contractor may not acquire any ownership interest
in any modification or derivative work prepared by such Contractor based upon or
using Licensed Source Code licensed to LICENSEE under this Agreement.
(v) Copies of such agreements shall be provided
to D2 on request; provided however, that portions of such agreements not
required by this Article 7 may be deleted from such copies.
8. REPRESENTATIONS AND WARRANTIES
8.1 By Both Parties. D2 warrants that it owns all rights, title,
and interests to Licensed Technology listed as Basic Services in Exhibit A.
LICENSEE and D2 each individually warrants that it (i) has all right, power and
authority necessary to enter into this Agreement and to grant the rights granted
herein; (ii) has obtained all approvals and authorizations that it is required
to obtain in connection with this Agreement; and (iii) has not entered, and will
not enter, into any arrangements or agreements inconsistent with this Agreement.
8.2 Additional D2 Warranties. D2 additionally warrants that it (i)
is not aware of any pending or actual litigation which is likely to have a
material adverse effect on the rights or obligations of LICENSEE under this
Agreement; and (ii) is not aware of any claim or any basis for any claim that
Licensed Technology, or LICENSEE's use of the Licensed Technology as
contemplated herein, will infringe any patents, trade secrets of other
intellectual property rights belonging to any third party.
8.3 Software Warranty. D2 warrants to LICENSEE that the media upon
which the Licensed Technology is delivered to LICENSEE will be free from Defects
in materials and workmanship, and that Licensed Technology shall meet and
perform in accordance with D2's specifications on Exhibit A. D2 shall promptly
correct any
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 12
errors in the Licensed Technology, or failures of the Licensed Technology
according to the terms of Article 6 of this Agreement. D2's warranty and error
correction obligations with respect to any portion of the Licensed Technology
shall extend for a period (the "Warranty period") of one year commencing on
acceptance of such portion of the Licensed Technology by LICENSEE.
8.4 Disclaimer of Other Warranties. THE REPRESENTATIONS AND
WARRANTIES EXPRESSLY SET FORTH IN THIS ARTICLE 8 ARE IN LIEU OF ALL OTHER
WARRANTIES, EXPRESS OR IMPLIED, EITHER IN FACT OR BY OPERATION OF LAW, STATUTORY
OR OTHERWISE. D2 SPECIFICALLY DISCLAIMS ALL WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE IN CONNECTION WITH THE LICENSED TECHNOLOGY.
9. TERM AND TERMINATION.
9.1 Term. This Agreement shall become effective on the Effective
Date and shall continue in effect until terminated in accordance with the
provisions of this Article 9.
9.2 For Convenience. LICENSEE may terminate this Agreement upon
ninety (90) days written notice.
9.3 Default. If either party defaults in the performance of any of
its material obligations hereunder and if such default is not corrected within
thirty (30) days after written notice thereof by the other party, then the
nondefaulting party, at its option, may, in addition to any other remedies it
may have, terminate this Agreement by giving written notice of termination to
the defaulting party.
9.4 Survival. Articles 7.2, 7.3,7.4, 8, 9, 10, 11, 12, 13, 14
shall survive any termination or expiration of this Agreement.
10. INDEMNIFICATION
10.1 By D2. D2 agrees to indemnify and hold LICENSEE harmless
against any cost, loss, liability, or expense (including attorney's fees)
arising out of any breach of D2's warranties hereunder, or out of third party
claims against LICENSEE alleging that the Licensed Technology, or LICENSEE's use
or distribution of the Licensed Technology as set forth in this Agreement,
infringes any third party's patent, trade secret, copyright of other
intellectual property right in any country, provided that LICENSEE shall (i)
notify D2 promptly in writing of such claims, and (ii) give D2 sole control of
the defense or settlement of such claims. D2 shall not be liable for any claims
to the extent that such claims arise out of the LICENSEE's unauthorized
modifications of the Licensed Technology, and not out of the Licensed Technology
as delivered by D2 to LICENSEE. If the Licensed Technology, or any part thereof,
is
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 13
adjudicatively determined to be, or in either party's reasonable opinion will
be, the subject of any claim, suit or proceeding for infringement of any third
party's patent, copyright or trade secret in any country, or if the distribution
of use of the Licensed Technology is enjoined, then D2 may, at D2's sole option
and expense, (i) obtain for LICENSEE and its distributors, resellers and
customers the right to distribute or use the Licensed Technology under such
third party patents, trade secrets, copyrights or other intellectual property
rights, or (ii) replace the Licensed Technology with other software of
equivalent or superior functionality, or (iii) suitably modify the Licensed
Technology to avoid such infringement. In the event that D2 is unable to carry
out the options set forth in (i), (ii) and (iii) of the proceeding sentence, at
the option of Licensee D2 may terminate this Agreement and refund all amounts
paid by LICENSEE to D2 hereunder; provided, that such termination shall have no
effect on the rights of end users to use LICENSEE products, incorporating any
Licensed Technology, which were acquired by such end users prior to such
termination.
11. LIMITATION OF LIABILITY
IN NO EVENT SHALL EITHER PARTY BE LIABLE TO THE OTHER PARTY FOR LOST
PROFITS OR ANY CONSEQUENTIAL, SPECIAL, INCIDENTAL, OR INDIRECT DAMAGES OR SUCH
OTHER PARTY, HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, ARISING OUT OF THIS
AGREEMENT. THESE LIMITATIONS SHALL APPLY NOTWITHSTANDING ANY FAILURE OF
ESSENTIAL PURPOSE OF ANY LIMITED REMEDY. IN NO EVENT SHALL D2'S LIABILITY
HEREUNDER EXCEED THE TOTAL AMOUNT PAID OR OWED BY LICENSEE TO D2 UNDER THIS
AGREEMENT.
12. CONFIDENTIALITY.
12.1 Confidential Information. As used in this Agreement, the term
"Confidential Information" shall mean any information disclosed by one party to
another pursuant to this Agreement which is marked as confidential or
proprietary, or, if disclosed orally, is designated as confidential at the time
of disclosure and is subsequently reduced to a writing which is marked as
confidential or proprietary and is provided to the receiving party within thirty
(30) days after such oral disclosure.
12.2 Confidentiality. Each party shall treat as confidential all
Confidential Information of the other party, shall not use such Confidential
Information except as set forth herein, and shall use reasonable efforts not to
disclose such Confidential Information disclosed to it by the other party under
this Agreement. Each party shall promptly notify the other party of any actual
or suspected misuse or unauthorized disclosure of such other party's
Confidential Information.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 14
12.3 Exception. Not withstanding the above, neither party shall
have liability to the other party with regard to any Confidential Information of
such other party which the receiving party can demonstrate:
(i) was in the public domain at the time it was
disclosed or has entered the public domain through no fault of the receiving
party;
(ii) was known to the receiving party, at the
time of disclosure, as demonstrated by files in existence at the time of
disclosure;
(iii) was disclosed with the prior written
approval of the disclosing party;
(iv) was, is presently or may be in the future
independently developed by the receiving party without any use of the
Confidential Information of any other party, as demonstrated by files created at
the time of such independent development;
(v) became known to the receiving party, without
restriction, from a source other than the disclosing party without breach of
this Agreement by the receiving party and otherwise not in violation of the
disclosing party's rights;
(vi) has been disclosed to third parties by the
disclosing party without restrictions similar to those contained in this
Agreement; or
(vii) is disclosed pursuant to the order or
requirement of a court, administrative agency, or other governmental body;
provided, however, that the receiving party shall provide prompt written notice
thereof to the disclosing party to enable the disclosing party to seek a
protective order or otherwise prevent or restrict such disclosure.
12.4 Return of Confidential Information. Upon expiration or
termination of this Agreement each party shall upon request promptly return all
tangible Confidential Information received from the other party.
12.5 Survival of Confidentiality Obligations. This Article 12 will
survive the termination of this Agreement, for any item of Confidential
Information, for five (5) years after the disclosure of such Confidential
Information to the receiving party under this Agreement.
13. CONFIDENTIALITY OF AGREEMENT.
D2 and LICENSEE agree that the terms and conditions of this Agreement
shall be treated as confidential and shall not be disclosed to any third party
without the
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 15
prior written consent of the other party. Notwithstanding the statements above
in this Article 13, any party may disclose any of the terms and conditions of
this Agreement;
(i) as required by any court of other
governmental body;
(ii) as otherwise required by law (including
without limitation with regard to any registration statement filed by a party
with the Securities and Exchange Commission);
(iii) to legal counsel of the parties;
(iv) in confidence, to accountants, banks, and
financing sources, and other advisors or consultants of the parties;
(v) in connection with the enforcement of this
Agreement or rights under this Agreement;
(vi) in confidence, in connection with an actual
or proposed license, merger, acquisition, or similar transaction;
(vii) which have been previously disclosed in a
joint press release by the parties hereto, or
(viii) in confidence, to a third party to the
extent reasonable necessary to permit the consideration of a bona fide
collaboration which would involve rights, obligations or limitations arising
under this Agreement, provided that such collaboration is not prohibited under
this Agreement.
In the event of any disclosure pursuant to (i) or (ii) above, the
disclosing party shall use all reasonable efforts to obtain confidential
treatment of materials so disclosed. The parties shall in good faith consult
regarding the text of any proposed public announcement regarding this Agreement
or the terms and conditions hereof before such announcement is actually made.
Any press release to be issued in connection with the terms and conditions of
this Agreement must be approved in advance by both parties.
14. EXPORT RESTRICTIONS
LICENSEE's distribution of products incorporating Licensed Technology
shall be subject to all United States laws and regulations governing the license
and delivery of technology and products abroad by persons subject to the
jurisdiction of the United States. LICENSEE shall not export any such products
without first
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 16
obtaining all required licenses and approvals from the appropriate government
agencies.
15. GENERAL
15.1 Governing Law. This Agreement shall be governed by and
interpreted in accordance within the laws of the State of New York without
reference to conflicts of laws provisions.
15.2 Venue. The parties agree that any litigation arising out of
this Agreement shall be brought in the state courts in Delaware.
15.3 Partial Invalidity. If any provision in this Agreement shall
be found or be held to be invalid or unenforceable in any jurisdiction in which
this Agreement is being performed, then the meaning of said provision shall be
construed, to the extent feasible, so as to render the provision enforceable,
and if no feasible interpretation would save such provision, it shall be
severed, solely in such jurisdiction, from the remainder of this Agreement,
which shall remain in full force and effect. In such event, the parties shall
negotiate, in good faith, a substitute, valid and enforceable provision,
effective solely in such jurisdiction, which most nearly effects the parties'
intent in entering into this Agreement.
15.4 Relationship of the Parties. D2 and LICENSEE are independent
contractors under this Agreement. Nothing contained in this Agreement is
intended to, nor is it to be construed so as to, constitute D2 and LICENSEE as
partners or joint ventures with respect to this Agreement. Employees of any
party remain employees of said party and shall at not time be considered agents
of or to be obligated to render a fiduciary duty to the other party.
15.5 Modification. No alteration, amendment, waiver, cancellation
or any other change in any term or condition of this Agreement shall be valid or
binding on any party unless the same shall have been mutually assented to in
writing by both parties.
15.6 Waiver. The failure of any party of enforce at any time any of
the provisions of this Agreement, or the failure to require at any time
performance by the other parties of any of the provisions of this Agreement,
shall in no way be construed to be a present or future waiver of such provision,
nor in any way affect the right of any party to enforce each and every such
provision thereafter. The express waiver by any party of any provision,
condition or requirement of this agreement shall not constitute a waiver of any
future obligation to comply with such provision, condition or requirement.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 17
15.7 Assignment. This Agreement shall be binding upon and shall
inure to the benefit of the parties hereto and their respective successors and
assigns. No party may assign any of its rights, obligations or privileges
(except by operation of law or other corporate reorganization) hereunder without
the prior written consent of the other party, which shall not be unreasonable
withheld, provided, that any party shall have the right to assign its rights,
obligations and privileges hereunder to a successor in business or an acquirer
of all or substantially all of its business or assets to which this Agreement
pertains without obtaining the consent of the other party.
15.8 Notices. Any notice required or permitted to be given by any
party under this Agreement shall be in writing, shall be addressed to the
President of D2, or to the President of LICENSEE, and shall be personally
delivered or set by certified or registered letter, or by telecopy confirmed by
registered or certified letter, to the receiving party at its address first set
forth above, or such new address as may from time to time be supplied hereunder
by the receiving party. Notices will be deemed effective upon receipt.
15.9 Force Majeure. Notwithstanding anything else in this
Agreement, no default, delay or failure to perform on the part of any party
shall be considered a breach of this Agreement if such default, delay or failure
to perform is shown to be due to causes beyond the reasonable control of the
party charged with a default, including, but not limited, causes such as
strikes, lockouts or other labor disputes, riots, civil disturbances, actions or
inactions of governmental authorities or suppliers, epidemics, war, embargoes,
were weather, fire, earthquakes, acts god, acts of the public enemy or nuclear
disasters; provided, that for the duration of such force majeure the party
charged with such default must continue to use all reasonable efforts to
overcome such force majeure.
15.10 Entire Agreement. The terms and conditions contained in this
Agreement constitute the entire agreement between the parties and supersede all
previous agreements and understandings, whether oral or written, between the
parties hereto with respect to the subject matter hereof.
IN WITNESS WHEREOF, the parties hereto have caused this agreement to be
signed by duly authorized officers or representatives as of the date first above
written.
"LICENSEE" D2 TECHNOLOGIES, INC.
- --------------------------------- -----------------------------------
BY: /s/ Dick Swee BY: /s/ David Y. Wong
----------------------------- -------------------------------
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 18
PRINT NAME: Dick Swee PRINT NAME: David Y. Wong
--------------------- -----------------------
TITLE: VP Engineering TITLE: President
-------------------------- ------------------------------
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 19
EXHIBIT A
LICENSED TECHNOLOGY SPECIFICATION
Basic Services:
The Basics Services algorithm group shall include the following list of standard
D2 products with LICENSEE required modifications as specified in the attached
Specification and the Contract for Products and Services, dated August 6, 1997:
DTMF Detection and Removal Algorithm 5007-54A
Universal Tone Detection Algorithm 50030-54A
Multifrequency Tone Detection Algorithm 50028-54A
Tone Generation Algorithm 50015-54A
Voice Activity Detection and AGC 50013-54A
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 20
Exhibit A continued.
Detailed Signal Processing Algorithm Specification
A.1 HDLC Communications
Not included as Licensed Technology.
A.2 Voice Activity Detection
Voice Activity Detection (VAD) detects voice activity, adapts to background
ambient or line noise as well as the presence of echo, classifies voice activity
as "early" versus "sustained", and assigns an "effort level" to the speaker that
is independent of network loss.
This module is used to detect voice activity in the CP Detect state.
A.2.1 Functional requirements:
The Voice Activity Detector discriminates voice activity generated by a caller
from background noise (acoustic and line noise) as well as echo and sidetones
reflected back to the receive voice path. It also provides an "effort level"
quantity that indicates the level of effort of the caller. The functional and
performance requirements are specified to cover a wide range of applications,
such as voice activated recordings (as in voice messaging), outbound call
classification, digital speech interpolation (DSI), and voice conferencing.
1. The Voice Activity Detector classifies every block of voice data (8 ms
long) as "port active" (early detect), "speaker active" (port
sustained), and "not active".
2. It provides a measurement that approximates the level of effort exerted
by the caller. Such an approximation is made by normalizing the short
term RMS of the voice signal by a longer term RMS value. The "effort
level" varies between -32 dB and 31 dB, and is at 0 dB when the speaker
is speaking at his/her "normal" level.
3. The Voice Activity Detector adapts to background noise up to -24 dBm.
Adaptation is 200 ms when the noise level drops, and is approximately
1000 ms when noise rises.
4. The Voice Activity Detector screens out sidetone or echo as speech up
to an ERL of -26 dB.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 21
A.2.2 Performance Requirements:
The accuracy of the voice Activity detector is measured by the rate of "false
detection" (i.e. classifying noise or echo as voice activity) and "clipping"
(i.e. classifying voice activity as noise or echo) under different ambient noise
and echo conditions. "Port active" detection under different ambient noise
conditions:
1. No perceptible clipping at quiet to modest noise levels of -50 dBm to
-40 dBm with nominal levels of speech activity (-20 dBm average power
over 2 seconds of speech). No more than 5% of voice onsets is clipped
for noisy conditions (noise level from -40 dBm to -30 dBm).
2. No more than 1% of "silence" periods is detected as speech for the
modest noise condition. No more than 2% of "silence" is detected as
port active for noisy conditions.
3. The performance goals above is met when noise levels change during the
test.
"Speaker active" detection under different ambient noise conditions:
1. Speech activity that lasts more than tSUSTAIN is detected as
"Sustained" or "Speaker Active".
2. The clipping requirements is better than "Port Activity" detection.
Fewer than 0.5% of onsets/hour (2.5 per hour) for modest noise
condition (-45 dBm) and fewer than 2% (10 per hour) for high noise
condition (-35 dBm) have perceptible clipping.
3. False detection performance (i.e., detecting noise as "speaker active")
exceeds those of "port activity" due to tSUSTAIN criteria. No more than
1% (36 seconds per hour) of noise segments is misclassified as
"sustained" for modest noise conditions, and no more than 2% (72
seconds per hour) of "silence" is detected as port active for noisy
conditions.
"Port active" and "Speaker active" detection in the presence of echo:
1. Less than 1% of residual echo is detected as "port active" - (i.e. 36
sec. per hour) during normal operation of canceller.
2. Less than 0.1 % (i.e. 3.6 sec per hour) of residual echo is detected as
"speaker active" or "port sustained" during normal operation of
canceller.
3. Clipping of input speech in the presence of echo is no higher than
clipping in the presence of modest to high level of noise.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 22
A.3 DTMF Detection
A.3.1 Functional requirements:
Table A-1 specifies the nominal frequencies for the DTMF digits that must be
detected.
--------------------------------------------------------------
Nominal High Group Frequencies (Hz)
1209 1336 1477 1633
--------------------------------------------------------------
Nominal 697 1 2 3 A
Low Group 770 4 5 6 B
Frequencies 852 7 8 9 C
(Hz) 941 * 0 # D
--------------------------------------------------------------
Table A-1: Nominal DTMF Frequencies
1. Detect the presence of all 16 DTMF digits that are produced by
different phones on the market under a broad range of network
conditions.
2. DTMF digit information is provided as soon as the minimum duration is
met. This information is called leading edge detection. This allows the
earliest possible response to the digit, such as stopping voice output.
3. The trailing edge of a DTMF digit must be detected. This allows the
system to delay any response (such as playing out voice) to the digit
until the user has released the DTMF key. The criteria selected for
trailing edge detection will debounce DTMF digits.
4. The DSP reports leading and trailing edge in the 8 ms block that they
are detected. DTMF events are not buffered.
A.3.2 Performance requirements:
Table A-2 consists of performance requirements taken from EIA-464A and Bellcore
TR-TSY-000181. Also shown is D2's DTMF performance requirements, which is a
superset of the EIA and Bellcore requirements.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 23
<TABLE>
<CAPTION>
- --------------------------------------------------------------------------------------------------------------------
Requirement
- --------------------------------------------------------------------------------------------------------------------
Characteristic Bellcore EIA/TIA-464A D2
- --------------------------------------------------------------------------------------------------------------------
<S> <C> <C> <C>
Frequency Deviation +/-1.5% must accept; +/-1.5% must accept; Configurable choice of
+/-3.5% must reject +/-3.5% must reject four sets of must
accept/must reject:
+/-2.0% accept to +/-3.0%
reject; +/-2.5% accept to
+/-3.5% reject; +/-3.0%
accept to +/-4.0% reject;
+/-3.5% accept to +/-4.5%
reject.
- --------------------------------------------------------------------------------------------------------------------
Minimum Tone 40 ms must accept; 23 40 ms must accept Configurable from 24
Duration ms must reject to 80 ms
- --------------------------------------------------------------------------------------------------------------------
Minimum Interdigital 40 ms 40 ms Configurable from 24
Interval to 80 ms
- --------------------------------------------------------------------------------------------------------------------
Minimum Cycle Time 93 ms 93 ms Configurable from 48
to 160 ms
- --------------------------------------------------------------------------------------------------------------------
Accept Levels 0 to -36 dBm must 0 to -25 dBm must 0 dBm to configurable
accept, -55 dBm must accept minimum (-25 to -45
reject dBm range)
- --------------------------------------------------------------------------------------------------------------------
Twist (ratio of high -8 to +4 dB -8 to +4 dB Separately
group power to low) configurable positive
and negative twists:
+/- 4, 6, 8, 10, and 12 dB
- --------------------------------------------------------------------------------------------------------------------
Bellcore talkoff tape Fewer than 670 total - Fewer than 20 talkoffs
talkoffs; fewer than (with default
330 talkoffs of digits 0- configuration of 2.5%
9; fewer than 170 to 3.5% frequency
talkoffs of signals * deviation; 40 msec min
and #. tone duration; +/- 8 dB
twists; -45 dBm min
accept level)
- --------------------------------------------------------------------------------------------------------------------
Mitel talkoff tape - - 0 talkoffs (with default
configuration)
- --------------------------------------------------------------------------------------------------------------------
SNR 23 dB 15 dB 15 dB
- --------------------------------------------------------------------------------------------------------------------
Impulse Noise Fewer than 14 missed Fewer than 10 errors Pass both Bellcore and
or split digits in in 10,000 tones for EIA EIA/TIA-464A
Bellcore Impulse Noise test #1; fewer than 500 impulse noise
Tape No. 201 errors in 10,000 tones requirements
for test #2
- --------------------------------------------------------------------------------------------------------------------
</TABLE>
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 24
<TABLE>
<S> <C> <C> <C>
- -------------------------------------------------------------------------------------------------------------------
Echo 16 dB Signal-to-Echo 10 dB Signal-to-Echo Pass both Bellcore and
ratio at 20 ms; 24 dB at ratio at 20 ms EIA/TIA-464A echo
45 ms requirements
- -------------------------------------------------------------------------------------------------------------------
Dial Tone DTMF Detection in the DTMF Detection in the Pass both Bellcore and
presence of dial tone presence of dial tone EIA/TIA-464A
at -15 dBm per dial at -16 dBm per dial requirements for
tone frequency tone frequency detection of DTMF
digits in the presence
of dial tone
- -------------------------------------------------------------------------------------------------------------------
</TABLE>
TABLE A-2: DTMF Performance Requirements
Other performance requirements:
1. A leading edge of DTMF digit is signaled during the block in which the
minimum duration is met, and the trailing edge is signaled during the
block in which the minimum debounce interval is met.
2. Talk-down: DTMF detection must work reliably in the presence of echo
(for the maximum allowable output voice level) and with varying levels
of DTMF signals (due to network loss). D2's DTMF detector combined with
the echo must meet the performance requirements of Figure A-I in the
presence echo generated by playing pause-removed voice (male and
female) at - 18 dBm ASL (averaged over 3 seconds) over a telephone
circuit with 15 dB echo return loss (ERL).
INSERT GRAPH
Figure A-1: DTMF Talk-down Acceptance Curve
3. Debounce test: Long tones (generated by "hard" key presses) must not be
detected as multiple tones in the presence of echo interference or line
noise. Combined with the echo canceller, the DTMF detector is required
to reliably "debounce" all DTMF digits above -18 dBm in the presence of
voice levels below -15 dBm (ASL) and a telephone circuit with echo
return loss (ERL) of 15 dB.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 25
4. Double-talk talk-off: Many voice processing hardware or semiconductor
manufacturers significantly degrade the "talk-off' performance of their
detector in the presence of voice echo or sidetone to achieve a high
level of talk-down performance. This strategy is acceptable in a pure
digit-in-voice-out scenario, but for voice conferencing or voice
recognition applications, voice could be present in the both the
transmit and receive path. In such cases, the DTMF detector must be
very robust against "talk-off" in double-talk situations. The talk-off
requirements for D2's DTMF detector under double-talk is fewer than 66
talkoffs for the Bellcore talk-off tape.
A.4 Tone Generation
The tone generation module can be programmed to generate any single, dual or
amplitude modulated tone required to meet international telecommunications
specifications. This functionality is provided by the GENF module, which
produces the sum or product of two independently generated sine waves as its
output. Each sine wave can be individually parameterized.
A.4.l Functional requirements:
The GENF module is designed to generate a wide range of DTMF, Call Progress
Signals, MF Rl/R2, and miscellaneous tones. In order to meet or exceed
international telecommunication specifications, GENF must meet or exceed the
following functional requirements.
1. Independent arguments shall be supplied for each frequency for dual
tones that GENF generates. Single tones are generated by specifying
that one of the dual tone's frequencies is 0 Hz.
2. Independent arguments shall be supplied for the carrier and modulation
frequencies for amplitude modulated tones that GENF generates.
3. Arguments shall be supplied that allow the frequency of a tone to be
set in the range of 0 to 4000 Hz in 1 Hz units.
4. Arguments shall be supplied that allow the output power to be set in
the range of +3 to -50 dBm in 0.5 dB steps.
5. Arguments shall be supplied that allow an amplitude modulated tone's
modulation percentage to be set in the range of 0 to 300% in 1% units.
6. The tone duration (make time) shall be specified in 1 ms units. Tone
durations shall be specified in the range of 0 to 8191 ms.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 26
7. An unlimited tone duration shall be specified by setting the make
duration to -1.
8. The silence duration between tones (break time) shall be specified in 1
ms units. Silence durations shall be specified in the range of 0 to
8191 ms.
9. An unlimited silence duration shall be specified by setting the make
duration to -1 and setting both frequencies of a dual tone to 0 Hz.
10. The GENF module shall allow tones to be generated that meet or exceed
EIA/TIA-464 requirement for DTMF and call progress tone generation.
11. The GENF module shall allow tones to be generated that meet or exceed
CCITT Blue Book Volume VI Fascicle VI.4 recommendations Q.310-Q.490
requirements for MF R1 and R2 tone generation.
12. The GENF module shall generate tones with one to three unique cadence
pairs (on/off pairs).
A.4.2 Performance Requirements
1. Frequency accuracy shall exceed 1 Hz.
2. Level accuracy shall exceed 0.5 dB.
3. Timing information shall exceed 1 ms accuracy.
A.5 Universal Tone Detector
A.5.l Overview
The Universal Tone Detector (UTD) is a high configurable tone detector. By
changing parameters, this algorithm can classify a wide range of single and dual
tone call progress signals generated in a wide variety of countries.
A.5.2 General
Since different tones need different detection heuristics, and tones may have
multiple specifications, each tone is tagged with a tone category identifier.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 27
-----------------------------------------------
Tone Category Call Progress Signal
-----------------------------------------------
1 Modem
2 FAX CNG
3 Audible Ringback
4 Busy
5 Reorder or Congestion
6 Number Unobtainable
7 SIT
8 Dial tone
9 Unknown Tone
-----------------------------------------------
Table A-3: Tone Categories
In addition to specifying a tone category, the parameters include a value that
is returned to the application when the tone is detected. This parameter need
not be unique. This allows multiple specifications to report the same tone event
to the application. UTD is table driven. Using this approach, the tone detector
searches parameter tables for a matching tone. When a tone matches, the tone
code determines the heuristics necessary to completely classify the tone. Also,
the tones must be specified in a way that a set of parameters corresponds to
either a single tone, a dual tone, or an amplitude modulated tone.
---------------------------------
Code Tone Type
---------------------------------
0 Single Tone
1 Dual Tone
2 Modulated Tone
---------------------------------
Table A-4: Call Progress Tone Types
A.5.3 General Functional Requirements
UTD functionally combines a single tone detector and a dual/modulated tone
detector into a single module. UTD combines the results of these detectors into
a single result. UTD has the following requirements.
1. The DSP shall indicate that the first ringback has started after at
least 400 ms of ringback like signal has been processed, as long as no
other tone type is early detected. If more than one type of tone is
early detected, the first ringback reporting shall be delayed until
either cadence information disqualifies the other types, or tone
precedence is used as a 'tie-breaker'.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 28
2. The DSP shall indicate ringback has stopped when ringback is no longer
detected.
3. The DSP shall indicate a busy tone has been detected after the
requisite number of make and break intervals have been processed, and
no other tone category is still a candidate for detection.
4. The DSP shall indicate a reorder tone has been detected after the
requisite number of make and break intervals have been processed, and
no other tone category is still a candidate for detection.
5. The DSP shall indicate a number unobtainable tone has been detected
after the requisite number of make and break intervals have been
processed, and no other tone category is still a candidate for
detection.
6. In the event that more than one tone is a candidate for detection,
detection is delayed until all characteristics that may disqualify any
of the candidates are tested (for example, waiting for multiple cadence
pairs to occur). If there is still more than one potential tone after
all differentiating features have been exhausted, then the tone with
the highest precedence is detected. Also, if the tone ceases prior to
singling out one candidate tone, then the tone with the highest
precedence is detected. Precedence is shown in Table A-3.
7. The DSP shall supply an early detect flag. This flag shall be valid
after the detector has processed no more than 72 ms of a tone. If more
than one tone category is early detected, then the early detect flag
shall indicate the tone category with the highest precedence.
8. The DSP shall indicate that a modem has been detected if a single tone
falls within the specified frequencies for modem tones, the minimum
make interval has been exceeded while the average tone power is in
excess of the minimum power requirement, and no other tone category is
still a candidate for detection.
9. The DSP shall indicate that a FAX CNG tone has been detected if a
single tone falls within the specified frequencies for a CNG tone, the
requisite number of on/off cadences have been processed, and no other
tone category is still a candidate for detection.
10. The DSP shall indicate that a SIT tone has been detected if at least
two of the three segments of possible SIT tones have been detected for
at least the minimum interval in excess of the minimum power
requirement.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 29
11. The DSP shall indicate that an Unknown tone has been detected when it
has been determined that a tone has been detected that falls within the
specified frequencies for an Unknown tone, the minimum duration has
been exceeded, and the tone does not match and other category tones.
A.5.3.1 TONE DETECTOR PERFORMANCE REQUIREMENTS
A.5.3.1.1 Single Tones
There are four types of parameters that shall be used to control single tone
detection. The variation of each parameter shall be limited by the constraints
listed in Table A-5.
------------------------------
Minimum Maximum
--------------------------------------------------------------
Frequency 300 Hz 3300 Hz
--------------------------------------------------------------
Bandwidth 0 Hz 1800 Hz
--------------------------------------------------------------
Duration 100 msec 32760 msec
--------------------------------------------------------------
Minimum Power Level -45 dBm 3 dBm
--------------------------------------------------------------
Table A-5: Single Tone Detection Constraints
The frequency detection range shall be specified the Frequency and Bandwidth
parameters. Figure A-2 shows the relationship of these parameters. Note that the
bandwidth specification is symmetric about the center frequency. The Frequency
and Bandwidth parameters define a "must detect" range. The detector shall not
use frequency criteria to reject any tones which are within the range specified
Frequency/Bandwidth parameters. Tones whose frequencies are outside but close to
frequency range may be detected.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 30
INSERT GRAPH
Figure A-2: Frequency Domain Representation of tone parameters for a
Single Tone
If the Power Level of the detected parameter is greater than the minimum power
specified by the parameters, the signal shall not be rejected by Power Level
heuristics. Duration parameters are used to set the allowable duration of a
tone. Minimum and maximum tone durations may be specified (make durations).
Also, minimum and maximum silence durations between tones may be specified.
A.5.3.1.2 Dual Tones
Dual tones are created by summing two sinusoids. Since each tone can be isolated
in the frequency domain, dual tones are specified as a pair of single tones.
Parameters for each tone of a dual pair use the same constraints as single
tones. Namely, frequency1 is the center frequency of the lower tone, and
bandwidth1 specifies its frequency tolerance. The same is true for frequency2
and bandwidth2 for the high tone. Figure A-3 shows the definition of the
frequency and bandwidth parameters for a dual tone.
INSERT GRAPH
Figure A-3: Frequency Domain Representation of Tone Parameters for a Dual Tone
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 31
Not all dual tones are detectable by UTD. A dual tone shall detected only when
the difference between the two component frequencies is greater than 10 Hz and
less than 230Hz.
A.5.3.1.3 Amplitude Modulated Tones
Amplitude modulated tones are created by multiplying two sinusoids. When
analyzed in the frequency domain, a modulated tone looks like three tones.
Figure A-4 shows the frequency spectrum for a modulated tone.
The tone whose frequency is the average of the other tones is the carrier. The
other two tones can be referred to as side lobes. For amplitude modulated tones,
frequencyl and bandwidth1 specify the low sidelobe and its tolerance, while
frequency2 and bandwidth2 specify the high sidelobe and its tolerance.
INSERT GRAPH
Figure A-4: Frequency Domain Representation of Tone Parameters
for an Amplitude Modulated Tone
As with dual tones, not all modulated tones will be detected by UTD. Modulated
tones shall be detected if the difference between the carrier frequency and the
sidelobes is between 10 Hz and 230 Hz.
A.5.3.l.4 Precedence
By assigning a detection precedence to the classification process, tone
frequency ranges can overlap. When a tone's parameters fall into a range shared
by two or more signals, the signal is classified as the one with the highest
precedence.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 32
-------------------------------------------
Precedence Call Progress Signal
-------------------------------------------
1 Modem
2 FAX CNG
3 Audible Ringback
4 Busy
5 Reorder or Congestion
6 Number Unobtainable
7 SIT
8 Dial Tone
9 Unknown Tone
-------------------------------------------
Table A-6: Tone Detection Precedence
Table A-6 shows the precedence of typical tones that the UTD module detects.
Modem signals have the highest precedence, and Unknown tones have the lowest.
Therefore, the frequency range of unknown tones can safely overlap the other
tone ranges without causing tones to be misclassified. If the range for Unknown
tones is allowed to be the maximum range allowed by the detector, any detected
tone that is unclassified would be designated as Unknown.
A.5.3.1.5 North American Call Progress Signal Detection
Functional Requirements:
The tables below specify the frequencies, power levels, and cadence of the
Bellcore and EIA-464A call progress tones.
- --------------------------------------------------------------------------------
Frequency (Hz) Power Level (dBm)
- --------------------------------------------------------------------------------
Name 350 440 480 620 Per Frequency Combined
- --------------------------------------------------------------------------------
Audible Ring X X -22.5 +/- 1.5
- --------------------------------------------------------------------------------
Busy X X -27 +/- 1.5
- --------------------------------------------------------------------------------
Dial Tone X X -17.5 to -15 -13 to -14.5
- --------------------------------------------------------------------------------
Intercept X X -20 +/- 1.5
- --------------------------------------------------------------------------------
Reorder X X -27 +/- 1.5
- --------------------------------------------------------------------------------
Table A-7: Call Progress Tone Frequency and Power Requirements
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 33
- -------------------------------------------------------------------------------
Audible ring (ring- repetition of the tone on for 0.8 to 2.2 seconds, and
back) off for 2.7 to 4.4 seconds
- -------------------------------------------------------------------------------
Busy repetition of the tone on for 0.5+/-0.05 seconds, and
off for 0.5 +/-0.05 seconds
- -------------------------------------------------------------------------------
Dial steady uninterrupted
- -------------------------------------------------------------------------------
Intercept repetition of an alternating sequence, of the two
frequencies each being on for 0.16 to 0.30 seconds
with a total cycle time of 0.5 +/-0.05 seconds
- -------------------------------------------------------------------------------
Reorder (fast busy) repetition of the tone on for 0.25+/-0.025 seconds,
and off for 0.25+/-0.025 seconds
- -------------------------------------------------------------------------------
Table A-8: Call Progress Tone Cadence
Performance Requirements:
1. Frequency Deviation: Even though the generator is required to meet a
frequency tolerance per tone of +/-0.5%, the detector needs to allow
for a wider frequency tolerance due to variations in generators and
line distortions. The CP detector detects all tones whose component
frequencies deviate less than 1% from nominal.
2. Twist: The CP detector detects all tones whose twist is less than +/-4
dB.
3. Dynamic Range: The CP detector exhibits a minimum dynamic range of
25 dB.
4. Cadence: The CP detector must detect call progress tones whose cadence
is within +/-10%.
5. Talkoff: The CP detector makes no false detections in 12 hours of
testing with voice at -15 to -18 dBm ASL.
A.5.3.1.6 FAX CNG Tone Detection
The standard connection protocol for automatic connection of a FAX modem
requires that the calling FAX modem generate a calling tone (CNG). Hence for
incoming calls, the EVP software has to detect a CNG signal. When CNG is
detected, EVP alerts the Core Processor to redirect the call to a FAX machine or
a FAX modem embedded within the call processing system.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 34
Functional Requirements:
Detect the presence of the FAX calling tone (CNG). A CNG signal is defined as
follows.
INSERT GRAPH
Figure A-5: Fax calling tone (CNG)
a) The CNG tone is within 38 Hz of nominal frequency.
b) The timing tolerance of a CNG tone is +/-15%.
c) The power of a CNG tone is between 0 and -43 dBm.
Performance Requirements:
1. The detector does not miss any CNG signals on a prerecorded tape
containing 50 CNG tone samples collected from S different FAX machines.
2. The detector does not miss any CNG signals from the same FAX machines
connected to a local CO with a noise level of less than -45 dBm.
3. The detector misses less than 0.5% of CNG signals (generated at -10
dBm) when compressed voice is output at a level of-15 dBm or less
(average over 3 seconds) into a network whose ERL is greater than 15
dB.
4. The detector does not falsely detect more than 1 CNG tone per 5 hours
of voice (based on Bellcore recorded talk radio voice tapes.)
A.5.3.1.7 Modem Tone Specification
All answering modems that conform to the ITU V.25 answering sequence present a
2100 Hz tone 1.8 to 2.5 seconds after answering the telephone line. Figure A-6
and Figure A-7 show the timing of the answering tone (ANS). In Figure A-6, the
2100 Hz
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 35
tone reverses phase every [tau] intervals. These phase reversals disconnect echo
cancellers and echo suppressors from the network. According to ITU G.164, phase
reversal shall be accomplished such that the phase is within 180 +/-10 degrees
in 1 ms and that the amplitude of the 2100 Hz tone is not more than 3 dB below
its steady state value for more than 400 musec.
INSERT GRAPH
Figure A-6: Timing for Answering Modem with Phase Reversal
A timing diagram for an answering modem without phase reversal is shown in
Figure A- 7. The timing is identical with that of phase reversing tone except
for the reversal timing.
INSERT GRAPH
Figure A-7: Timing for Answering Modem without Phase Reversal
Table A-9 contains the nominal frequency, power, and duration requirements for
------------------------------------------------
Minimum Maximum Unit
---------------------------------------------------------------------
Frequency 2085 2115 Hz
---------------------------------------------------------------------
Duration 2.6 4.0 seconds
---------------------------------------------------------------------
Power -18.0 -6.0 dBm0
---------------------------------------------------------------------
generating modem tones as derived from V.25 and G.164.
Table A-9: Modem Tone Generation Requirements
Performance Requirements:
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 36
1. The detector does not miss any modem answer tone on a pre-recorded tape
containing 50 modem answer tone samples collected from 5 different data
modems.
2. The detector does not miss any modem answer tone signals from the same
data modem connected via a local CO with a noise level of less than -45
dBm.
3. The detector does not miss more than 0.5% of modem answer tones
(generated at -10 dBm) when compressed voice is played at a level of
-15 dBm (ASL) or lower into a network connection with ERL greater than
15 dB.
4. The detector does not falsely detect the presence of a modem answer
tone more than once per 5 hours of voice (using Bellcore recorded talk
radio voice tapes).
5. There is no talkdown performance requirement. The near end is always
silent and does not interfere with far end modem ANS signals.
6. There shall be fewer than 1 talkoff in 5 hours of call classification
when the detector is programmed with the recommended parameters.
Assuming that each call is resolved within an average time of 10
seconds, there shall be less than 1 talkoff in 1800 calls.
A.5.3.1.8 Three Tone Sequences
Most countries that generate Special Information Tones (SIT) use a three tone
sequence. SIT sequences are generated by various central offices or common
carrier switching points to indicate a problem with the dialed call. A SIT tone
sequence generally precedes a recorded voice announcement such as "the number
you have dialed is no longer in service..." and is provided specifically for the
purpose of detection of the problem type by an automated device.
There are two popular types of SIT sequences. The first type is used mainly in
Europe. It consists of a sequence of three tones of identical durations. The
second type is the one used in North America. There are several North American
SIT sequences that are encoded using various combinations of frequency and
duration for each of the three tones. The encoding has been standardized by
Bellcore.
Performance Requirements:
1. The UTD shall handle both types of sequences.
2. There is no talkdown performance requirement. The near end is always
silent and does not interfere with far end SIT signals.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 37
3. There shall be fewer than 1 talkoff in 5 hours of voice when the
detector is programmed with the recommended parameters. Assuming that
each voice call is has an average of 2 seconds of voice, there shall be
fewer than 1 talkoff in 9000 calls.
A.5.3.1.9 Unknown Tone
Any single tone, dual tone, amplitude modulated tone or single tone sequence
that is not classified as a CP, SIT, CNG or modem ANS tone, shall be reported as
an unknown tone.
Performance Requirements:
1. Talkdown performance requirement [TBD]
2. There shall be fewer than 1 talkoff in 5 hours of voice when the
detector is programmed with the recommended parameters (minimum tone
duration 400 ms). Assuming that each voice call is has an average of 2
seconds of voice, there shall be fewer than 1 talkoff in 9000 calls.
A.6 Multifrequency Tone Detection (MFD)
The MFD algorithm module detects the presence of Rl, R2 Forward, and R2 Backward
Multi frequency (MF) tones under a broad range of network conditions and under
international telecommunications specifications.
A.6.1 Functional requirements:
Table A-10, Table A-11, and Table A-12 specify the nominal frequencies for the
MF digits that must be detected.
- -----------------------------------------------------------------------
F1 (Hz) F2 (Hz)
900 1100 1300 1500 1700
-------------------------------------------------------------
700 1 2 4 7 Spare
900 -- 3 5 8 Spare
1100 -- -- 6 9 KP
1300 -- -- -- 0 Spare
1500 -- -- -- -- ST
- -----------------------------------------------------------------------
Table A-10: Nominal MF R1 Frequencies and corresponding digit definitions
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 38
- -----------------------------------------------------------------------
F1 (Hz) F2 (Hz)
1500 1620 1740 1860 1980
-------------------------------------------------------------
1380 1 2 4 7 11
1500 -- 3 5 8 12
1620 -- -- 6 9 13
1740 -- -- -- 10 14
1860 -- -- -- -- 15
- -----------------------------------------------------------------------
Table A-11: Nominal MF R2 Forward Frequencies and corresponding combination
numbers
- -----------------------------------------------------------------------
F1 (Hz) F2 (Hz)
1020 900 780 660 540
-------------------------------------------------------------
1140 1 2 4 7 11
1020 -- 3 5 8 12
900 -- -- 6 9 13
780 -- -- -- 10 14
660 -- -- -- -- 15
- -----------------------------------------------------------------------
Table A-12: Nominal MF R2 Backward Frequencies and corresponding combination
numbers
1. Be configurable to detect either R1, R2 forward, or R2 backward MF
digits on a per-call basis.
2. Detect the presence of all 15 R1, 15 R2 Forward, and 15 R2 Backward
digits under a broad range of network conditions.
3. MF digit information is provided as soon as the minimum duration is
met. This information is called leading edge detection. This allows the
earliest possible response to the digit, such as in compelled
signaling.
4. The trailing edge of a MF digit must be detected. This allows the
system to delay any response (such as in compelled signaling) to the
digit until it is removed. The criteria selected for trailing edge
detection will debounce MF digits.
5. The DSP reports leading and trailing edge in the 8 ms block that they
are detected. MF events are not buffered.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 39
A.6.2 R1 Detection Performance requirements:
Table A- 13 consists of MF R1 tone detection performance requirements taken from
CCITT/ITU Q310-Q331 and Bellcore TR-NWT-000506. Also shown is D2's MF R1
performance requirements, which is a superset of the CCITT and Bellcore
requirements.
<TABLE>
<CAPTION>
- ------------------------------------------------------------------------------------------------------------------
Requirement
- ------------------------------------------------------------------------------------------------------------------
Characteristic Bellcore CCITT/ITU D2
- ------------------------------------------------------------------------------------------------------------------
<S> <C> <C> <C>
Frequency Deviation +/-(1.5% + 5 Hz) must +/-1.5% must accept Configurable choice of
accept three sets of must
accept frequency
tolerance:
+/-(1.5% + 5 Hz),
+/-(1.5% + 10 Hz),
+/-(1.5% + 15 Hz)
- ------------------------------------------------------------------------------------------------------------------
Tone Duration KP signal >/= 54 ms >/=30 ms must accept Minimum duration is
must accept; </=30 ms </=10 ms must reject configurable in 4 ms
must reject steps, from 28 ms up.
All others: >/=30 ms Can be configured for
must accept; </=10 ms >/=30 ms must accept;
must reject </=10 ms must reject
- ------------------------------------------------------------------------------------------------------------------
Minimum Interdigital Must accept Must accept Minimum interdigital
Interval interdigital intervals interdigital intervals interval is configurable
>/=25 ms. Must bridge >/=20 ms in 4 ms steps. Can be
interdigital intervals configured for >/=20 ms
</=10 ms accept; </=10 ms bridge
- ------------------------------------------------------------------------------------------------------------------
Minimum Cycle Time Up to 10 pulses per - >10 pulses per second
second (100 ms cycle (<100 ms cycle time)
time)
- ------------------------------------------------------------------------------------------------------------------
Accept Levels 0 to -25 dBm must - Minimum power is
accept configurable from -25
</=-35 dBm must reject dBm to -45 dBm per
frequency
- ------------------------------------------------------------------------------------------------------------------
Twist (ratio of high </=6 dB twist must </=6 dB twist must </=6 dB twist must
group power to low) accept accept accept
- ------------------------------------------------------------------------------------------------------------------
SNR (white noise) 20 dB - 20 dB
- ------------------------------------------------------------------------------------------------------------------
Impulse Noise Fewer than 14 missed - Fewer than 14 missed
or split digits in or split digits in
Bellcore Impulse Noise Bellcore Impulse Noise
Tape No. 201 Tape No. 201
- ------------------------------------------------------------------------------------------------------------------
</TABLE>
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 40
<TABLE>
<S> <C> <C> <C>
- ------------------------------------------------------------------------------------------------------------------
Disturbing Frequencies Detection in the - Detection in the
presence of 2A-B and presence of 2A-B and
2B-A modulation 2B-A modulating
products 28 dB below products 28 dB below
each frequency each frequency
component level of the component level of the
signals. signals
- ------------------------------------------------------------------------------------------------------------------
</TABLE>
Table A-13: MFD R1 Detection Performance Requirements
A.6.3 R2 Detection Performance Requirements
Table A- 14 shows the MF R2 tone detection performance requirements taken from
CCITT/1TU Q400-490. The MFD module is required to pass all CCITT/ITU
requirements.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 41
<TABLE>
<CAPTION>
- --------------------------------------------------------------------------------------------------------
Characteristic CCITT/ITU Requirement CCITT/ITU Requirement
- --------------------------------------------------------------------------------------------------------
<S> <C> <C>
Frequency Deviation +/-10 Hz must accept Configurable choice of three
- --------------------------------------------------------------------------------------------------------
sets of must accept frequency
tolerance:
+/-10 Hz
+/-15 Hz
+/-20 Hz
- --------------------------------------------------------------------------------------------------------
Tone Duration Must reject signals </= 7 ms Must reject signals </= 7ms
- --------------------------------------------------------------------------------------------------------
Minimum response time for R2 detect delay + generate detect delay + generate delay
compelled signaling delay </= 70 ms </= 70 ms
detect delay + decision detect delay + decision delay +
delay + generate delay </= 80 ms generate delay </= 80 ms
- --------------------------------------------------------------------------------------------------------
Accept Levels -5 dBm0 to -31.5 dBm0 must Minimum power is
detect; configurable from -25 dBm to
-38.5 dBm0 must reject -45 dBm per frequency
- --------------------------------------------------------------------------------------------------------
Twist (ratio of high group </= 5 dB twist must accept for </= 5 dB twist must accept
power to low) adjacent frequencies; for adjacent frequencies;
</= 7 dB twist must accept for </= 7 dB twist must accept
non-adjacent frequencies; for non-adjacent frequencies
20 ddB twist must reject 20 dB twist must reject
- --------------------------------------------------------------------------------------------------------
</TABLE>
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 42
<TABLE>
- --------------------------------------------------------------------------------------------------------
<S> <C> <C>
Disturbing Frequencies Must not falsely detect due to Must not falsely detect due to
any one or more valid R2 any one or more valid R2
frequencies at -55 dBm per frequencies at -55 dBm per
frequency. frequency.
In the presence of a valid R2 In the presence of a valid R2
tone, no missed detections and tone, no missed detections and
no false detections due to any no false detections due to any
of the remaining frequencies at of the remaining frequencies at
20 dB below the highest of the 20 dB below the highest of the
MF tone pair. MF tone pair. Must not falsely
Must not falsely detect due to: detect due to:
1. Any 1 or 2 pure sine waves, 1. Any 1 or 2 pure sine waves,
each at -38.5 dBm0, 300-3400 each at -38.5 dBm0, 300-3400
Hz. Hz.
2. Any 1 or 2 pure sine waves, 2. Any 1 or 2 pure sine waves,
each at -42 dBm, 300-3400 Hz. each at -42 dBm, 300-3400 Hz.
3. Forward detector: Any 2 3. Forward detector: Any 2
pure sine waves, each at -5 pure sine waves, each at -5
dBm, 330-1150 Hz or 2130-3400 dBm, 330-1150 Hz or 2130-3400
Hz. Hz.
4. Backward detector: Any 2 4. Backward detector: Any 2
pure sine waves, each at -5 pure sine waves, each at -5
dBm, 1300-3400 Hz. dBm, 1300-3400 Hz.
- --------------------------------------------------------------------------------------------------------
Transmitted signal interference Must not falsely detect due to Must not falsely detect due to
generation of outgoing MF generation of outgoing MF
digits. digits.
- --------------------------------------------------------------------------------------------------------
</TABLE>
Table A-14: MFD R2 Detection Performance Requirements
A.7 MFcR2 compelled signaling
In order to pass the CCITT requirements for compelled signal timing, the
following additional requirements are made on the MFD detector:
1. The MFD detector shall detect the leading edge of an R2 digit after
processing no more than 24 ms of the digit.
2. The MFD detector shall detect the trailing edge of an R2 digit after
processing no more than 16 ms of the silence following the digit.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 43
EXHIBIT B
LICENSEE PRODUCT DESCRIPTION
Service Resource Module (SRM) for high density programmable switching systems.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 44
EXHIBIT C
DEVELOPMENT, MAINTENANCE, AND RUNTIME LICENSE FEE SCHEDULE
DEVELOPMENT LICENSE FEES: LICENSED TECHNOLOGY FOR THE BASIC SERVICES SPECIFIED
IN EXHIBIT A
Development license fees are specified in PO #104962.
50% of which has already been paid to D2 and the final 50% to be paid upon the
delivery and acceptance of the Licensed Technology for Basic Services by
Licensee in accordance with Article 4 of this Agreement.
MAINTENANCE FEES: LICENSED TECHNOLOGY FOR THE BASIC SERVICES SPECIFIED IN
EXHIBIT A
The Maintenance Fee after the expiry of the Warranty period shall be $20,000 per
year, starting from the date after the Warranty period (Contract Year),
renewable at the end of each Contract Year.
In the event that during the four consecutive calendar quarters which begin
immediately after the start of a Contract Year, LICENSEE completes payments to
D2 of one hundred thousand dollars in Runtime License Fees under this Agreement,
D2 will apply a credit equaling to 100% of the Maintenance Fee against the
Runtime License Fees of that Contract Year.
In the event that LICENSEE exercises the Buy Out option for Runtime License
Fees, there shall be no Maintenance Fee for the first three years after the
expiry of the Warranty period.
RUNTIME LICENSE FEES: LICENSED TECHNOLOGY FOR BASIC SERVICES SPECIFIED IN
EXHIBIT A AND SIMPLE CONFERENCING TECHNOLOGY
A runtime license fee shall be paid for each SRM in the Licensee Product
(Exhibit B) which contains the Licensed Technology for Basic Services and simple
conferencing which does not require network echo cancellation technology
(Exhibit A) sold by LICENSEE. Licensee Products which do not run the Licensed
Technology are not subject to runtime license fees.
The runtime license fee is based on the number of ports of service that a
customer can expect the SRM to provide. As such, this runtime license fee
calculation may be used for an SRM with any number of DSP processors (DSPs),
with any MIPS
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 45
performance rating, as long as it is from the TI TMS320C54x, TMS320C55x, or
TMS320C6x processor family.
Fee_per_SRM = Fee_per_Port * DSPs_per_SRM * Average_Ports_per_DSP
Where:
Fee_per_SRM is the runtime license fee for each SRM.
Fee_per_Port is on Table 1.
DSPs_per_SRM is the number of DSPs on each SRM.
Average_Ports_per_DSP is defined below.
-----------------------------------------------------------
total quantity of processors licensed Fee_per_port
-----------------------------------------------------------
1-5,000 $2.00
-----------------------------------------------------------
5,001 - 25,000 $1.00
-----------------------------------------------------------
25,001 - 50,000 $0.75
-----------------------------------------------------------
5,001 - 75,000 $0.50
-----------------------------------------------------------
> 75,000 $0.00
-----------------------------------------------------------
Table 1. Fee per port
If LICENSEE commits to purchase licenses for a minimum of 10,000 processors for
the first year after first customer shipments, the fee_per_port will be reduced
for $1.00 for the first 5,000 processors.
The SRM will provide 5 Basic Services and simple conferencing (which does not
require network echo cancellation):
1. DTG -- Digital Tone Generation (static channels and outpulsing)
2. CPA -- Call Progress Analysis (with Voice Activity Detection)
3.- DRC -- DTMF Detection
4. MFR(1) -- Multifrequency Reception (1)
5. MFCR2 -- Multifrequency Reception and Transmission, Compelled R2
To determine the Average ports per DSP, the completed software will be tested in
a heavily-loaded VCO/20 to determine the maximum number of ports that a single
DSP processor performing each of the Basic Services can reliably satisfy. This
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 46
maximum will be documented in Table 2 below, and will be encoded in software, to
prevent a customer from exceeding it.
This maximum will vary depending on the DSP processor speed, so a separate
measurement will have to be done for SRMs containing faster processors. Due to
system limitations, this number will never exceed 63.
The number of ports supported for each of the Basic Services, per DSP processor,
will be averaged (arithmetic mean) to create an average number of ports per DSP
(Average_Ports_per_DSP). Because of the computational simplicity of the DTG
Service, it will not be included in this calculation:
Average_Ports_per_DSP = (#CPA + #DRC + #MFR1 + #MFCR2)/4
- --------------------------------------------------------------------------------
Service Predicted Measured Included in
Maximum # Ports Maximum # Ports Average?
- --------------------------------------------------------------------------------
DTG 63 To be measured Not included
- --------------------------------------------------------------------------------
CPA 30 To be measured Included
- --------------------------------------------------------------------------------
DRC 30 To be measured Included
- --------------------------------------------------------------------------------
MFR1 30 To be measured Included
- --------------------------------------------------------------------------------
MFCR2 30 To be measured Included
- --------------------------------------------------------------------------------
TABLE 2. MEASURED PERFORMANCE OF SERVICES
CAP: The runtime license fees is fully paid up after it reaches the CAP, which
is the cumulative runtime license fees paid by LICENSEE for the first 75,000
processors as specified in Table 1 above. The CAP is cumulative across the Texas
Instruments TMS320C54x, TMS320CSSx, and TMS320C6x, and other TI processors based
on the same core processor architecture.
BUYOUT OPTION: Within the Warranty period, LICENSEE may elect to pay D2 a sum of
$1,400,000 as a one time paid-up runtime license fees for the Basic Services
specified in Exhibit A.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 47
EXHIBIT D
MODEL LICENSEE AGREEMENT FOR LICENSEE PRODUCT
SOFTWARE LICENSE
Licensed Technology incorporated in LICENSEE Product, together with Updates and
New Versions thereof, are provided to LICENSEE's Customer under a non-exclusive
worldwide license subject to the following terms:
1. LICENSEE's Customer shall have the right to distribute copies of the Licensed
Technology to end users in Object Code form either directly or indirectly
through others for use in connection with the LICENSEE Product. LICENSEE's
Customer shall require that such end users agree to protect D2's and LICENSEE's
intellectual property rights in the Licensed Technology as set forth in this
LICENSEE's Customer Agreement.
2. LICENSEE's Customer shall have the right to reproduce the Licensed Technology
for distribution and make a reasonable number of copies of the Licensed
Technology for backup or archival purposes.
3. LICENSEE's Customer shall not have the right to modify, reverse engineer,
decompile or derive Source Code from the Licensed Technology, nor shall
LICENSEE's Customer permit any third party to do so. LICENSEE's Customer shall
not have the right to disclose the Licensed Technology except as permitted
herein.
4. LICENSEE's Customer shall have the right to transfer a licensed copy of the
Licensed Technology to a third party provided LICENSEE's Customer does not
retain any copies of such licensed copy and the third party agrees to abide by
the terms and conditions of this LICENSEE's Customer Agreement. All Licensed
Technology must be transferred upon a change in title of any hardware in which
it was installed.
5. LICENSEE's Customer agrees that D2 or LICENSEE retain the entire right and
title to Licensed Technology.
6. The provisions of this Article (paragraphs 1 through 6 preceding) shall
survive the termination or expiration of this LICENSEE's Customer Agreement.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 48
EXHIBIT E
1. Development and Back-up Computers
Computer Manufacturer and Model Serial Number Dev/Backup
(1) -- --
(2) -- --
(3) -- --
1. FORMAT OF Licensed Software Media
(1) -- --
(2) -- --
(3) -- --
Date:
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
<PAGE> 49
EXHIBIT F
Acceptance Test Specification
To be provided by D2 and LICENSEE within 90 days of effective date of this
Agreement.
Software License D2 Technologies, Inc.
and Maintenance Agreement August 4, 1997 CONFIDENTIAL
