Sample Business Contracts

Agreement for Services - Intrado Inc. and Vonage Network Inc.

Services Forms

Sponsored Links

AGREEMENT FOR SERVICES

This Agreement for Services (“Agreement”) is entered into by and between Intrado Inc. (“Intrado”) and the party signing below (“Customer”), as of the April 27, 2005. This Agreement consists of these terms and conditions and any order, statement of work, exhibit, or similar document executed under this Agreement (each, an “Attachment”). Intrado and Customer are referred to herein collectively as “Parties” and individually as “Party.”

1. SERVICES. Intrado will provide to Customer the services specified in Attachment A - VoIP 9-1-1 Gateway Services with V9-1-1^SM Mobility Services for City of New York Statement of Work for Vonage Network Inc. and Attachment B - VOIP V9-1-1^SM Mobility Services for Vonage Network Inc. (“Services”).

2. TERM. This Agreement will commence as of the date first set forth above and, as to each Attachment, will continue until the expiration or termination of such Attachment.

3. PAYMENT.

a. Customer will pay the fees described in the Attachment. Except as specified in the applicable Attachment, (i) recurring fees will be billed monthly; (ii) non-recurring fees will be billed within thirty (30) days of the applicable Attachment effective date; and (iii) except with regard to disputed amounts as permitted in 3(d below, all invoices will be due and payable within thirty (30) days of invoice date. If Customer generates purchase orders, Customer will use commercially reasonable efforts to provide appropriate purchase orders to Intrado.

b. Customer will bear all taxes, duties, and other government charges imposed on Customer’s purchase of the Services (including interest and penalties to the extent caused by Customer’s actions or omissions), except taxes based on Intrado’s income, employment or property. Customer will support any Customer claim of tax exemption with appropriate documentation.

c. Interest will accrue on past-due balances as of the date of delinquency at the lower of: (i) one-half percent (0.5%) per month, or (ii) the highest rate permitted by applicable law. If Services are discontinued due to nonpayment of fees and subsequently recommenced, a reconnection fee or deposit will apply, in addition to applicable interest and will be provided to Customer prior to any such reconnection.

d. If Customer disputes an invoice in good faith, Customer may withhold the disputed amount, not to exceed one month’s recurring fees for such Service, provided that Customer must: (a) notify Intrado within thirty (30) days of any such invoice, specifying the nature of the dispute or inaccuracy; and (b) pay any undisputed amounts as provided herein. Both Parties will in good faith investigate and attempt to promptly resolve any disputed invoices. Once resolved, Customer will promptly pay any amounts owed and Intrado will promptly refund any amounts it has collected to which it is not entitled.

e. No set-off, deduction, or cross-collateralization will be permitted hereunder. However, Intrado may require prepayment or additional security if Customer becomes insolvent, is unable to pay its debts when due, or is the subject of a bankruptcy or receivership proceeding.

4. CONFIDENTIALITY.

a. During the course of this Agreement, either Party may receive or have access to Confidential Information of the other. “Confidential Information” means any confidential information or data disclosed by a Party (“Disclosing Party”) to the other Party (“Recipient”) under or in contemplation of this Agreement, which (a) if in tangible form or other media that can be converted to readable form is clearly marked as Confidential, proprietary, or private when disclosed; or (b) if oral or visual, is identified as Confidential, proprietary, or private on disclosure or (c) if not so marked or identified, is such that a reasonable businessperson would understand it to be confidential by reason of its nature or content. The terms “Disclosing Party” and “Recipient” include each Party’s corporate affiliates that disclose or receive Confidential Information. Each Party will cause its affiliates to comply with the obligations of this Section 4, and each Party agrees that it is responsible for its affiliates’ compliance with this Section 4. Actions or omissions by a Party’s affiliate, that if taken by said Party would constitute a breach of this

Pages where confidential treatment has been requested are stamped, "Confidential treatment has been requested. The redacted material has been separately filed with the Commission." All redacted material has been marked by an asterisk (*).

Section 4, will be considered actions or omissions of said Party. The Recipient acknowledges the economic value of the Disclosing Party’s Confidential Information. The Recipient therefore, will: (i) use the Confidential Information only in connection with the Recipient’s performance of its obligations or in exercising its rights under this Agreement; (ii) restrict disclosure of the Confidential Information to employees of the Recipient and its affiliates with a “need to know” and not disclose it to any other person or entity without the prior written consent of the Disclosing Party; (iii) advise those employees who have access to the Confidential Information of their obligations with respect thereto; (iv) treat the Confidential Information with at least the same degree of care to avoid disclosure to any third party as is used by Recipient with respect to its own information of like importance which is to be kept secret; and (v) copy the Confidential Information only as necessary for those employees who are entitled to receive it and ensure that all confidentiality notices are reproduced in full on such copies.

b. For the purposes of this Section 4 only, “employee” includes third parties retained by the Parties for temporary consultative, administrative, clerical, programming or related Services support. A “need to know” means that the employee reasonably requires the Confidential Information to perform his or her responsibilities in connection with this Agreement.

c. “Confidential Information” will not include, and the obligations of this Section 4 will not apply to, any information or data which the Recipient can demonstrate: (i) is or becomes available to the public through no breach by Recipient of this or any other agreements between the Parties; (ii) before its disclosure hereunder, was known by the Recipient without any obligation owing to the Disclosing Party (directly or indirectly) to hold it in confidence; (iii) is received from a third party who does not owe any duty to the Disclosing Party (directly or indirectly) with respect to such information; (iv) is independently developed by the Recipient without the use of Confidential Information of the Disclosing Party; or (v) is approved for release by written authorization of the Disclosing Party but only to the extent of such authorization and without any disassembly, reverse engineering, or similar undertaking by Recipient. If Recipient is required by law or regulation to disclose Confidential Information of the Disclosing Party, Recipient may do so, but only to the extent and for the purposes of such required disclosure, and only if the Recipient first promptly notifies the Disclosing Party of the need for such disclosure and allows the Disclosing Party a reasonable opportunity to seek an appropriate protective order.

d. Confidential Information, including copies, will be deemed the property of the Disclosing Party. The Recipient will, within twenty (20) days of a written request by the Disclosing Party return all Confidential Information (or any designated portion thereof), including all copies thereof, to the Disclosing Party or if so directed by the Disclosing Party, destroy such Confidential Information. The Recipient will also, within ten (10) days of a written request by the Disclosing Party, certify in writing that it has satisfied its obligations under this Section.

e. Each of the parties acknowledges and agrees that irreparable harm could result if any obligation under this Section 4 is not performed by a Recipient and accordingly, the Disclosing Party shall be entitled to seek such injunctive or equitable relief as may be deemed proper by a court of competent jurisdiction to prevent disclosure of its Confidential Information. The Disclosing Party shall not be deemed to have made an election of remedies by obtaining, or seeking to obtain, injunctive or equitable relief.

5. LIMITED WARRANTY.

a. Intrado warrants that Services (i) will meet the applicable specifications in the Attachment(s); and (ii) will be provided in a professional and workmanlike manner by individuals with suitable skills and abilities. Intrado will use commercially reasonable efforts to re-perform any Services not meeting this limited warranty promptly following notice from Customer. Intrado does not warrant products, equipment, hardware, or software not manufactured or developed by Intrado, but will, to the extent permitted, assign to Customer any warranties given to Intrado by the applicable vendor(s).

b. EXCEPT AS EXPRESSLY PROVIDED HEREIN, INTRADO MAKES NO EXPRESS OR IMPLIED WARRANTIES, INCLUDING ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. THE REMEDY STATED ABOVE IS CUSTOMER’S SOLE REMEDY FOR A BREACH OF WARRANTY. INTRADO EXPRESSLY DENIES ANY REPRESENTATION OR WARRANTY ABOUT THE ACCURACY OR CONDITION OF DATA OR THAT THE SERVICES OR RELATED SYSTEMS WILL OPERATE UNINTERRUPTED OR ERROR-FREE.

6. LIMITATION OF LIABILITY.

a. NEITHER PARTY WILL BE LIABLE TO THE OTHER FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL, OR PUNITIVE DAMAGES, INCLUDING COST OF COVER. EACH PARTY’S ENTIRE AGGREGATE LIABILITY FOR ANY CLAIMS RELATING TO SERVICES OR THIS AGREEMENT WILL BE LIMITED TO AN AMOUNT EQUAL TO THE SUM OF THE FEES PAID BY CUSTOMER FOR THE APPLICABLE SERVICES IN THE TWELVE MONTHS IMMEDIATELY PRECEDING THE DATE OF THE RELEVANT CLAIM.

b. THE FOREGOING LIMITATIONS AND EXCLUSIONS OF LIABILITY WILL NOT APPLY FOR CLAIMS RELATING TO VIOLATIONS OF EITHER PARTY’S INTELLECTUAL PROPERTY RIGHTS (INCLUDING SOFTWARE), OR ANY OF EITHER PARTY’S OBLIGATIONS SET FORTH IN THE SECTIONS HEADED “CONFIDENTIALITY” AND “INDEMNIFICATION”, AND MAY BE FURTHER LIMITED BY FEDERAL, STATE OR LOCAL LAW. EXCEPT AS SET FORTH IN THE PRECEDING SENTENCE, THE FOREGOING LIMITATIONS OF LIABILITY WILL APPLY, HOWEVER, WHETHER THE APPLICABLE CLAIM IS BASED ON LOST GOODWILL, LOST PROFITS, LOSS OF USE OR PERFORMANCE OF ANY PRODUCTS, SERVICES, OR OTHER PROPERTY, LOSS OR IMPAIRMENT OF DATA OR SOFTWARE, OR OTHERWISE, AND WHETHER THE APPLICABLE CLAIM ARISES OUT OF BREACH OF EXPRESS OR IMPLIED WARRANTY, CONTRACT, TORT, (INCLUDING NEGLIGENCE), STRICT PRODUCT LIABILITY OR OTHERWISE, REGARDLESS OF WHETHER SUCH PARTY HAS BEEN NOTIFIED OF THE POSSIBILITY OF SUCH DAMAGES OR IF SUCH DAMAGES WERE REASONABLY FORESEEABLE.

7. INDEMNIFICATION. Intrado and Customer each agrees to indemnify and hold harmless the other, its respective officers, agents, employees, contractors, subcontractors, suppliers, invitees, and representatives, from and against any and all third party claims, including without limitation claims by Customer’s customers, of loss, damages, liability, costs, and expenses (including reasonable attorneys’ fees and expenses) for physical injury or death or damage to real property to the extent caused by the indemnifying Party’s negligence, and/or willful misconduct. In addition, Intrado shall indemnify, defend, and hold harmless Customer and its Affiliates, directors, officers, employees, agents, successors and assigns from all claims of patent or other intellectual property infringement arising from the use of the Services or software provided by Intrado. (Whenever Intrado is responsible under the preceding sentence, Intrado may at its option either procure the right for Customer to continue using, or may replace or modify the alleged infringing Service or Software so that the Service or Software becomes noninfringing. If those alternatives are not reasonably achievable, Intrado may terminate the affected Attachment without termination liability to either Party. If the indemnifying Party acknowledges in writing its obligations under this Section, the indemnifying Party will have the right to conduct the defense of such claim or action and all negotiations for settlement or compromise. However, the indemnified Party, at its own expense, may participate in the defense of any such proceeding through counsel of its choosing.

8. TERMINATION.

If either Party defaults in the performance of any material provision of any Attachment or this Agreement, and such default is not cured within (i) for late payments, ten (10) days; (ii) for all other matters (except as may be set forth in an applicable Attachment), thirty (30) days, after notice specifying, in reasonable detail, the nature of the default, then the non-defaulting Party may by further notice terminate for cause the Attachment or, if such breach affects the entire Agreement, this Agreement. The cure period will extend for up to thirty (30) more days if the defaulting Party notifies the other Party that the defaulting Party has commenced cure activities and continues to use good faith efforts to cure the default. On termination, (i) by Customer other than for cause or other circumstances entitling Customer to terminate without liability, or (ii) by Intrado for breach by Customer pursuant to this Section 8, Customer will pay as liquidated damages and not as a penalty (and as Intrado’s sole and exclusive remedy for such termination) the termination charge set forth in the applicable Attachment, or if no such termination charge is set forth in the applicable Attachment, a termination charge equal to fifty percent (50%) of the sum of all * (as well as any past due balances) due under the remaining term(s) of the affected Attachment(s). Termination of one Attachment will not affect any other Attachment.

* Confidential treatment has been requested. The redacted material has been separately filed with the Commission.

9. INTELLECTUAL PROPERTY. Intrado will have and retain full and exclusive ownership of all intellectual property rights associated with any design, data, specification, know-how, software, device, technique, algorithm, method, discovery or invention, whether or not reduced to practice, developed by or for Intrado relating to (a) the Service, including any Intrado work product, and/or (b) enhancement or improvement to or derivative of the foregoing (collectively, “Intrado Property”). The intellectual property rights associated with Intrado Property are referred to collectively as “Intrado IP”. Except as provided in an Attachment, Customer receives no right, title or interest in or license to use any Intrado IP. However, Customer is hereby granted a non-exclusive, non-transferable, license to use such of the Intrado IP that is necessary for Customer to exercise its rights hereunder, including without limitation the use of the Service by Customer and the provision by Customer or any Customer affiliate to its customers of the Service or of Customer’s (or it’s affiliate’s) own services that make use of or incorporate the Service, but solely in connection with and only for the term of the applicable Service and subject to the terms of any applicable Attachment. Customer will not allow access to Intrado Property, including without limitation, software and systems, by anybody other than Customer’s employees and subcontractors who (i) are bound by law or written agreement to comply with Customer’s duties under this Agreement with respect to Intrado Property and Confidential Information, and (ii) require such access to assist Customer in its permitted use thereof. Customer will not directly or indirectly reverse engineer, decompile, disassemble or copy any Intrado Property. Customer will return all Intrado Property to Intrado at the conclusion of the applicable Service. Customer will cooperate to take such actions reasonably requested to vest ownership of Intrado IP and Intrado Property in Intrado.

10. ON-SITE SERVICES. If Intrado personnel perform Services on Customer’s premises: (i) Customer will provide all facilities, access, furnishings, equipment, software, documentation, passwords, and data necessary to perform the Services; (ii) Customer will maintain adequate security, safety, utilities, and environmental standards, consistent with industry standards and its regular practices; and (iii) while on Customer’s premises, Intrado personnel will comply with Customer’s standard rules and regulations generally applied and communicated to Intrado in advance.

11. INSURANCE.

a. Intrado and Customer will each maintain during the term of this Agreement: (1) Workers’ Compensation insurance as prescribed by the law of the state or nation in which the Work is performed; (2) employer’s liability insurance with limits of at least $500,000 for each occurrence; (3) comprehensive automobile liability insurance if the use of motor vehicles is required, with limits of at least $1,000,000 combined single limit for bodily injury and property damage for each occurrence; (4) Commercial General Liability (“CGL”) insurance, including Blanket Contractual Liability and Broad Form Property Damage, with limits of at least $1,000,000 combined single limit for bodily injury and property damage for each occurrence; (5) Professional Liability or Errors and Omissions insurance in the amount of at least $1,000,000 (one million dollars) for each occurrence (such Errors and Omissions policy has been requested by Customer and is forthcoming); and (6) excess or umbrella liability at a limit of no less than $5,000,000 (five million dollars) per occurrence and aggregate in excess of the underlying coverage required above. The CGL, employer liability, excess or umbrella liability, and automobile liability policies of each Party will designate the other Party and its officers, directors and employees as an Additional Insured. [

b. On either Party’s written request, the other Party will furnish certificates evidencing the foregoing insurance. At least thirty (30) days prior to any cancellation or termination of a Party’s policy, said Party will notify the other in writing of such cancellation or termination.

12. MISCELLANEOUS.

a. Force Majeure. Either Party’s performance of its obligations hereunder may be impeded by events outside of such Party’s reasonable control (a “force majeure event”), including acts of God, floods, fires, hurricanes, earthquakes, acts of war or terrorism, labor actions, failure of third-party suppliers, or changes in applicable laws and regulations. Failure to perform such obligations due to a force majeure event will be excused. In the event Intrado is unable to deliver Service as a result of a force majeure event, Customer shall not be obligated to pay Intrado for the affected Service for so long as Intrado is unable to deliver the affected Service, and in the event such inability persists for more than thirty (30) days, Customer may terminate the affected Service without liability.

b. Notices. All notices required hereunder will be made in writing to the addresses below the signature line. Notices will be acceptable only if provided as follows, and will be deemed given: (a) one (1) day after deposit with an overnight courier, charges prepaid; (b) three (3) days after mailing by first class, certified, or registered U.S. Mail, charges prepaid, return receipt requested; and (c) when delivered by hand or by facsimile with confirmed receipt.

c. Independent Contractors. The Parties are independent contractors, and nothing herein will be construed to any other effect. Each Party alone will determine, supervise and manage the method, details, and means of performing its obligations. Except as agreed in writing, neither Party will act or attempt to act or represent itself, directly or by implication, as the other Party’s agent. Each Party will be solely responsible for the compensation, fringe benefits and withholding and payment of all applicable federal, state, and local taxes for its own employees.

d. Exclusivity. Except as specified in an Attachment, neither Party is bound by any exclusivity to the other under this Agreement.

e. No Third Party Beneficiaries. This Agreement benefits Customer and Intrado. There are no intended third party beneficiaries, including without limitation Customer’s customers.

f. Severability; No Waiver. Any provision of this Agreement that is prohibited or unenforceable will be ineffective to the extent of such prohibition or unenforceability without invalidating the remaining provisions. No course of dealing or failure of a Party to enforce strictly any term or provision of this Agreement, or to exercise any right, obligation, or option provided hereunder, will waive such term, provision, right, obligation, or option.

g. Interpretation. In this Agreement, the term “including” means “including, without limitation”, and the term “days” refers to calendar days. This Agreement and each Attachment is the joint work product of Intrado and Customer, and no inference may be drawn or rules of construction applied against either Party to interpret ambiguities. Should the terms of this Agreement and an Attachment conflict, the terms of the Attachment will govern for that Attachment only. No preprinted or form terms on a purchase order will apply.

h. Assignment. This Agreement will be binding on the successors and assigns of both Parties, provided, however, neither party may assign, delegate or transfer this Agreement (an “Assignment”) without the other party’s prior written consent. Such consent will not be required, however, for any Assignment to a financially solvent affiliate of the assigning party or an assignment involving a sale of all or substantially all of Customer’s assets or stock, or any company with which or into which Customer may merge or consolidate. Any other assignment or transfer will be void and of no effect.

i. Governing Law; Venue. This Agreement and all acts, transactions, rights, and obligations relating thereto will be governed by and construed under the laws of the State of New York, without giving effect to principles of conflicts of law. All disputes will be resolved exclusively in the federal or state courts located in New York, New York, and each Party consents to the personal jurisdiction and exclusive venue of those courts for that purpose.

j. Remedies. Either Party will be entitled to immediate injunctive relief in addition to any other rights and remedies available to it at law or in equity, without the posting of a bond or demonstration of irreparable harm, for breach by the other Party of Section 4 or 9 above. Except as stated herein, the rights and remedies of each Party are cumulative, and are in addition to any other rights or remedies available at law or in equity.

k. Laws, Regulations, Permits. Each Party will comply, at its own expense, with all applicable federal, state, county, and local ordinances, regulations, and codes in performing its obligations hereunder. Each Party represents that it has or will obtain all consents, licenses, permits and certificates required to receive or perform the Services and to do business in the United States. If continued performance of the Services would cause Intrado or Customer to be in violation of any applicable law, statute, ordinance, court order or regulatory agency rules, either Party may cease performing the applicable Service(s) to the extent reasonably required to correct or avoid the violation,

l. Advertising And Publicity. Except for materials already made public, neither Party will distribute any news releases, articles, brochures, speeches, or advertisements concerning this Agreement, nor use the other Party’s

name or trademarks (or any variation thereof), without the other Party’s prior written consent, not to be unreasonably withheld or delayed. Notwithstanding the foregoing, Intrado may use Customer’s name and trademarks in a list of customers, or in connection with written sales or promotional materials. Subject to Section 4, either Party may make appropriate disclosures (including regarding this Agreement) pursuant to federal or state securities or other laws, or for the limited purpose of providing information to shareholders or investment analysts or state or federal regulatory agencies.

m. Authority. Each Party represents to the other that (i) it has full authority to enter into and perform under this Agreement (ii) the person signing this Agreement on its behalf is properly authorized; and (iii) it has read this Agreement, understands it, and agrees to be bound by all of its terms, conditions, and provisions.

n. Survival. Sections 3, 4, 6, 7, 9 and 12 will survive the expiration or termination of this Agreement or any Attachment

o. Entire Agreement. This Agreement, together with any Attachment(s) or executed amendments, constitutes the Parties’ entire understanding, and supersedes any prior written or oral agreements or understandings, related to the subject matter hereof. This Agreement or any Attachment may be modified only by a mutually executed amendment.

The Parties hereby execute and authorize this Agreement as of the date first set forth above.

VONAGE NETWORK INC.				INTRADO INC.

/s/ LOUIS MAMAKOS				/s/ MARY HESTER
Authorized Signature				Authorized Signature

Louis Mamakos				Mary Hester
Name Typed or Printed				Name Typed or Printed

Chief Technology Officer				Sr. VP
Title				Title

Address for Notices				Address for Notices
2147 Route 27				1601 Dry Creek Dr.
Edison, New Jersey 08817				Longmont, CO 80503
Attn:				Attention: Chief Financial Officer
With Copy Attn:				With copy Attention: General Counsel

Attachment

VoIP V9-1-1^SMMobility
Services

Statement of Work
for
Vonage Network Inc.

intrado®
1601 Dry Creek Drive
Longmont, Colorado, U.S.A. 80503
720.494.5800

Notice

Certain portions of this Statement of Work are © 2004-2005 Intrado Inc., Longmont, Colorado, USA - All rights in such portions are reserved. Intrado, triangle beacon design, IntelliBase and the logo forms of the foregoing, are trademarks and/or service marks of Intrado Inc. in the United States, other countries, or both and may be registered therein.

Such portions of this documentation may not be altered, copied, distributed, published, displayed, or reproduced in whole or in part (except for Customer’s internal use in connection with this SOW and the Agreement or for purposes of enforcing Customer’s rights thereunder) without Intrado’s prior written consent except as otherwise provided in writing. Any authorized use, in whole or in part, must contain the following statement:

Trademark Information

All trademarks used herein are the property of their respective owners.

It is the policy of Intrado to improve products and services as new technology, software, hardware, and firmware become available. Intrado, therefore, reserves the right to change underlying, non-customer impacting, components of the service without prior notice provided any such modifications will not materially or adversely affect the services and specifications outlined in this SOW. If the change is Customer impacting Intrado will obtain Customers prior written consent.

Proprietary and Confidential

Table of Contents

				Page

1	INTRODUCTION			1
2	ADDITIONAL TERMS AND CONDITIONS			2
	2.1	Term		2
	2.2	Termination		2
	2.3	Exclusivity and Competition		2
	2.4	Letter of Agency		2
3	SERVICES OVERVIEW			3
	3.1	Provisioning Flow		3
		3.1.1	VUI	3
	3.2	Services Local Number Portability Service		3
	3.3	Failover Call Flow		3
	3.4	Services Call Flow		4
4	CUSTOMER RESPONSIBILITIES			5
	4.1	Dedicated IP Infrastructure Procurement and Provisioning		5
	4.2	Subscriber Record Provisioning		5
		4.2.1	Subscriber Record Provisioning	5
		4.2.2	Error Records	5
	4.3	Emergency Call Routing		5
		4.3.1	Standard Production Call Routing	5
		4.3.2	Failover Call Routing to Intrado’s ECRC	6
		4.3.3	Facilitation of Emergency Call Routing using Intrado’s ECRC	6
	4.4	ANI Delivery		6
	4.5	PSAP Communication		6
	4.6	Security Compliance		7
	4.7	Service Affecting Activities		7
	4.8	Implementation Timeline		7
	4.9	Additional Connectivity Requirements		7
5	INTRADO RESPONSIBILITIES			7
	5.1	Services Systems		7
		5.1.1	GRIXE Interface	7
		5.1.2	Maintenance	7
	5.2	Subscriber Record Provisioning		8
		5.2.1	Customer Provisioning Access	8
		5.2.2	Subscriber Record Provisioning	8
		5.2.3	Geo-Coding Accuracy	8
	5.3	Emergency Call Routing		9
		5.3.1	Standard Production Call Routing	9
		5.3.2	Emergency Call Routing using Intrado’s ECRC	9
	5.4	Troubleshooting		9
	5.5	Billing and Metrics		9
		5.5.1	Invoicing and Metrics for Services	9
		5.5.2	Invoicing for Connectivity	9
6	JOINT RESPONSIBILITIES			10
	6.1	Standard Acceptance Testing		10
7	PROJECT COORDINATION			10
	7.1	Project Coordinators		10
	7.2	Project Escalation		10
8	ABBREVIATED PROJECT PLAN (SAMPLE DATES)			10
9	SERVICES LIMITATIONS			11
10	TRAINING			11
11	AUTHORITY			11
12	ENTIRE AGREEMENT			11

iii

APPENDIX A:	SERVICES FEES
APPENDIX B:	GLOSSARY OF DEFINITIONS
APPENDIX C:	VALIDATION AND UPDATE INTERFACE CUSTOMER SETUP PROCESS
APPENDIX D:	VALIDATION AND UPDATE INTERFACE SPECIFICATION
APPENDIX E:	GEOGRAPHICAL ROUTING INTERFACE USING XML
APPENDIX F:	INTRADO’S PROJECT ESCALATION LIST
APPENDIX G:	ACCEPTANCE TEST PLAN
APPENDIX H:	ABBREVIATED PROJECT PLAN
APPENDIX I:	PROPOSED DEPLOYMENT SCHEDULE AND TIMELINE POSITION

1 Introduction

This Statement of Work (“SOW”), effective as of July 8^th, 2005 (“SOW Effective Date”), is an Attachment to the Agreement for Services between Intrado Inc. (“Intrado”) and Vonage Network Inc. (“Customer”), dated as of July 12th, 2005 (“Agreement”). This SOW sets forth the responsibilities of Intrado and Customer for V9-1-1^SM Mobility Services described herein (“Services”). If terms conflict between this SOW and the Agreement, this SOW will govern for purposes of this SOW only. Charges for the Services are specified in Appendix A attached to this SOW. The definitions in Appendix B will apply to this SOW only (including appendices). Capitalized terms not defined in this SOW will have the meanings set forth in the Agreement. This SOW replaces and supersedes: (i) the Vonage™ – Intrado™ Implementation Phase I Contract effective December 23, 2002 (“ECS Agreement”) in its entirety, provided however that Addendum 2, Addendum 3 and Addendum 4 of said ECS Agreement are hereby incorporated herein and made a part hereof, except that Section 3 of Addendum 4 and Section 3 of each of the Amendments to Addendum 4 are hereby deleted in their entirety, and replaced in each instance by the following:

In addition to the indemnification obligations set forth in Section 7 of the Agreement for Services between Intrado Inc. (“Intrado”) and Vonage Network Inc. (“Customer”), dated as of July 12th, 2005 (“Agreement”), (i) Customer shall indemnify, defend, and hold harmless Intrado and its directors, officers, employees and agents from and against any claims, actions, damages, liabilities, costs, judgments or expenses (including but not limited to filing fees, expert fees, attorney fees) (“Claims”) arising out of or relating to the ECRC Call Transfer Service; provided that the foregoing indemnity will not require Customer to indemnify Intrado against liability for damages to the extent such damages result from any negligent, willful or wanton act or omission of Intrado; and (ii) Intrado shall defend, indemnify and hold harmless Customer and its directors, officers employees, representatives, agents and third party vendors from and against any and all Claims arising out of or in connection with any negligent, willful or wanton act or omission by INTRADO or its employees, agents or representatives.

(ii) the Agreement for Services between Intrado Inc. (“Intrado”) and Vonage Network Inc. (“Customer”), dated as of April 27, 2005 (“New York Agreement”) in its entirety (provided, however, that Attachment A of the New York Agreement – VoIP 9-1-1 Gateway Services with V9-1-1^SM Mobility Services for City of New York Statement of Work for Vonage Network Inc. is hereby incorporated herein and made a part hereof) and (iii) Attachment B of the New York Agreement – VoIP V9-1-1^SM Mobility Services for the City of New York effective April 27, 2005 in its entirety.

The following are attached to this SOW and are incorporated herein:

•	Appendix A	Fees
•	Appendix B	Definitions
•	Appendix C	Validation and Update Interface (“VUI”) Customer Setup Process
•	Appendix D	Validation and Update Interface (“VUI”) Specification
•	Appendix E	Geographical Routing Interface using XML (GRIXE)
•	Appendix F	Intrado’s Project Escalation List
•	Appendix G	Standard Acceptance Test Plan
•	Appendix H	Abbreviated Project Plan
•	Appendix I	Proposed Deployment Schedule and Timeline Position

The Services Intrado provides under this SOW will enable the routing of Customer’s VoIP Subscribers’ VoIP 9-1-1 emergency calls to the appropriate PSAP through delivery of the VoIP 9-1-1 call to the SR(s) on behalf of the Customer or through delivery of information back to Customer’s call control platform with routing instructions for proper termination. The V9-1-1 Mobility service will enable the VoIP 9-1-1 call to be delivered to the PSAP with the VoIP Subscriber’s call back number and MSAG valid address, when available.

The Services will provide a native E9-1-1 solution for delivering VoIP 9-1-1 calls from both in-region and out-of-region TNs (i.e., from TNs that are ordinarily assigned within the PSTN to locations within the serving territory of the applicable PSAP (“in-region TNs”) and TNs that are not ordinarily assigned within

the PSTN to locations within the serving territory of the applicable PSAP but are used by Vonage in serving VoIP Subscribers located within such territory (“out-of-region TNs”). The Services will provide the Customer with a near real-time provisioning interface to provision/register Subscriber location data. At the time of a 9-1-1 call Intrado will: (i) whenever feasible, provide call routing instructions to the Customer which will contain a ten (10) digit Emergency Services Routing Number (“ESRN”) and ten (10) digit Emergency Services Query Key (“ESQK) as the Calling Party Number (“CPN”), or (ii) when (i) is not feasible, deliver the VoIP 9-1-1 call to the appropriate PSAP on behalf of the Customer utilizing one (1) or multiple existing business agreements and partnerships and/or dedicated IP infrastructure (i.e., Intrado’s VoIP 9-1-1 Peering Service) deployed by Intrado.

To receive the Services, the Customer will do the following:

1. Provide Subscriber Records containing the TN and an accurate physical service address (as provided to Customer by Subscriber) with the five (5) digit zip code.

2. Comply with the interface specification for provisioning Subscriber data, described in Appendix D attached hereto.

2 Additional Terms and Conditions

In addition to the terms and conditions of the Agreement, the following additional terms and conditions shall apply to this SOW.

2.1 Term

The term of this SOW shall begin upon the SOW Effective Date as first stated above and continue for a period of three (3) years (“Initial Term”) unless earlier terminated under the terms of this SOW or the Agreement. The Initial term may be extended at Vonage’s option for successive additional one (1) year terms (each, a “Renewal Term”).

2.2 Termination

Customer may terminate for convenience at any time, provided Customer will pay a termination fee (which will be Intrado’s sole and exclusive remedy for such termination) equal to *.

2.3 Exclusivity and Competition

Nothing herein shall prohibit Intrado from providing services similar or identical to the Services provided to Customer hereunder to any other entity or person, whether or not such services are utilized for emergency purposes; provided, however, that Intrado does not use Confidential Information of Customer to do so. Nothing herein shall prohibit Customer from procuring services similar or identical to the Services provided by Intrado hereunder from any other entity or person, whether or not such services are utilized for emergency purposes; provided, however, that Customer does not use Confidential Information of Intrado to do so.

2.4 Letter of Agency

Concurrent with the execution of this SOW, or at any time during the Initial Term or any Renewal Term, Customer agrees to execute and deliver to Intrado, such Letter of Agency (“LOA”) as may reasonably be required, which LOA will enable Intrado, as a limited agent for Customer, to work with telecommunications carriers on the Customer’s behalf solely for the purpose of establishing interconnections between Intrado, Customer, and/or the telecommunications carriers required for Intrado to provide and Customer to receive Services hereunder. The LOA shall: (1) not be released by Intrado or used except as authorized by this SOW; (2) be deemed revoked upon: (i) delivery to Intrado or the applicable telecommunications carrier of written notice of Customer’s election in this regard or (ii)

* Confidential treatment has been requested. The redacted material has been separately filed with the Commission.

termination or expiration of this SOW, whereupon Intrado shall cease to act under such :LOA or represent itself as Customer’s agent or representative for any purpose whatsoever; and (3) be returned to Customer upon Customer’s request, upon: (i) termination or expiration of this SOW; or (ii) delivery of a revocation notice to Intrado as described herein. In no event shall Intrado be deemed Customer’s agent (nor shall Intrado represent itself as such) for purposes of responding to or interfacing with PSAPs impacted by the routing and delivery of Subscriber calls. The Parties understand and acknowledge that should Customer fail to provide Intrado with such an LOA, portions of the Services may not be able to be provided to the extent Intrado cannot reasonably provide such Services in the absence of such an LOA.

3 Services Overview

3.1 Provisioning Flow

The Customer will provision Subscriber data into the Intrado Services systems, and Intrado will receive such Subscriber data, by means of a validation and update interface (“VUI”), a real-time Extensible Markup Language (“XML”) based transactional interface. The following describes the provisioning process.

3.1.1 VUI

The VUI setup and interface specifications, attached hereto as Appendix C and Appendix D, provide setup instructions for establishing the Customer account and facilitating Subscriber Record transactions.

1. Customer submits an XML formatted message set which will contain a Subscriber base record to Intrado via the VUI.

2. Intrado geo-coding process adds x, y (latitude-longitude) coordinates to the Subscriber base record. Records that fail the geo-coding process are sent to Intrado data integrity unit analyst for error processing. Address errors that cannot be resolved by Intrado will be sent back to the Customer for further resolution.

3. Subscriber base record is matched by Intrado against the MSAG for MSAG validation. Upon successful MSAG validation, Intrado provisions the Subscriber base record on Intrado’s Services system. If MSAG validation fails, the Subscriber base record is sent to an Intrado data integrity unit analyst for error processing.

4. Subscriber base records are inserted, deleted, or changed by the Customer through the agreed upon provisioning interface (VUI), within the Subscriber database on Intrado’s Services provisioning systems.

5. All Subscriber base records in error, once processed by Intrado, will be sent by Intrado to an Intrado data integrity unit analyst for resolution and resubmitted to Intrado’s Services provisioning systems as soon as error processing is complete. Upon processing and correction of error Intrado will immediately resubmit record into Intrado systems.

6. Customer Subscriber base records in error that cannot be resolved by Intrado will be sent to Customer for resolution and resubmission to Intrado’s Services provisioning systems within three (3) business days from receipt of error from Intrado.

3.2 Services Local Number Portability Service

Intrado’s Services provisioning process supports local number portability (“LNP”) services allowing the Customer to submit VoIP Subscriber Records that have been ported from other ILEC(s) or CLEC(s).

3.3 Failover Call Flow

1. In the event of a communication link failure or non-response from the Primary IntelliVector Position Server (provided by Intrado as further described in Section 5.1 below), Customer’s VoIP call control platform queries the other IntelliVector Position Server with the Subscriber TN. The call flow steps from one (1) to five (5) below are then followed to complete the VoIP Subscriber 9-1-1 call to the PSAP.

2. In the event of dual link failures, a non-response from both IntelliVector Position Servers, or an error message in the GRIXE response, *, and will deliver the call to the geographically appropriate PSAP.

3.4 Services Call Flow

Figure 1 – Services Call Flow Diagram

Depicting Intrado Delivering Call Routing Instructions to Customer

The Services call flow as depicted in Figure 1 is as follows. The reference to “Service Provider” in Figure 1 is to Customer.

When the Customer’s VoIP call control platform receives a 9-1-1 call, *. Intrado’s IntelliVector Position Server determines available routing instructions for the VoIP Subscriber’s TN.

If native call delivery is available, *

If native call delivery is not available, the Intrado IntelliVector Position Server returns a ten (10)-digit PSTN routable PSAP DN of the appropriate PSAP. Customer’s VoIP network redirects the call via the PSTN to the PSAP DN with the VoIP Subscriber’s TN as the CPN.

* Confidential treatment has been requested. The redacted material has been separately filed with the Commission.

4 Customer Responsibilities

4.1 Dedicated IP Infrastructure Procurement and Provisioning

When necessary and appropriate and as the parties mutually agree, Customer will procure and provision dedicated IP connectivity to Intrado facilities, and according to Intrado specifications, in order to pass 9-1-1 calls directly to Intrado for routing determination and termination to the dedicated Intrado IP infrastructure.

Customer will be responsible for providing technical personnel during pre-launch acceptance testing, to resolve any technical issues traced to Customer’s implementation of the dedicated IP connectivity to Intrado.

4.2 Subscriber Record Provisioning

Customer will provide Subscriber Records containing Subscriber TN and Subscriber’s accurate physical service address (as provided by Subscriber) with five digit (5) zip code. Intrado recommends that each Subscriber Record include the zip+4 where possible as further defined in Section 5.2.3. Customer will provide Subscriber Records by means of a VUI as described in Appendix D attached hereto. Subscriber Records submitted to Intrado for Services provisioning must contain only Subscriber Records of Customer’s or its affiliates’ Subscribers. If Customer desires to submit records from other providers, Customer should contact Intrado about Reseller Services.

Additionally, Customer will obtain a NENA ID to use as the Company ID on each Subscriber Record submitted.

For Services procured by Customer hereunder, Customer will use and Intrado will provide Intrado’s geo-coding services as further defined in Section 5.2

4.2.1 Subscriber Record Provisioning

4.2.1.1 VUI

Customer will develop the VUI client interface to the VUI specification as described in Appendix C and Appendix D attached hereto.

4.2.2 Error Records

Customer Subscriber Records that error out of the normal provisioning process will be sent to the Intrado data integrity unit analyst for resolution and resubmitted immediately to Intrado’s Services provisioning system. Customer Subscriber Records that cannot be resolved by an Intrado data integrity unit analyst will be sent back to the Customer for resolution and resubmission by Customer within three (3) business days of receipt of error, to Intrado’s Services provisioning system by means of the already established VUI.

4.3 Emergency Call Routing

4.3.1 Standard Production Call Routing

Customer will route VoIP emergency calls to *. Customer will use the *. Customer will use the *. VoIP Subscribers must be activated for dialing 9-1-1 after Customer receives confirmation from Intrado that the Subscriber Record has been successfully provisioned in the Intrado Services provisioning system *.

In the event that Customer’s VoIP call control platform does not receive *, Customer will configure its VoIP call control platform to *.

* Confidential treatment has been requested. The redacted material has been separately filed with the Commission.

Note: Intrado may institute an Emergency Call Routing Query internally and on behalf of Customer as available in the future. This change to Service delivery will not materially impact Services and any changes required by Customer will be addressed on a mutually agreeable basis.

4.3.2 Failover Call Routing to Intrado’s ECRC

*. Customer will also be responsible for any associated access or toll charges associated with emergency failover calls to the ECRC.

4.3.3 Facilitation of Emergency Call Routing using Intrado’s ECRC

Customer will provide the following tools to assist Intrado’s ECRC personnel in routing Customer’s VoIP emergency calls:

Customer will provide *. In the event the Subscriber Record is unavailable from the IntelliVector Position Servers, *.

Customer will provide a 24x7x365 operations center ("NOC") with trained personnel to facilitate the emergency call routing process detailed within this SOW, including:

• If data connectivity *.

• *

Intrado’s ECRC personnel will contact Customer’s operation center only after all other failover scenarios have been exhausted.

4.4 ANI Delivery

Customer will be required as a condition of receiving Services pursuant to this SOW for any Subscriber VoIP 9-1-1 call, to provide ANI with such Subscriber call presented to Intrado’s VoIP 9-1-1 Gateway for processing. Except as set forth in Section 4.3, Intrado will have no obligation to provide Services with respect to any Subscriber call that does not include ANI, and Intrado will not be liable for any claims arising from any efforts undertaken by Intrado to provide Services with respect to any Subscriber call that does not include ANI.

4.5 PSAP Communication

When Customer intends to notify PSAP(s) of its intent to launch VoIP 9-1-1 services using the Services provided by Intrado under this SOW, Intrado will provide Customer with an approved PSAP communication letter within two (2) business days of Customer’s request for such letter. Customer agrees to submit to Intrado any revisions to this letter for review and approval by Intrado at least ten (10) business days in advance of mailing and Intrado will inform Customer of its approval or rejection of such revisions within two (2) business days of such submission. Intrado will not unreasonably withhold approval of such revisions.

* Confidential treatment has been requested. The redacted material has been separately filed with the Commission.

4.6 Security Compliance

Each Party will comply with the other’s security policies provided in writing. Customer will pay Intrado’s reasonable and actual out-of-pocket expenses for any changes to the Intrado Services if the changes are required by Customer’s security policies and the changes are generally considered above and beyond accepted industry security standards, provided that such expenses must be quoted to Customer and approved by Customer in advance.

4.7 Service Affecting Activities

Customer will use commercially reasonably efforts to notify Intrado’s NOC ten (10) business days in advance of any scheduled maintenance activities that could affect Services. Such activities include but are not limited to hardware or software upgrades to network components such as Customer’s IP call router.

4.8 Implementation Timeline

Customer agrees to work with Intrado to complete all implementation activities and transition into production service in accordance with Appendix I.

4.9 Additional Connectivity Requirements

Connectivity requirements may vary based on the agreements Intrado enters into for access into the 9-1-1 network (SR Access and ALI Steering Agreements). Intrado will provide, upon request, detailed service connectivity requirements by region in cases where connectivity requirements differ from this SOW.

5 Intrado Responsibilities

5.1 Services Systems

*. The initial query from Company must incorporate the Primary and redundant IntelliVector Position Server node as necessary per the Acceptance Test Plan in Appendix G attached hereto. *.

5.1.1 GRIXE Interface

Intrado will maintain the GRIXE software interface and corresponding specification.

5.1.2 Maintenance

Intrado will use commercially reasonably efforts to notify Customer ten (10) business days in advance of any scheduled maintenance activities that could affect Services. Such activities include but are not limited to hardware or software upgrades.

* Confidential treatment has been requested. The redacted material has been separately filed with the Commission.

5.2 Subscriber Record Provisioning

5.2.1 Customer Provisioning Access

As part of the implementation process Intrado will establish Customer access to the Intrado Services VUI server for submission of Customer VoIP Subscriber Records by means of the Customer’s real-time VUI transactional interface.

5.2.2 Subscriber Record Provisioning

As part of the Intrado Services provisioning service, Intrado will geo-code and MSAG validate each Subscriber Record prior to completion of record provisioning into Intrado’s Services provisioning systems. The geo-coding process associates x, y (latitude-longitude) coordinates with the Subscriber service address for each Subscriber Record. The x, y association to the Subscriber Record enables Intrado to assign appropriate call routing instructions to the Subscriber’s TN at the time of a VoIP 9-1-1 call.

Intrado will complete the geo-coding process and provision the Subscriber Record in the Services provisioning system enabling the Customer to turn up VoIP 9-1-1 service for that Subscriber.

Upon successful geo-coding of the Subscriber Record, Intrado will validate the Subscriber Record against the MSAG and complete the Services provisioning process.

5.2.3 Geo-Coding Accuracy

The geo-coding process will associate x, y (latitude-longitude) with variable accuracy levels. The geo-coding accuracy indicates how closely the x, y coordinates map to the Subscriber’s actual street address. *.

All geo-coded Subscriber Records will be provisioned in the Services provisioning system once they have been geo-coded to the zip level accuracy to enable VoIP 9-1-1 call routing to the appropriate PSAP.

* Confidential treatment has been requested. The redacted material has been separately filed with the Commission.

5.3 Emergency Call Routing

5.3.1 Standard Production Call Routing

Upon receiving a query from Customer’s VoIP call control platform *.

At Customers option, Intrado will utilize Customer supplied ESQKs with the assumption that no additional costs will be incurred by Intrado. In the event costs are incurred, the Parties will negotiate additional fees to Customer in good faith.

Intrado is committed to working with Customer to make available an MSAG tool to provide real-time MSAG validation and record query capabilities. In addition, Intrado will work with Customer to develop and enhance existing MSAG tool response content to include additional data response messages. Customer recognizes that the development of such enhancement falls outside of the scope of this SOW and will be detailed in separate addendum to this SOW and may be subject to additional fees which will be negotiated in good faith.

5.3.2 Emergency Call Routing using Intrado’s ECRC

Intrado will provide a 24x7x365 facility staffed by trained personnel for manually routing emergency calls that cannot be automatically routed using Intrado’s Services systems.

5.4 Troubleshooting

Upon request by Customer, Intrado will use commercially reasonable efforts and standard practices to perform a root cause analysis for troubles encountered in the Services. For Services this will be limited to any and all Intrado functions, hardware and software, including without limitation the VUI server, the IntelliVector Position Servers, Intrado’s Services provisioning systems, ECRC, and associated network connectivity.

5.5 Billing and Metrics

5.5.1 Invoicing and Metrics for Services

By the fifteenth (15) of each month, Intrado will provide a monthly invoice covering day one (1) through day thirty (30) of the prior month. *:

• *

5.5.2 Invoicing for Connectivity

By the fifteenth (15) of each month, Intrado will provide a monthly invoice covering day one (1) through day thirty (30) of the prior month for any connectivity ordered, maintained, and monitored by Intrado on behalf of Customer.

* Confidential treatment has been requested. The redacted material has been separately filed with the Commission.

6 Joint Responsibilities

6.1 Standard Acceptance Testing

Both Intrado and Customer will be responsible for providing personnel to jointly execute the standard Services acceptance testing as defined in Appendix G attached hereto. Execution of the standard test plan will be jointly scheduled based on availability of the appropriate technical personnel.

Customer and Intrado will mutually agree and sign-off on any modifications of the test plan or testing criteria.

Customer will provide a select group of Customer Subscribers or internal personnel to participate in acceptance testing.

All acceptance testing will be performed by Intrado and Customer using production connectivity

7 Project Coordination

Intrado and Customer will each appoint a project coordinator. The project coordinators will meet on a periodic basis to inform each other of the status of the Project and Services and will act as primary contacts to coordinate the completion of the Project activities between Intrado and Customer. The duties of each project coordinator include:

• Implement and maintain the Services described in this SOW (Intrado project coordinator only)

• Establish and maintain a professional level of communication between the Parties

• Scheduling regular meetings to review project progress and direction

• Coordinate training

• Manage escalation procedures

7.1 Project Coordinators

		Intrado
Program Management and communications:	Office:
<CRM Name>	Cell:
	Email:

Implementation and project management:	Office:
<PM Name>	Cell:
	Email:

		Customer
All project coordination details:	Office:
<Contact Name>	Cell:
	Email:

7.2 Project Escalation

In an effort to manage the project to the timeframes and functionality outlined herein, it may become necessary to escalate issues within each Party’s organization. Upon execution of the SOW, the Parties will supply each other with lists of their respective personnel to whom Project issues should be escalated (“Project Escalation List”). Intrado’s Project Escalation List is attached as Appendix F hereto.

8 Abbreviated Project Plan (Sample Dates)

An abbreviated project plan that includes Services activities and Parties’ responsibilities as described in Appendix H is attached hereto.

9 Services Limitations

Customer understands, acknowledges, and accepts the following limitations of Intrado’s Services:

• For Customer’s VoIP Subscribers:

a. The real-time provisioning interfaces provided with the Services allow the Customer to submit Subscriber Records for Services provisioning which enables the Services call to be routed to the appropriate PSAP and present call back number and MSAG valid physical service address of Subscriber to the PSAP. In the event of a geo-coding or MSAG validation failure, Intrado cannot process the error records in real time and will use commercially reasonable efforts to resolve the records in error as soon as possible. There may be circumstances beyond Intrado’s control that will prevent an Intrado data integrity unit analyst from correcting geo-coding and or MSAG validation errors in the event the Subscriber’s physical service address is a new address causing delays in provisioning the Subscriber’s data into Intrado’s Services provisioning systems.

b. The Services is predicated on using primary wireline PSAP boundaries for routing Services emergency calls to the appropriate PSAP. The primary wireline boundary information is collected by Intrado and is entered into a database for real time queries for PSAP boundary lookup. Customer acknowledges that, due to circumstances beyond Intrado’s control, primary wireline PSAP boundary data may not be available for the entire United States and that Intrado is dependent on the PSAPs to provide such information resulting in the use of wireless PSAP boundary data to route a VoIP emergency call.

• For emergency call routing using Intrado’s ECRC, in the event (i) caller cannot speak or identify their address, (ii) data connectivity between the Customer VoIP Subscriber address database and the ECRC is interrupted, (iii) ANI is not provided, and (iv) Customer’s NOC cannot provide the Customer VoIP Subscriber’s location information, Customer acknowledges that Intrado has no further ability to assist the caller.

10 Training

As part of the cost of Services, Intrado will provide two (2) hours of training via telephone on how to transmit data, submit additional records, and Intrado escalation procedures. All training conducted by Intrado will be customized to meet the needs of Customer. The trainer will use customized training examples to familiarize Customer with Intrado’s system and procedures. Training will be “train-the-trainer” format, which will enable Customer to train new employees.

Customer and Intrado will mutually agree on and schedule training.

11 Authority

Each Party represents to the other that (i) it has full authority to enter into and perform under this SOW; (ii) the person signing this SOW on its behalf is properly authorized; and (iii) it has read this SOW, understands it, and agrees to be bound by all of its terms, conditions, and provisions.

12 Entire Agreement

This SOW shall not be enforceable unless duly executed by both Parties. This SOW, together with any Appendices hereto and the Agreement, constitutes the Parties’ entire understanding related to the subject matter of this SOW and supersedes any prior written or oral agreements or understandings with regard to the subject matter of this SOW.

IN WITNESS WHEREOF, the Parties hereto have caused this SOW to be executed by their duly authorized representatives.

	Intrado Inc.		Vonage Network Inc.


	/a/ Mary Hester		/s/ Louis Mamakos
	Signature		Signature

	Mary Hester, Sr. VP		Louis Mamakos, Chief Technology Officer
	Printed Name and Title		Printed Name and Title

	7/15/05		13 July 2005
	Date		Date

Appendix A: Services Fees

The following fee(s) and payment schedule for Services as described in this SOW will apply:

I. One-Time Fees:

Fee Descriptions:		At Contract Signing
Service Licensing and Activation, One Time Fee (“OTF”)		$75,000

SoftSwitch connection to pair of IntelliVector Position Servicers, OTF		Waived

II. Recurring Fees:

Fee Descriptions:		Fee:
Monthly Recurring Charge (“MRC”)
• Begins upon Effective Date hereof • Does not include NYC Gateway Services ($10K per Month)		$*, per month

Telephone Number, recurring fee • TNs within Each Tier take on that Tier’s Pricing
• 0 – 1,000000 TNs		$* per TN
• 1,000,001 – 1,500,000 TNs		$* per TN
• 1,500,001 – 2,000,000 TNs		$* per TN
• 2,000,001 – 2,500,000 TNs		$* per TN
• 2,500,001 – 3,000,000 TNs		$* per TN
• 3,000,001 – 3,500,000 TNs		$* per TN
• 3,500,001 – 4,000,000 TNs		$* per TN
• Tiering Continues at Intervals of 500K TNs and 1 penny reduction until 10,000,000 TNs are reached
• >10,000,000 TNs		$.09 per TN

Fee Descriptions:		Fee:
Per V9-1-1 Query, recurring fee		$*, per query
Per Automated ECS Query (PSAP 24x7 Line Returned)j V9-1-1 Address Geocoding, recurring fee		$* per query
• Automated address geocoding		$* per address
• Manual address geocoding and error resolution		$*, per hour
• Emergency Call Relay Center • To apply only until execution of Intrado Call Center Solutions (ICCS) SOW		$* per call

• The pricing set forth will not be binding on either party unless the SOW is executed by both parties by July __th, 2005.

• Customer will pay Intrado the MRC and other recurring fees based on the schedule above. The MRC and other recurring fees will begin to accrue in the first month in which Services are actually rendered following the satisfactory completion of testing pursuant to the acceptance test plan is completed. If the first day upon which such Services are rendered is after the first (1^st) day of such

* Confidential treatment has been requested. The redacted material has been separately filed with the Commission.

first month, the MRC and other recurring fees will be prorated on a thirty (30) calendar day month for the first monthly recurring fee invoice billing.

• The professional services rate of $275.00 per hour will apply to mutually agreed (in writing) manual processes to support the services and for ongoing support, primarily for data management issues and telecom networking issues, unless otherwise negotiated.

• Emergency Call Relay Center pricing is to be replaced in its entirety by the Intrado Call Center Solutions SOW upon execution. Upon execution and the effective date of the ICCS SOW, pricing for ECRC calls above will no longer apply.

Appendix B: Glossary of Definitions

These definitions are for the attached SOW only and are not necessarily the definitions used by the Federal Communication Commission (“FCC”) or any other governmental, industry, or private organization or entity.

Automatic Location Identification (“ALI”) means the automatic display at the public safety answering point (“PSAP” or “PSAP”) of the Subscriber’s telephone number (“TN”) and the address/location of the telephone.

Automatic Number Identification (“ANI”) means the TN of the telephone or other device from which an emergency call is placed.

Coordinate Routing Database (“CRDB”) means Intrado’s patented hardware and software that provides PSAP or PSAP routing data based on x, y (latitude-longitude) coordinates for automated routing of emergency calls.

Customer Update means updating Customer data related to an existing License.

Enhanced 9-1-1 (“E9-1-1”) means an emergency telephone system which includes network switching, database, and CPE elements capable of providing Selective Routing, Selective Transfer, Fixed Transfer, ANI, and ALI information.

E9-1-1 Database Provider means an agency responsible for maintaining and supporting the ALI database and associated infrastructure.

Emergency Call Relay Center (“ECRC”) means Intrado’s inbound call center, staffed 24 hours per day, 7 days per week, and 365 days per year for emergency call handling Customer support. For purposes of this SOW and the Services provided hereunder, “Emergency Call Relay Center” and “ECRC” will include a third party contracted by Intrado to perform call center services.

Emergency Call means a 9-1-1 call placed by a Voice over Internet Protocol (“VoIP”) Subscriber to Customer’s Internet Protocol (“IP”) services.

Geo-coding means the association of address information to “x, y” (i.e., latitude/longitude) spatial coordinates.

Geographical Routing Interface using XML (“GRIXE” or “GRIXE Interface”) means an interface that uses Intrado’s proprietary interface with eXensible markup language (“XML”) messaging over dedicated Transmission Control Protocol/Internet Protocol (“TCP/IP”) links to geographically route emergency calls.

Geographical Routing Interface using SIP (“GRISIP Interface”) means using Intrado’s proprietary interface with Session Initiation Protocol (“SIP”) messaging over dedicated TCP/IP links to geographically route emergency calls.

IntelliVector Position Server means Intrado’s hardware and software that provides PSAP or PSAP routing information to the Customer for automated routing of emergency calls.

Local Exchange Carrier (“LEC”) means a telecommunications carrier that provides local exchange telecommunications services. Also known as Incumbent Local Exchange Carrier (“ILEC”), Competitive Local Exchange Carrier (“CLEC”), Local Service Provider, and Local Dial Tone Provider.

Master Street Address Guide (“MSAG”) means a database of street names and house number ranges within their associated communities and Emergency Services Numbers (“ESNs”) to enable the proper routing of 9-1-1 calls.

National Emergency Number Association (“NENA”) means a professional association comprised of emergency number personnel, 9-1-1 equipment vendors, and telephone company personnel responsible for the planning, implementing, managing, and administering of emergency number systems.

native 9-1-1 solution means a solution for VoIP calls includes both “native call routing”, where a public switched telephone network (“PSTN”) selective router identifies all 9-1-1 calls and routes to the trunk group serving the appropriate PSAP or PSAP for that NPA/NXX, and delivery of ALI to the PSAP or PSAP call taker.

Number of Records means the quantity of TNs resident in the PS/ALI Database that corresponds to geographic locations of the Customer and/or the Customers’ Subscribers.

Primary IntelliVector Position Server (“Primary IPS”) is determined by which IntelliVector Position Server system Customer configures their IP Call Router to query first. Note that both the IntelliVector Position Server and the Intrado CRDB are fully-redundant, reliable core 9-1-1 systems with equivalent capacity.

Project means the undertaking of the tasks and duties necessary to implement the Services.

Pseudo ANI (“pANI”) means temporarily associating a non-dialable ANI containing a NPA/NXX corresponding to the geographically appropriate PSAP or PSAP to facilitate call routing and ALI delivery to the PSAP or PSAP for “mobile” calls.”

PSAP/PSAP direct number (“PSAP DN” or “PSAP DN”) means a 10-digit local exchange telephone line of the geographically appropriate PSAP or PSAP for any given emergency call request. This dialable number has been indicated to Intrado’s analyst team by the PSAP or PSAP or county as the appropriate 24x7 direct number for wireless call failover.

Public Safety Agency means those governmental agencies, which by law are responsible for the delivery of emergency services within the jurisdiction served by PS/ALI Direct Services to be provided hereunder.

Public Safety Answering Center or Public Safety Answering Point (“PSAP” or “PSAP”) means a facility equipped and staffed to receive emergency calls.

Public Switched Telephone Network (“PSTN”) means the network systems and connectivity operated by incumbent operating telephone companies to route and deliver voice calls to the indicated emergency TN.

Selective Router (“SR”) means a telephone switching center that receives 9-1-1 calls from other offices and uses the ANI or pANI to route them to the proper PSAP or PSAP. Operated by the LEC serving a particular PSAP or PSAP. Some LECs call this the 9-1-1 “tandem” office.

Selective Routing means the routing of a 9-1-1 call to the proper Public Safety Answering Point (PSAP or PSAP) based on the location of the caller. Selective routing is controlled by the ESN which is derived from the Subscriber location.

Subscriber (or “Customer Subscriber”) means a customer of Customer or any Customer affiliate who subscribes to Customer’s or its affiliate’s services.

Subscriber Record means a database record which includes the name, address or address equivalent, and the TN of a Subscriber.

Telephone Number (“TN”) means the ten (10) digit telephone number used to deliver a call to a designated Subscriber.

Appendix C

Validation and Update
Interface (VUI)

Customer Setup Process
Version 1

Notice

Intrado Validation and Update Interface (VUI) Program and Documentation
© 2005 by Intrado Inc.
All Rights Reserved
Printed in U.S.A.

This software product is copyrighted and all rights reserved by Intrado Inc. The product is licensed to the original Licensee only for use according to the terms and conditions set forth in the System Agreement or applicable document containing the licensing provisions. Copying, selling, or using the product contrary to those licensing terms and conditions is a violation of the law. All parts of the Validation and Update Interface (VUI) documentation are copyrighted and all rights reserved. This documentation may not be copied, photocopied, or reproduced in whole or in part without Intrado’s prior written consent except as otherwise provided in writing. Any authorized copying or reproduction in whole or in part, must contain the following statement:

Intrado Validation and Update Interface (VUI) Program and Documentation
© 2005 by Intrado Inc.
All Rights Reserved
Printed in U.S.A.

If you have any questions regarding the appropriate use of this software product and documentation, please direct your comments to:

Intrado Inc.
1601 Dry Creek Drive
Longmont, CO 80503

720.494.5800

Trademark Information

Intrado, triangle beacon design, Informed Response, IntelliBase and the logo forms of the foregoing, are trademarks and/or service marks of Intrado Inc. in the United States, other countries, or both and may be registered therein.

Trademark Ownership

All trademarks used herein are the property of their respective owners.

Product Updates

It is the policy of Intrado to improve products as new technology, software, hardware, and firmware become available. Intrado, therefore, reserves the right to change specifications without prior notice. All features, functions, and operations described herein may not be available worldwide.

Validation and Update Interface (VUI) Customer Setup Process

Table of Contents

Introduction	1

Intended Audience	1

Document Overview	1

VUI Account Setup	2

Downloading the Digital Certificate	3

Exporting the Digital Certificate	9

Introduction

Intrado’s Validation and Update Interface (VUI) allows client-side software to validate and update information used in E9-1-1 systems. VUI implements a specific set of XML messages that allows for all information required by E9-1-1 systems to be pre-validated, authenticated, formatted, and delivered to the appropriate destination databases. This may include Selective Router (SR) and Automatic Location Identification (ALI) databases (refer to your product-specific documentation for more information).

VUI uses digital certificates to verify that users sending messages are who they claim to be, and to provide the receiver with the means to encode a reply.

Intended Audience

This document is intended for application administrators and software engineers who are responsible for testing or implementing the client software necessary to interface with Intrado’s VUI.

Document Overview

This document provides information on the following tasks associated with VUI:

• VUI account setup

• Downloading the digital certificate needed in order to connect to VUI over the public Internet via a secure and encrypted session

• Exporting the digital certificate from your Internet browser

Intrado Confidential

VUI Account Setup

Following a signed agreement with Intrado, you will receive an email with your VUI account ID and instructions on how to receive your enrollment server confirmation number and username. For security purposes this information cannot be provided in the email.

The confirmation number and user name information provided by Intrado is used during the digital certificate authenticator enrollment process. The confirmation number and user name can only be used once. However, the account ID provided by Intrado must be used every time information is transmitted to VUI.

Downloading the Digital Certificate

Once you have received your username and enrollment server confirmation number, you can download the digital certificate.

1. Open your browser and enter the following URL:

https://login.intrado.com

The following screen is displayed:

2. Select the SafeWord PremierAccess Enrollment Server link. The screen displays open user reservations links.

3. Select the VUI Web Service Clients link.

4. The Authenticator Enrollment screen is displayed. The information entered in this screen is used to confirm whether you have the permissions to download the digital certificate.

5. Enter the username provided to you by Intrado in the Username field. This username is valid only one time.

6. Enter the confirmation number provided to you by Intrado in the ConfirmationNumber field. The confirmation number is valid only one time.

7. Enter the full computer name of the computer accessing VUI in the Common Name field. To access this information:

12.1.1 Open the Control Panel and select the System folder. The System Properties dialog box is displayed.

12.1.2 Select the Network Identification tab. The full computer name is listed under this tab.

8. Provide additional information by completing the remaining optional fields.

9. Display the dropdown menu in the last field and select Microsoft Base Cryptographic Provider v1.0.

10. Select the Next button. The following dialog box is displayed:

11. Select the Yes button to continue. The following screen confirms your enrollment and provides buttons to test the authenticator and download the digital certificate.

Before you can test the authenticator, you must download the certificate.

l2. Select the Download Certificate button. The following dialog box is displayed:

13. Select the Yes button. You should receive the following message:

14. Select the OK button. The Confirmation Congratulations screen redisplays.

15. Select the Test button to verify that the downloaded certificate works with your browser. The following screen is displayed:

16. Select the Next button. If the digital certificate passed authentication, the screen displays the following message:

If the digital certificate does not pass authentication, call the Intrado product administrator.

17. Select the Next pushbutton. The screen displays the following message:

18. Select the Continue button to conclude the enrollment process. In order to interface with Intrado’s VUI application, you must export the digital certificate. Refer to “Exporting the Digital Certificate” below.

Exporting the Digital Certificate

The application you develop to interface with VUI must have access to the digital certificate acquired from Intrado. To export the digital certificate from the browser:

Open the browser.

It must be the same web-browser software you used to download the digital certificate. For example, if you used Internet Explorer to download the Digital Certificate, you must open Internet Explorer to export the certificate.

19. Display the Tools menu and select Internet Options.

20. Select the Content tab. Under Certificates, click the Certificates button. The following dialog box displays:

21. Select the certificate downloaded from the Enrollment server. The name of the certificate should correspond to the information entered in the Common Name field from the Authenticator Enrollment screen.

22. Select the Export button. The Certificate Export Wizard is launched.

23. Select the Next button. The next screen asks for information related to the private key.

24. Select the Yes, export the private key radio button and select the Next button. The next screen asks for file format information.

25. Select the Enable strong protection checkbox, as shown below:

26. Select the Next button. The next screen requires you to set your personal password. This password protects the private key associated with the digital certificate.

Intrado does not provide this password.

27. Type your password in the Password field. Retype the same password in the Confirm Password field. The entry in both fields must be identical.

28. Select the Next button. The next screen asks for the file name of the digital certificate.

29. Click on the Browse button to specify the file name and export location of the digital certificate, as shown in the following dialog box:

30. Display the Save in pulldown menu and select the location. Complete the File name field. Select the Save button.

31. Select the Next button. The next screen displays the file name and location:

32. Confirm the information and select the Next button. The next screen displays the digital certificate information entered in the previous screens.

If the information is not correct, select the Back button and reenter the information.

33. Select the Finish button. The screen should display an “export successful” message.

Appendix D

Validation and Update Interface
Specification, v1.1

Intrado Inc.

Longmont, Colorado USA

Issue 1.6

October 2004

Validation and Update Interface Specification, v1.1

License Notice

The information presented herein is the exclusive property of Intrado. Only those persons licensed by Intrado are permitted to use such information and only in accordance with the terms and conditions of the applicable license agreement.

Copyright

This material is protected under the copyright laws of the United States and other countries. It may not be reproduced distributed or altered in any fashion by any entity (either internal or external to Intrado) except in accordance with applicable agreements, contracts or licensing, or with the express written consent of Intrado.

Disclaimer

Every effort was made to ensure that the information in this document was complete and accurate at the time of publication. However, information is subject to change, and Intrado makes no representations or warranties as to the accuracy of the information or its suitability for any intended purpose.

Prerequisites for Use

To take advantage of the interface described herein, software developers and their customers must establish an appropriate business relationship with Intrado. Please see our web site for further details (http://www.Intrado.com).

Contact Information

For more information about this interface, please e-mail Intrado at VUIMail@intrado.com.

Intrado Confidential

Table of Contents

1.0	Scope and Content		3
	1.1	Introduction	3
	1.2	System Access	4
	1.3	References	4
2.0	System and Network Overview		5
	2.1	System Performance	5
	2.2	System Date and Time	5
3.0	XML Message Formats		6
	3.1	General XML message format	6
	3.2	Error Response	7
	3.3	MSAG Query Request	7
	3.4	MSAG Pre-Validation	9
	3.5	TN Query	10
	3.6	TN Update	11
4.0	XML Data Element Descriptions		13
Appendix A: Return Codes and Descriptions			18
Appendix B: Acronyms and Definitions			20
Appendix C: State Abbreviation Codes			21
Appendix D: Revision History			22

1.0 Scope and Content

1.1 Introduction

The Validation and Update Interface (VUI) specification is designed to facilitate application vendors in the provisioning of enhanced 9-1-1 (E9-1-1) services when producing software that supports residential and commercial local exchange service subscribers, Voice over IP (VoIP) subscribers, and users of corporate and institutional Multiple Location Telephone Service (MLTS) systems. Every telecommunications service provider providing dial tone is required by state and local regulators to provide E9-1-1 services to their customers. Using this interface, application vendors can substantially automate the process of efficiently provisioning E9-1-1 services while meeting the regulatory requirements and thereby reducing costs.

The Validation and Update interface implements a set of messages that allows for all information required by the E9-1-1 systems to be pre-validated, authenticated, formatted, and delivered to the appropriate destination databases (for example, Selective Router (SR) and ALI databases). This interface specification draws upon currently recognized standards in the industry including those from the National Emergency Number Association (NENA).

This specification documents the following interconnects to the Validation and Update Interface system: the application, database, and authentication servers; gateways; and devices necessary to provide a robust platform for the provisioning of E9-1-1 data with the service provider’s system. The Intrado E9-1-1 interface supports online connectivity for batch and near real-time transaction processing. Standard e-business protocols such as XML over HTTP allow access to the Validation and Update system. The Intrado system ensures database updates are distributed through the network in accordance with standard provisioning mechanisms and fed into the appropriate destination databases based upon customer type (traditional wireline or VoIP subscriber). This interface anticipates the client-side code will manage all direct interaction with the user of the application and will use the Validation and Update Interface system to provision the E9-1-1 services for the subscriber or user.

This specification implements all functions a telecommunications service provider or PBX user needs to be in full compliance with the FCC mandates for E9-1-1 and meets the demanding requirements of Incumbent Local Exchange Carriers (ILECs), Competitive Local Exchange Carriers (CLECs), and Wireless Carriers. The end users of the applications developed using this interface will be Alternative Local Exchange Carriers, Building Local Exchange Carriers, and Data Local Exchange Carriers.

Figure 1 - Validation and Update Interface Overview

1.2 System Access

The Validation and Update Interface is called via an XML-formatted request transmitted via the HTTP protocol.

The Validation and Update Interface requires transmission of E9-1-1 and subscriber TN data over secure network connections in order to protect customer privacy. Unsecured connections over the public Internet (FTP, SMTP) are not supported, and 128-bit encryption is the minimum supported for public Internet connections.

Messages sent to Intrado are authenticated using the customer’s account number and a client-side digital certificate. Intrado issues an account number to each registered customer, which is a required element of each request sent by the customer.

Intrado’s network engineering and network security groups evaluate and approve all proposed network topologies prior to implementation.

1.3 References

Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation

http://www.w3.org/TR/2000/REC-xml-20001006

Namespaces in XML, World Wide Web Consortium

http://www.w3.org/TR/ 1999/REC-xml-names-19990114/

XML Schema Tutorial

http://www.w3schools.com/schema/default.asp

01-002 – NENA Master Glossary of 9-1-1 Terminology, March 1998

http://www.nena.org/9-1-1TechStandards/Standards_PDF/NENA_01-002.pdf

02-010 – NENA Recommended Formats & Protocols for ALI Data Exchange, ALI Response and GIS Mapping,
January 2002

http://www.nena.org/9-1-lTechStandards/Standards_PDF/NENA_02-010.PDF

2 System and Network Overview

This section describes the Validation and Update Interface standards.

2.1 System Performance

The customer can expect between two and thirty-second transactional response times to the online transactions listed within this specification. Batch transaction performance will depend on file size, system availability, and query types.

2.2 System Date and Time

All date and time elements within this interface are represented using coordinated universal time (UTC) in order to have a common reference point regardless of location of sending or receiving system. Systems operated by Intrado are referenced to the National Institute of Standards and Technology (NIST) atomic clock via radio.

3 XML Message Formats

3.1 General XML message format

All VUI XML request and response messages are contained in the following general structure. All tags are required. Public XML schema files are provided separately.

<VUI

ver=“1.0”

xmlns=“http://www.intrado.com/namespaces/vui”

xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=“http://www.intrado.com/namespaces/vui

http://vuitest.intrado.com/schema/VUI.xsd” >

<HDR>

<Acct>customer account ID</Acct>

<ClientVersion>client software version</ClientVersion>

<REC>number of requests in the message payload</REC>

</HDR>

[actual VUI request information message]

</Payload>

<TRL>

<REC>number of requests in the message payload</REC>

</TRL>

</VUI>

All requests to VUI must use this structure. Individual request structures are described in subsequent sections.

Upon receipt, all messages are checked against an XML schema, which is provided via the Intrado web site. Those schema files are the sanctioned VUI message specifications.

The HDR and TRL tags are included to implement the NENA message specification. Both the HDR and TRL sections must include a REC tag, which specifies the number of records included in the Payload section of the request and response documents. In request messages, the REC tag should always contain the number “1”. In responses, this value indicates the number of responses from a query request, or “1” for most other messages.

The Acct and ClientVersion tags contain information that Intrado uses to route requests and identify customers. Your Intrado account representative provides this information.

All alpha characters to VUI must be uppercase. The system will upshift alpha characters if they are submitted in lower case, except in cases where valid values for the data element have been defined within this specification. If lower case alpha characters are submitted within the FOC, PRD, POD, STA, or CLS fields, the XML request message will not pass the XML schema validation.

Empty-element tags may be used for any element that has no content and as such are disregarded by VUI except in cases where element content is required.

Several additional requirements on VUI XML message contents have been set. There are several characters with special meanings that may not appear in an XML document, including the. A full listing of invalid characters may be found in the W3C XML specification. These characters must be replaced as follows:

& becomes &

< becomes <

Also, a VUI XML request message may not contain a CDATA section—special characters must be escaped individually as described above. Most XML libraries perform this modification automatically. Requests containing CDATA are rejected by our XML schema.

All responses from VUI to the customer use this structure:

<HDR>

<REC>[Response record count]</REC>

</HDR>

[Response message]

</Payload>

<TRL>

<REC>[Response record count]</REC>

</TRL>

</VUI >

3.2 Error Response

If the VUI system receives an XML message it is unable to parse, the following error message is returned in the Payload section of the standard response structure, described in Section 3.0:

</ErrorResponse>

The RC1 tag contains an error code and a detailed description of the parsing error, if possible (refer to Appendix A: Return Codes and Descriptions), and the REQ tag contains a CDATA-delimited copy of the original message to assist customers in troubleshooting their requests.

3.3 MSAG Query Request

The customer uses this transaction to request the MSAG data that matches their specified query criteria.

3.3.1 MSAG Query Request Structure

This message must be placed under the Payload tag in the standard VUI request message, described in Section 3.1.

<HNO> [optional]

<PRD> [optional]

<POD> [optional]

<STS> [optional]

<STN> [optional if MCN is present, otherwise required]

<MCN> [optional if STN is present, otherwise required]

<STA> [required]

</MSAGQueryRequest>

The customer uses this transaction to request the MSAG data that matches their specified query criteria.

The STN and MCN tags may include wildcard characters. The asterisk (*) is the wildcard for any number of characters, and the question mark (?) is the wildcard to indicate any single character. An MSAG query must contain an STA tag and either an MCN or STN tag, with all other data tags optional.

NOTE: The POD and STS fields are specified by the NENA recommendation but do not exist in Intrado’s MSAG database. When an MSAG query request is submitted, the fields are appended to the STN field. For example, if a request contains these fields:

the system will treat it as if the following was sent in:

Responses append the data contained within the POD and STS fields within the STN field.

Also, the Intrado MSAG database backend will attempt to find additional streets when a query produces no results. For example, if a query is sent in with the STN set to “MAIN”, the system may return results for “MAIN ST” and “MAIN AVE.” This may produce unexpected results in certain circumstances because of the behavior mentioned above. For example, if a request is sent in with these fields:

the system will treat it as a request with the STN set to “MAIN S,” which will then return potentially misleading results for “MAIN ST.”

3.3.2 MSAG Query Response Structure

This structure is passed back to the customer in the Payload section of the standard VUI response structure, described in Section 3.1:

<PRD>

<STN>

<MCN>

<STA>

<COI>

<LOR>

<HIR>

<OEI>

<EXC>

<ESN>

<SRT>

</MSAGRange>

</MSAGData>

[additional MSAGData sections for each result returned]

</MSAGQueryResponse>

The OEI tag will not be present in the response if the House Number Range is valid for both odd and even house numbers.

The RC1 tag indicates either success (0) when records have been returned or failure (1) if no records exist. If the query was performed successfully, one or more MSAGData tags are included in the message payload, representing the data queried.

The MSAGQuery returns a number of records up to the specified recordLimit. VUI may also limit the response size in order to optimize performance based upon the current number of simultaneous client systems and requests.

When the number of records that match the query exceeds what can be returned in a single response, a sequence of repeated identical queries may be used to retrieve all the records. The user-supplied continuation attribute identifies these related queries. Each query in the same continuation group begins where the previous query left off.

An RC2 tag is returned indicating either this response has returned the last set of records available (value 1) or that more records that match this query (value 0) are available.

Repeatedly sending in the same request with the same continuation attribute value continues to return the next set of records matching the query until RC2 indicates no more records are available (value 1):

…

NOTE

1. Several query sequences can be in progress at the same time by the user providing distinct continuation attribute values.

2. The continuation mechanism is implemented using HTTP cookies. This requires the user application to return any cookies sent it in the subsequent continuation request.

3.4 MSAG Pre-Validation

The customer uses this transaction to request that Intrado perform an MSAG pre-validation of the specified address. If the pre-validation request data refers to one or more MSAG entries, the record is considered to be valid. If the request data refers to zero records, the record is considered to be invalid.

3.4.1 MSAG Pre-Validation Request

<HNO> [required]

<PRD> [optional]

<POD> [optional]

<STS> [optional]

<STN> [required]

<MCN> [required]

<STA> [required]

<EXC> [optional]

</MSAGValidationRequest>

The behavior of the STS and POD tags is the same as in an MSAG query – see the note above.

3.4.2 MSAG Pre-Validation Response

If the MSAG data supplied is valid (meaning that it produces one or more MSAG street and range entries), the system responds with this message:

</MSAGValidationResponse>

If the MSAG data supplied is NOT valid (meaning that it produces zero results), the system responds with this message:

</MSAGValidationResponse>

3.5 TN Query

The customer uses this transaction to request the TN data that matches their specified query criteria. Wildcard queries are currently not supported.

The customer only has access to TN data for the CPNs that they own.

3.5.1 TN Query Request Structure

<CPN>3035815600</CPN> [required]

</ALIQueryRequest>

3.5.2 TN Query Response

<CPN>

<HNO>

<HNS>

<PRD>

<STN>

<MCN>

<STA>

<LOC>

<NAM>

<CLS>

<TYP>

</CLS>

<TYS>

<TYP>

</TYS>

<EXC>

<ESN>

<MTN>

<ORD>

<CPD>

<COI>

<CPF>

<ZIP>

<CUS>

<CMT>

<TAR>

<ALT>

</ALIData>

</ALIQueryResponse>

The behavior of the STS and POD tags are the same as in an MSAG query – see the note above.

3.6 TN Update

The customer uses this transaction to insert, change, or delete TN records in the TN databases.

The customer can only update TN data for the CPNs that they own.

3.6.1 TN Update Request Structure

<CPN> [required]

<HNO> [required]

<HNS> [optional]

<PRD> [optional-refer to Section 4.0 for all valid entries]

<STN> [required]

<MCN> [required]

<STA> [required]

<LOC> [optional]

<STS> [optional]

<POD> [optional-refer to Section 4.0 for all valid entries]

<NAM> [required]

<CLS> [required]

<TYP> [required]

</CLS>

<TYS> [required]

<TYP> [required]

</TYS>

<EXC> [optional]

<MTN> [required]

<ORD> [optional]

<CPD> [optional, must be formatted CCYY-MM-DD if data element present]

<CPF> [required]

<ZIP> [optional]

<CUS> [optional]

<CMT> [optional]

<TAR> [optional]

</ALIUpdateRequest>

NOTE: The POD and STS fields are specified by the NENA recommendation but do not exist in Intrado’s database. When a TN Update request is submitted, the fields are appended to the STN field. Responses will append the data contained within the POD and STS fields within the STN field.

3.6.2 TN Update Response Structure

</ALIUpdateResponse>

The optional RC2 and RC3 tags may contain validation error codes if the data passed in for update fails validation. These tags will follow the same structure as the RC1 tag.

4 XML Data Element Descriptions

Type Values: A = Alpha and spaces, N = Numeric, S = Special Characters [# @& * ( ) - _ + , .: ;”‘’ /]

XML Tag	Field Name	Description		Max Length	Data Type
Acct	Account Number	Intrado account number for the customer sending the request.		N/A	AN and hyphen “-“
Client Version	Client Software Version	Version of client software being used to communicate with VUI.		20	ANS
CLS	Class of Service	Class of Service for the Calling Party Number. Subtags: <TYP> (1 character, required) Valid Entries for TYP subtag:		1	AN
CLS	Class of Service	1 = Residence 2 = Business 3 = Residence PBX 4 = Business PBX 5 = Centrex 6 = Coin 1 Way Out 7 = Coin 2 Way 8 = Wireless Phase 0	9 = Residence OPX 0 = Business OPX A = Customer Owned Coin B = Generic Use G = Wireless Phase I H = Wireless Phase II C = VoIP Centrex V = VoIP Residence U = VoIP Business O = VoIP Residence PBX P = VoIP Business PBX	1	AN

		Note: The system will generate an error response ‘3’ if a value other than the above is populated in the TYP subtag.
CMT	Comments	Optional telephone company notes. May be displayed at PSAP.		30	ANS
COI	County ID	County identification code (usually the FIPS code).		3	AN
Continuation	Continuation Attribute	User-supplied string that uniquely identifies an MSAG query such that if the MSAG Query is broken into several XML responses, the client system is able to re-query VUI using the continuation attribute to retrieve the next set of records for the same MSAG Query.		36	AN and Hyphen “-“

XML Tag	Field Name	Description	Max Length	Data Type
CPD	Completion Date	Service order completion date in format YYYY-MM-DD.	10	N and hyphen “-“
CPF	Dial Tone Company ID	NENA registered company identification code for the service provider providing facilities for dial tone to the customer.	5	ANS
CPN	Calling Party Number	Number of the CPN. The Emergency Location Identification Number (ELIN) belongs in this field. The ELIN is a valid North American Numbering Plan format telephone number assigned to the multi-line telephone system’s operator by the appropriate authority that is used to call a PSAP and is used to retrieve the ALI for the PSAP. The ELIN may be the same number as the ANI. In some cases, the North American Number Plan number may not be a dialable number.	10	N
CPS	Data Provider Company ID	NENA registered company identification code for the service provider/reseller/private switch supplying ALI record source information. Note: This tag is present in the NENA specification but does not exist in the Intrado backend database and is discarded from any update requests.	5	ANS
CUS	Customer Code	Code used to uniquely identify a subscriber.	3	ANS
ESN	Emergency Service Number	Emergency Service Number associated with the house number, street name, and community name.	5	N
EXC	Exchange	Abbreviated name of the switching entity that provides dial tone.	4	ANS
FOC	Function Code	Type of activity the record is being submitted for. Valid entries: C Change D Delete I Insert M Migrate U Unlock	1	A
HDR	Header	Header information.	0
HIR	High Range	The highest house number that is included in this ESN definition.	10	ANS
HNO	House Number	House number for the CPN.	10	ANS

XML Tag	Field Name	Description	Max Length	Data Type
HNS	House Number Suffix	House number extension for the CPN.	4	ANS
LOC	Location	Additional address information (free formatting). The Emergency Response Location (ERL) belongs in this field. The ERL is a location to which a 9-1-1 emergency response team may be dispatched. The location should be specific enough to provide a reasonable opportunity for the emergency response team to quickly locate a caller. This information may be displayed at the PSAP.	20	ANS
LOR	Low Range	The lowest house number that is included in this ESN definition.	10	ANS
MCN	MSAG Community Name	Valid community name as identified by the MSAG.	32	AS
MSAGData	MSAG record data	Contains a single MSAG entry and all the data associated with it.	0	N/A
MSAGRange	MSAG Range information	Contains ranges of street addresses.	0	N/A
MTN	Main Telephone Number	Ten-digit telephone number of the main billing number associated with the CPN.	10	N
NAM	Customer Name	Subscriber name associated with the CPN.	32	ANS
OEI	Odd/Even Indicator	The indicator on the street to indicate if this is the odd number part of the street, the even number part of the street, or both odd and even number parts of the street. Valid Responses: O – Odd numbering only E – Even numbering only	1	A
ORD	Order Number	Service order number for the activity associated with this record.	10	ANS
Payload	Message Payload	Transaction request information.	0	N/A
POD	Post Directional	Trailing street direction suffix. Valid values are: N, E, S, W, NE, NW, SE, and SW. Note: The system will generate an error response ‘3’ if a value other than the above is populated in the POD tag.	2	A

XML Tag	Field Name	Description	Max Length	Data Type
PRD	Prefix Directional	Leading street direction prefix. Valid values are N, E, S, W, NE, NW, SE, and SW. Note: The system will generate an error response ‘3’ if a value other than the above is populated in the PRD tag.	2	A
RC1	Return Code	Code indicating specific processing error code or processing completed successfully. See Appendix A for return codes and the corresponding description. Note: The description attribute is intended to be an informative message and does not map directly to the numeric return code.	3	N
RC2	Return Code 2	Code indicating specific processing error code or processing completed successfully. See Appendix A for return codes and the corresponding description.	3	N
RC3	Return Code 3	Code indicating specific processing error code or processing completed successfully. See Appendix A for return codes and the corresponding description.	3	N
REC	Record Count	The number of records in the request or response.	9	N
recordLimit	Maximum Response Records	Maximum number of records to return from a query. Must be greater than zero.	3	N
REQ	Request Message Sent	The request message that was sent to the Validation and Update Service from the customer.	Unlimited	ANS
SRT	E9-1-1 Control Office	9-1-1 Control Office CLLI as identified in the Bellcore Local Exchange Reference Guide (LERG).	11	ANS
STA	State	Alphabetic state abbreviation.	2	A
STN	Street Name	Valid service address of the CPN.	48	ANS
STS	Street Name Suffix	Valid street abbreviation, as defined by the U.S. Postal Service Publication 28 (e.g., AVE). Note: This tag is specified by NENA but is not present in the Intrado backend database. If this tag is included in a request, it will be appended to the end of the STN tag. This tag will never be present in output messages.	4	A
TAR	TAR Code	Taxing Area Rate Code	6	ANS
TRL	Trailer record	Trailer information	0	N/A
TYP	Type	Subtag to CLS and TYS tags	1	AN
TYS	Type of Service	Type of Service for the Calling Party Number. Subtags: <TYP> (1 character, required)	1	N

XML Tag	Field Name	Description	Max Length	Data Type
		Valid entries for TYP subtag: 0 = Not FX or Non-Published 1 = FX in 9-1-1 serving area 2 = FX outside 9-1-1 serving area 3 = Non-Published 4 = Non-Published FX in 9-1-1 serving area 5 = Non-Published FX outside 9-1-1 serving area 6 = Local Ported Number (LNP) 7 = Interim Ported Number 8 = PS/ALI Published 9 = PS/ALI Non-Published Note: The system will generate an error response ‘3’ if a value other than the above is populated in the TYP subtag.
ver	VUI XML document revision number	Used to identify different versions of the VUI API.		NS
ZIP	Zip Code and Zip Code + 4	Postal zip code. Format: NNNNN or NNNNN-NNNN	10	N and hyphen “-“

Appendix A: Return Codes and Descriptions

Note: Description text may vary slightly from description text returned by the VUI application.

VUI Response Messages

Response Code		Description
0		Query successful. One or more records returned.
000		TN update successful
1		Query returned no records
2		Internal system error (VUI)
3		Unable to parse XML message
4		Request failed validation. One or more required data fields are not populated.
5		Internal system error (TSS)

TN Update Error Messages

Error Code		Description
100		Customer Code is not numeric
101		NPA/NXX is not found
105		Customer Name is missing
107		House Number is invalid
115		Invalid Class of Service
126		Invalid Type of Service
701		MSAG range not found for submitted House Number
702		A subscriber record already exists in the database for this TN. Unable to Insert record.
703		Pilot record does not exist
704		TN record does not exist for Delete
705		Pilot record does not exist for Delete
709		Street not found in the MSAG
710		Customer Code does not match existing subscriber record Customer Code (Change service orders only)
711		Customer Code or Street Criteria does not match existing subscriber record (Delete service orders only)
712		TN record does not exist for Change
713		TN and Pilot number mismatch
731		A record exists in the database with a Completion date that is equal to or greater than the submitted Completion date
734		Pilot has sublines and cannot be deleted
735		A record exists in the database with a Completion date that is equal to or greater than the submitted Completion date (Delete service orders only)
737		Address cannot be updated. This record may be locked, please contact your Intrado representative.

Error Code		Description
741		PS/ALI Locked record
742		Class of Service does not match Pilot Class of Service
743		Type of Service does not match Pilot Type of Service
744		Customer Name does not match Pilot Customer Name
749		Customer Code does not match Pilot Customer Code
752		Invalid Company ID
753		Record does not exist for Unlock
754		No record exists for Migrate
755		Record already exists for another company (Migrate service orders only)
756		Record already exists for another company (Change service orders only)
757		Record already exists for another company (Delete service orders only)
758		Record already exists for another company (Unlock service orders only)
761		Pilot exists for another company
762		Company ID cannot be less than 3 characters
763		Pilot delete orphaned sublines
765		Invalid CLLI Code
783		Unlock on Pilot with sublines attached
792		Record already exists for another company (Insert service orders only)
793		Zip Code missing (VoIP records only)
799		House Number, Street Name, or Community name is missing.
801		Geocode Interface Unavailable
802		Geocode Data Error

Appendix B: Acronyms and Definitions

ALEC – Alternate Local Exchange Carrier

ALI – Automatic Location Identification

ANI – Automatic Number Identification

BLEC – Business Local Exchange Carrier

CLEC – Competitive Local Exchange Carrier

CPN – Calling Party Number

DLEC – Data Local Exchange Carrier

ELIN – Emergency Location Identification Number

ERL — Emergency Response Location

ESN — Emergency Service Number

HTTPS – Secure Hypertext Transfer Protocol

ILEC – Incumbent Local Exchange Carrier

MSAG – Master Street Address Guide

PBX – Private Business Exchange

PS – Private Switch

PSAP – Public Safety Answering Point

SOI – Service Order Input

SRDB – Selective Routing Database

VoIP – Voice over Internet Protocol

VPN – Virtual Private Network

XML – eXtensible Markup Language

Appendix C: State Abbreviation Codes

State		Abbreviation
ALABAMA		AL
ALASKA		AK
ARIZONA		AZ
ARKANSAS		AR
CALIFORNIA		CA
COLORADO		CO
CONNECTICUT		CT
DELAWARE		DE
DISTRICT OF COLUMBIA		DC
FLORIDA		FL
GEORGIA		GA
HAWAII		HI
IDAHO		ID
ILLINOIS		IL
INDIANA		IN
IOWA		IA
KANSAS		KS
KENTUCKY		KY
LOUISIANA		LA
MAINE		ME
MARYLAND		MD
MASSACHUSETTS		MA
MICHIGAN		MI
MINNESOTA		MN
MISSISSIPPI		MS
MISSOURI		MO
MONTANA		MT
NEBRASKA		NE
NEVADA		NV
NEW HAMPSHIRE		NH
NEW JERSEY		NJ
NEW MEXICO		NM
NEW YORK		NY
NORTH CAROLINA		NC
NORTH DAKOTA		ND
OHIO		OH
OKLAHOMA		OK
OREGON		OR
PENNSYLVANIA		PA
RHODE ISLAND		RI
SOUTH CAROLINA		SC
SOUTH DAKOTA		SD
TENNESSEE		TN
TEXAS		TX
UTAH		UT
VERMONT		VT
VIRGINIA		VA
WASHINGTON		WA
WEST VIRGINIA		WV
WISCONSIN		WI
WYOMING		WY

Appendix D: Revision History

Revision Number	Date	Description of Change
1.5	September 2004	Removed the XML Data Elements that will not be part of VUI, release 1.1. Added MSAG Query continuation attribute. Performed format changes to Section 4.0 Removed Section 7.0. “Batch Transactions.” This section will be included in the VUI, release 1.1.

1.6	October 2004	Added alpha character case treatment details to section 3.1. Added Appendix C: State Code Abbreviations Revised Section 4.0 to enumerate special characters accepted by VUI. Removed error conditions 103 and 120. Added error conditions 105, 799

Appendix E

Intrado VoIP Emergency Calling Service

Geographical Routing Interface
using XML Elements (GRIXE)

Developed by Intrado
July 17, 2003

This confidential and proprietary document contains confidential and proprietary information of Intrado Inc. Under no circumstances should this document, its contents, or any portion thereof, be distributed without the prior written consent of Intrado Inc. If you are in possession of this document, its contents, or any portion thereof without the express written consent of Intrado Inc. immediately destroy said materials and notify Intrado Inc. at (720) 494-5800.

INTRADO

Document Description

This document represents Intrado’s external interface specifications for Call Processing Centers requiring emergency call routing to an IntelliVector^SM Position Server.

Intellectual Property

© 2002, 2003 Intrado Inc., Longmont, Colorado, USA – All rights reserved. Neither this document nor any part thereof may be reproduced, distributed, transmitted, or altered in any fashion by any entity (either internal or external to Intrado) except in accordance with applicable agreements, contracts or licensing, or with the express written consent of Intrado.

Intrado, triangle beacon design, Informed Response, IntelliVector, and the logo forms of the foregoing, are trademarks and/or service marks of Intrado Inc. in the United States, other countries, or both and may be registered therein.

Disclaimer

Table of Contents

1.0	Overview		4

2.0	Protocol Stack		4

3.0	Network Architecture		6

4.0	Session Establishment		7

5.0	Query Response Call Flows		7

	5.1	Calls Treated as Native 9-1-1 Calls	8

	5.2	Calls Treated as Anonymous Calls	9

6.0	Call Processing Center Interface Messages		10

	6.1	GRIXE Query/Response Messages	10

	6.2	GRIXE Call Termination Report (Optional)	12

	6.3	GRIXE Heartbeat Report (Optional)	12

Appendix A: XML Message Examples			14

Appendix B: XML Data Definition			16

1.0 Overview

This specification describes the interface between a Call Processing Center (CPC)(1) and Intrado’s IntelliVector^SM Position Server (PS). This interface is called the Geographical Routing Interface using XML Elements (GRIXE). This interface is part of the network specification for delivery of emergency service calls from a CPC requiring routing instruction to the caller’s local Emergency Services Network(2). The specification supports parameters that would allow routing of the call as a native 9-1-1 call. The CPC vendor provides subscriber records of their customer base. The records include customer name, address, city, state, county, and zip code. The customer addresses are then geo-coded to provide latitude and longitude (X/Y) coordinates for each subscriber. The Telephone Number (TN), subscriber record, and X/Y coordinates are stored in the PS system. When an emergency call is received at the CPC, a query containing the caller’s TN is sent to the PS System over this new interface. Based on the received TN, the PS retrieves the X/Y coordinates. The Coordinate Routing Database (CRDB) is queried by the PS with those X/Y coordinates to determine the PSAP serving area and returns it to the PS. The PS uses the PSAP serving area received from the CRDB to determine the routing data for this call. The PS returns the routing data across the GRIXE interface to allow the CPC to route the call to the appropriate PSAP.

The protocol for this interface is XML message sets transported using Hypertext Transfer Protocol (HTTP) over TCP/IP. This protocol specifies the query and response messages and call termination message between the Call Processing Center and Position Server.

2.0 Protocol Stack

The protocol stack used for the GRIXE interface is shown in Figure 2-1. The XML encoded message content is transported using HTTP over TCP/IP. IP provides the capability to route the messages between the CPC and the PS. The intervening network elements (for example, routers and firewalls) need only use IP to correctly route the session setup message and subsequent packets.

IP provides a connectionless, “best-effort” delivery service. IP’s responsibilities include the transmission of a block of data received from upper layers as well as the message addressing. The combination of an IP header preceding a block of data constitutes a datagram. If a link layer failure occurs during datagram transmission, IP’s behavior rules do not specify that the datagram be present.

The transport layer (for example, TCP) is responsible for this datagram retransmission functionality. TCP provides a reliable, connection-oriented, byte stream, transport layer service. It provides the reliability by performing the following functions:

1. Resizing application layer packets into the proper buffers for the network layer.

2. Sending acknowledgments for each block of data received.

3. Retransmitting unacknowledged data blocks.

4. Making sure that the transmitted packets are received through the use of acknowledgement timers.

(1)		Call Processing Center refers to an entity that receives calls and has the capability to route those calls to a network for completion to their final destination.

(2)		Emergency Services Network refers to the network that has connections to Public Safety Answering Point (PSAP)s. PSAPs handle emergency calls.

5. Maintaining a checksum for the header and data.

6. Discarding duplicate blocks of data.

7. Providing flow control that prevents a faster host from overrunning a slower one.

HTTP is responsible for routing and encapsulating the XML content. It is a request/response protocol involving a server and a client. The CPC takes the role of the client and requester, and the PS is the server that responds to the messages. HTTP has the capability to provide a secure interface but, for the purpose of this interface, that capability is not required since the emergency service network is a secure private domain.

CPC	ROUTER	ROUTER	PS

XML HTTP TCP/IP PHYSICAL	IP PHYSICAL	IP PHYSICAL	XML HTTP TCP/IP PHYSICAL

Figure 2-1: Logical Network Element Connectivity

The HTTP exchange, shown in Figure 2-2, between the CPC and the PS consists of the following messages:

CPC Request

CPC Response

CPC Call Terminations (optional)

Heartbeat (optional)

The following HTTP message flow encapsulates the CPC query/response messages:

Figure 2-2: HTTP Exchange

3.0 Network Architecture

Figure 3-1 below represents the network architecture to allow the CPC to pass client related information to the PS and receive routing information so that the call can be delivered to the PSAP.

The CPC may be a single call center or redundant, geographically distributed locations as shown in Figure 3-1. Normal operation would have a primary call processing center that would process calls and a secondary one that would be used for disaster recovery. The Position Server will always operate in a redundant, geographically distributed configuration. The mated pair will operate in primary/secondary configuration where the secondary Position Server may take over for the primary if the primary is removed from service.

In this configuration there is a logical link between each CPC and each PS. The network connection between the CPC and the PS is expected to be either a private packet-based network or a dedicated point-to-point environment.

Figure 3-1 Network Configuration

4.0 Session Establishment

For the GRIXE interface, the TCP/IP address and port are agreed upon between the owners of the CPC and the PS. By convention, the PS is the TCP/IP server and the CPC is the TCP/IP client. The sessions are established via sockets where the CPC establishes the connection to the PS. Upon system start up the PS will listen to the designated port, and the CPC will initiate session set up to the designated TCP/IP address and port. Once the socket session is established, the application may begin the query and response handshake.

5.0 Query Response Call Flows

When the CPC queries the PS, there are two call flows that can be expected. The first is where the PSAP is covered by this application and the call can be delivered as a native 9-1-1 call. In this scenario, the PS returns an Emergency Services Routing Number (ESRN) and an Emergency Services Query Key (ESQK). The ESRN identifies the terminating switch in the Emergency Services Network and is used by the CPC to route the call. The ESQK is a query key that is valid for the life of the call, is routed along with the ESRN through the network, and is used by the PSAP to query for a customer subscriber record. The second scenario is where the PSAP is not covered by this application and the call must be routed to the PSAP as an anonymous call. The PS returns the PSAP DN to the CPC and the CPC routes the call using the PSAP DN. In this case, there will not be any subscriber information available to the PSAP.

5.1 Calls Treated as Native 9-1-1 Calls

The flow illustrated in Figure 5-1 shows the scenario where the ESQK and ESRN are returned to the CPC. The CPC can then route the call through the Public Switched Telephone Number (PSTN) to the Emergency Services Network so it can be handled as a native 9-1-1 call.

Figure 5-1: Native 9-1-1 Call where ESQK and ESRN are returned to the CPC

1. The CPC has received an emergency call and sends an XML query to the Position Server. At a minimum, Subscriber Telephone Number (Subscriber_TN), Provider ID (PROVIDER_ID), Date Stamp (ADS), and Time Stamp (ATS) are sent in the query. Additional information may also be passed.

2. The Position Server retrieves the X/Y coordinates based on the Subscriber_TN and queries the Coordinate Routing Database (CRDB) with those coordinates.

3. The CRDB returns the PSAP ID and PSAP DN of the PSAP that is serving the area of the caller.

4. The Position Server uses the PSAP ID to determine the ESRN associated with the terminating switch in the Emergency Service Network and an ESQK that will be associated with this call. It returns these along with the Date Stamp (ADS) and Time Stamp (ATS) to the CPC.

5. The CPC routes the call through the PSTN using the ESRN as the Called Party Number and the ESQK as the Calling Party Number.

The ESRN enables routing the call to the E9-1-1 Selective Router in the Emergency Service Network that is local to the caller and identifying the call as an emergency. Once the call has been identified as an emergency, normal 9-1-1 call processing takes over. The ESQK is then used as the caller’s Automatic Number Identification (ANI) for use in selectively routing the call to the correct PSAP and retrieving the caller’s Automatic Location Identification (ALI) record from the Position Server. The ALI record contains the caller’s real callback number and their location, i.e. postal address.

5.2 Calls Treated as Anonymous Calls

If the Emergency Services Network is not set up to handle CPC emergency calls across the PSTN, calls can still be delivered to the correct PSAP. This is done by routing the call to the 10-digit local exchange line terminating at the PSAP. Calls to these lines cannot be treated as native 9-1-1 calls. This means that the PSAP cannot query for information associated with the caller. This call flow is shown in Figure 5-2.

Figure 5-2: Calls Treated as Anonymous Calls

1. The CPC has received an emergency call and sends an XML query to the Position Server. At a minimum, Subscriber_TN, Provider ID (PROVIDER_ID), Date Stamp (ADS) and Time Stamp (ATS) are sent in the query. Additional information may also be passed.

2. The Position Server retrieves the X/Y coordinates based on the Subscriber_TN and queries the CRDB with those coordinates.

3. The CRDB returns the PSAP ID and PSAP DN of the PSAP serving the area of the caller.

4. The Position Server uses the PSAP ID to attempt to determine the ESRN and an ESQK but finds that this PSAP does not support CPC calls as native 9-1-1 calls. The PS returns the 10-digit local exchange DN to the PSAP along with the ADS and ATS to the CPC.

5. The CPC routes the call through the PSTN using the PSAP DN as the Called Party Number. The call is then delivered to the PSAP local exchange line.

6.0 Call Processing Center Interface Messages

The GRIXE message set uses XML based application messages between the CPC and the PS. These message sets are defined in Appendix B; example messages are found in Appendix A. There are three types of messages: query/response, call termination, and Heartbeat. The query/response messages allow the CPC to query the PS and have the PS respond with routing numbers. The call termination message is an optional message from the CPC to the PS, which allows the PS to release transient call data upon completion of the call. The Heartbeat message allows a client to determine at regular intervals if the link and the PS application are still alive and functioning.

6.1 GRIXE Query/Response Messages

The CPC queries the PS for routing information. The CPC will query with a Call Processing Center Query (CPCQ) message with type=“Q”. The expected elements are Subscriber TN (key/Callback Number), ADS (Day), ATS (Time), Provider ID (PROVIDER_ID), and Service Provider Number (SPN). The format of the query is:

elements

</CPCQ>

The expected elements are defined as:

ADS – The Date Stamp provides the UTC (Coordinated Universal Time) date when the query is made. Expressed in the format CCYYMMDD where CCYY is the four-digit year, MM is the month, and DD is the day of the month.

ATS – The Time Stamp provides the UTC time when the query is made. Expressed in military format HHMMSS where HH is hours, MM is minutes, and SS is seconds.

SPN – The Service Provider 7x24 number is expected and is required to be a full ten-digit North American Numbering Plan (NANP).

Subscriber_TN – The Subscriber TN element is the key component used to determine the emergency service network for the caller. Records for all subscribers are pre-provisioned in the PS. The records include the physical location of the subscriber. This is required to be a full 10-digit North American Numbering Plan (NANP).

PROVIDER_ID – The NENA Company ID of the CPC.

Optional elements:

POS – The position provides an identifier for the Call Processing Center. This could identify the CPC if there are multiple locations, or this could be an agent ID if the center supports attendants and desires to uniquely identify agents serving these calls.

Message_ID – The message identification field is used to correlate the query with the response. If this element is included in the CPCQ, the CPCR will include a Message ID element with the same integer value as it received. This element is useful when a persistent connection is supported by the CPC to keep track of outstanding responses. The field is defined to be an integer that supports up to 6 digits, value 0-999999.

The Position Server will respond with a CPCR message with the type=“R”. If the PSAP serving area is equipped to handle this native 9-1-1 application the expected response elements are ESRN, ESQK, STATUS(0), ADS, and ADT. If the PSAP serving area is not supported by this application, the Position Server will return the PSAPDN, STATUS(6), ADS, and ADT. If the Subscriber TN has not been provisioned on the PS, the Position Server will return STATUS(8), ADS, and ATS. For any other type of error condition, the STATUS element in the message, along with ADS and ATS, will be returned to explain the error condition. The format of the response is:

elements

</CPCR>

The expected elements are:

ESQK – The ESQK is a unique key assigned from a pool of keys by the PS to the call for the duration of the call. It is passed through the network with the call set up and used by the PSAP to query for information related to this incident. (Required full ten-digit NANP format.)

ESRN – The ESRN designates the terminating switch in the Emergency Services Network. It is assigned by the PS and used by the CPC to route the call through the PSTN. (Required full 10-digit NANP format.)

PSAPDN – The PSAP DN is the 10-digit local exchange telephone number at the PSAP, which will route to an Intrado telecommunicator at the ECRC who will then transfer the call to the correct PSAP. This line does not have any Emergency Services functionality associated with it. (Required full 10-digit NANP format.)

STATUS – Denotes if the response is normal (successful) or contains error information.

ATS – The Time Stamp provides the UTC time when the query is made. Expressed in military format HHMMSS where HH is hours, MM is minutes, and SS is seconds.

Optional element:

Message_ID – This element is included in the CPCR if the CPCQ contained one. The value included in the response will be the same integer value as received in the CPCQ/Message_ID.

STATUS type enumerations are:

0 Native 9-1-1 Delivery, Query Successful – Effect: ESRN and ESQK returned.

1 Resource Unavailable – Effect: Resource such as CRDB not available, no PSAP information returned.

2 Failed Parsing – Effect: Invalid XML structure or invalid data, no PSAP information returned.

3 Unauthorized Request – Effect: Query rejected.

4 Unrecognized Geodetic Information – Effect: No PSAP information can be returned.

5 Resource Exhaust – Effect: Possible error such as ESQK exhaust, PSAP DN will be returned.

6 PSAP DN Delivery – Effect: Return a PSAP DN (expected delivery for non-native 9-1-1 application).

7 General System Error – Effect: Unspecified system error, no PSAP information can be returned.

8 Subscriber TN not provisioned – Effect: No PSAP information can be returned.

6.2 GRIXE Call Termination Report (Optional)

A call termination report is sent from the CPC to the PS when the emergency call is terminated. This will allow the PS to release transient data, such as ESQKs, so they may be used for subsequent calls. The message only pertains to those calls where the CPCR included an ESQK and ESRN. It is not applicable when only the PSAP DN was provided. Some CPCs may not maintain the knowledge of the type of call in progress (for example, emergency) so this message is optional. Call Termination Report messages received by the Position Server for which no ESQK or ESRN were allocated will be ignored. A response to this message from the PS to the CPC is not required. This message is a CPCQ with type=“T”. The expected parameters are Provider (PROVIDER_ID & SPN), Subscriber_TN, ADS, and ATS. The format of the message is:

elements

</CPCQ>

6.3 GRIXE Heartbeat Report (Optional)

A Heartbeat messages can be sent by the CPC to verify the integrity of each logical link connection to the Position Server. These will be initiated by the CPC and responded to by the Position Server. The initiation of the Heartbeat message is denoted by a CPCQ message with the type of “H” and should only be sent during times of inactivity. The Position Server will respond to the Heartbeat message with a CPCR message with the type of “H”. The parameters ADS and ATS are expected in both the CPCQ and CPCR.

The CPC is expected to maintain the logic for determining corrective action to take if it does not receive a response from the PS. The format of the heartbeat query and response are as follows:

CPC to PS

elements

</CPCQ>

PS to CPC

elements

</CPCR>

Appendix A: XML Message Examples

CPC Query and Response – Returning ESQK and ESRN

Query (CPCQ)

Response (CPCR)

<?xml version=“1.0” standalone=“yes”?>

<PROVIDER_ID>MyCPC</PROVIDER_ID>

</PROVIDER>

<Message_ID>101</Message_ID>

<Subscriber_TN>6305551212</Subscriber_TN >

</CPCQ>

<?xml version=“1.0” standalone=“yes”?>

<Message_ID>101</Message_ID>

<STATUS type=“0”> Native 9-1-1 Delivery

</STATUS>

</CPCR>

CPC Query and Response – Returning PSAP DN

Query (CPCQ)

Response (CPCR)

<?xml version=“1.0” standalone=“yes”?>

<PROVIDER_ID>MyCPC</PROVIDER_ID>

</PROVIDER>

<Subscriber_TN>6305551212</Subscriber_TN >

</CPCQ>

<?xml version=“1.0” standalone=“yes”?>

<STATUS type=“6”> PSAP DN Delivery

</STATUS>

</CPCR>

CPC Query and Response — Error Response

Query (CPCQ)

Response (CPCR)

<?xml version=“1.0” standalone=“yes”?>

<PROVIDER_ID>MyCPC</PROVIDER_ID>

</PROVIDER>

<Subscriber_TN>63055554444</Subscriber_TN >

</CPCQ>

<?xml version=“1.0” standalone=“yes”?>

<STATUS type=“ 8”>Subscriber TN not provisioned

</STATUS>

</CPCR>

CPC Call Termination

CPC CC Sends Call Termination

<?xml version=“1.0” standalone=“yes”?>

<PROVIDER_ID>MyCPC</PROVIDER_ID>

</PROVIDER>

<Subscriber_TN>63055512127</Subscriber_TN >

</CPCQ>

CPC Heartbeat

CPC CC Initiates Heartbeat

Position Server Heartbeat Response

<?xml version=“1.0” standalone=“yes”?>

</CPCQ>

<?xml version=“1.0” standalone=“yes”?>

</CPCR>

Appendix B: XML Data Definition

Notes:

1. Elements in the diagrams surrounded by dashed lines are optional; elements in solid lines are mandatory for the message.

2. In the context of a query or response, some elements are expected. For example, for a normal CPCQ, a subscriber TN must be present. But for a CPCQ that is a heartbeat, it is not expected. The expected elements are defined in the text.

Schema GRIXE-V2.xsd

element ADS

element ATS

element CPCQ

element CPCQ/Subscriber_TN

element CPCR

element CPCR/ESRN

element CPCR/ESQK

element CPCR/PSAPDN

element CPCR/STATUS

element Message_ID

element PROVIDER

element PROVIDER/PROVIDER_ID

element PROVIDER/POS

Appendix F

Intrado Project Escalation Contact List

In an effort to manage the project within the timeframes and functionality outlined in the Statement of Work attached herein, it may be necessary to escalate issues within each party’s organization. Each Party shall mutually provide project escalation contact information. The following Intrado project escalation contacts are to be used in the order provided.

Intrado Contact/Title	Contact Information

Sean Fitzsimmons	Office:	720.494.5815
Customer Team Director, VoIP Operations	Cell:	303.885.7668
	Email:	sfitzsimmons@intrado.com
John Hickey	Office:	720.864.5139
Vice President & General Manager Competitive Customer	Cell:	303.588.5295
Services, Wireline Delivery Services Group	Email:	jhickey@intrado.com
Mary Hester	Office:	720.494.5940
Vice President, Wireline Delivery Services Group	Cell:	720.839.0214
	Email:	mhester@intrado.com

Appendix G

V9-1-1 Mobility Services

Standard Acceptance Test Plan

Using the GRIXE/GRISIP Interface

Document:	Generic GRIXE/GRISIP Test Plan 12-14-04.doc
Revision Number:	1.0
Status:	Standard Test Plan
Document Date:	12-14-04

Pre-Test Document Signoff

Customer
	Name	Date

Supplier
	Name	Date

Post-Test Document Sign off. Sign below to indicate the tests were satisfactorily completed.

Customer
	Name	Date

Supplier
	Name	Date

Supplier/Confidential & /Proprietary

This document contains confidential and proprietary information owned by Supplier Corp. (“Supplier”), and such information may not be used or disclosed by any person without the prior written consent of Supplier.

SQA Test Plan Revision History

Revision #		Date		Author		Description of Change
1.0		12-14-04		Supplier		Standard Test Plan

Supplier Test Project Team

Project Representatives

Product/Program Management

Development Liaisons

Operations Liaisons

Change Control Board Representatives

Customer Test Project Team

Project Representatives

Product/Program Management

Development

Operations Liaisons

SQA

Network Operations Center (NOC) Ops

Change Control Board Representatives

Intrado - Confidential & Proprietary

STANDARD TEST PLAN FOR DISCUSSION PURPOSES ONLY

Table of Contents

SQA Test Plan Revision History		2

Supplier Test Project Team		2

Customer Test Project Team		2

1.0	Introduction	4

1.1	Executive Summary	4

1.2	Project Scope	4

1.3	Definitions, Acronyms, and Abbreviations	4

1.4	References	5

1.5	Assumptions	5

2.0	Test Strategy	5

2.1	Approach	5

2.2	Acceptance Test Techniques	6

2.3	Test Documentation	6

3.0	Test Environment	6

3.1	Hardware	6

3.2	Software	7

4.0	Overview of Testing Activities	7

4.1	Items Included in Test	7

4.2	Items Excluded from Test	7

4.3	Test Entrance Criteria	7

4.4	Test Exit Criteria	8

4.5	Test Suspension and Resumption Criteria	8

4.6	Problem/Change Request Tracking	8

5.0	QA Risk Assessment	8

6.0	Document and Version Control	8

7.0	Schedule	9

8.0	Test Cases	9

Introduction

1.1 Executive Summary

This document describes the acceptance end-to-end test plan for V911. Wide Area Network (WAN) functionality, Call Processing (for normal and fail-over scenarios) and Data File Management will be tested. Internal integrated test plans will be used to test internal processes and procedures in addition to this plan. There are four main features of this test.

1. Network – Validation of WAN Infrastructure

2. Call Processing – Automated – uses GRIXE/GRISIP, IPS and telecom infrastructure.

3. Call Processing – Manual – uses the ECRC and telecom infrastructure

4. VoIP Calling Number and Address Provisioning – Automated – uses the Intrado Validation and Update Interface, VUI

The test plan covers standard and non-standard queries and responses to achieve call completion for calls made over the VoIP network. Supplier’s tracking system will be used to log results. A regularly scheduled test meeting will be used to review the results and plan any re-testing required.

The test runs during a mutually agreed upon period. The test includes active participation by the Customer and Supplier. Post-document sign-off indicates the service is ready to launch.

1.2 Project Scope

This document covers the test approach, resources, specific functionality, schedule, assumptions, and risks of the testing activities that will be performed for this release.

1.3 Definitions, Acronyms, and Abbreviations

IPS		Supplier Positioning Server that stores CUSTOMER subscriber data.
ECRC		Emergency Call Relay Center at Supplier routes fail-over calls to PSAPs.
GRISIP		Geographical Routing Interface using SIP is a query interface from the CUSTOMER softswitch to the Supplier IPS.
GRIXE		Geographic Routing Interface using XML Elements is a query interface from the CUSTOMER softswitch to the Supplier IPS.
PSAP		Public Safety Answering Point is the location where emergency calls are received/answered.
SQA		Software Quality Assurance (Testing).
TN		Telephone Number.
ICMP		Internet Control Message Protocol: Also known as the “ping” command.
		The ping command allows a user to test continuity of a physical interface at the far end of a circuit.
CR		Change Request.

Severity Levels		As follows: • Severity Level 1: Critical: A critical or significant function is not available and no work around exists. Examples: A total system failure that results in a loss of all transaction processing capability

E9-1-1 data corrupted or not being processed or made available within business guidelines
Major network backbone outage without redundancy

• Severity Level 2: Serious: A non-critical software component does not function and there is no workaround. Examples:

Service and/or other work order commitments delayed or missed

Single link failure (in dual-link environment)

Hardware/software failure that affects system capacity

• Severity Level 3: Moderate: Some loss of functionality to major or minor components of application, but acceptable workaround exists to the’s satisfaction. Examples:

Equipment taking hard errors, no impact yet

Redundant peripheral equipment down

External interface link instability

• Severity Level 4: Minimal. Cosmetic flaws and trivial problems that do not impact usability. Examples:

Device or software regularly has to be reset, but continues to work and the outage does not result in significant business pain

Questions regarding normal operations

System anomalies that only occur once

1.4 References

Document		Version
Executed Contract		Signed

1.5 Assumptions

• The tests will require coordination between Supplier and CUSTOMER.

• Provisioning will be tested via the Intrado VUI.

• CUSTOMER will activate 9-1-1 calling for three (3) to four (4) of CUSTOMER’s subscribers.

• Supplier will provide scripts for the callers during the ECRC tests.

2.0 Test Strategy

2.1 Approach

• Development is being performed at Supplier and CUSTOMER’s facility.

• There will only be one (1) milestone code drop when 100% of the code will be delivered for testing.

• Testing will begin once the code is fully unit tested and delivered to CUSTOMER.

• Supplier will provide a list of zip codes that are supported by three (3) to four (4) selected PSAPs.

2.2 Acceptance Test Techniques

The test effort consists of multiple end-to-end integrated tests to verify overall functionality. In addition, smaller functional tests are included to verify specific requirements. As testing progresses, existing tests may be modified or new tests written to explore as yet unseen areas of concern.

As areas of concern are encountered, members of the test team will mutually decide how to proceed as follows:

• Note area of concern in comments area of test case and proceed with testing.

• Contact development to share information and explore options.

• Identify area of concern as a Defect and open a Change Request ticket. CUSTOMER to send email to Product Manager.

• Identify area of concern as a future enhancement and open a CR ticket. CUSTOMER to send email to Product Manager.

• Decide if testing can continue.

2.3 Test Documentation

• This test plan will be added to Supplier’s Document Library once it is baselined.

• Test Cases and Test Results will be stored and managed using this test plan. Results can be requested by any team member.

• All Change Requests (“CR”) will be tracked using Supplier’s ticketing system. Project management has the ability to create reports containing any and all tickets generated during the test interval. Outstanding CRs will be discussed in the daily test meetings.

• Test results and release notes will be published by the Supplier team lead and added to the Supplier Document Library at the end of the test interval.

• Supplier and will sign-off that they are ready to launch. Each company will maintain a copy of the sign-off sheet.

3.0 Test Environment

3.1 Hardware

• IPS 0 In Longmont.

• IPS 1 In Miami.

• Circuit 1: From [Customer location A] to Longmont.

• Circuit 2: From [Customer location A] to Miami.

• Circuit 3: As needed, Frame Relay from [Customer location B] to Longmont.

• Circuit 4: As needed, Frame Relay from [Customer location B] to Miami.

• VUTAPP01 and VUTAPP02 servers for VUI.

• Router Cards in Supplier’s routers in Longmont and Miami.

3.2 Software

• GRIXE/GRISIP Interface

• IPS subscriber database

• Validation and Update Interface

4.0 Overview of Testing Activities

4.1 Items Included in Test

A checklist of functions to be tested is included in Section 8 of this document.

4.2 Items Excluded from Test

Items that do not cross between the two companies are not included in this test plan. For example, CUSTOMER address verification is solely a CUSTOMER function and is not included herein.

4.3 Test Entrance Criteria

Testing can begin when the following conditions are met:

• Development has all source code for this release checked into the source code control system.

• System Configuration Management can install the system objects on the appropriate machines.

• Mitigation of risk: If Acceptance Testing possibly is performed on the production system, Supplier will bring associated risk to the attention of CUSTOMER and mitigate that risk to a mutually acceptable level.

• Subscriber or subscriber test data must be loaded to the Supplier IPS prior to test. Three records need to be loaded that do not have an associated x, y coordinates.

• Customer connection to the Supplier’s VUI server must be established.

• Web access to CUSTOMER’s subscriber database must be established.

• Three (3) test terminating VoIP boxes must be provided by CUSTOMER and deployed at Supplier for the purpose of placing test calls.

4.4 Test Exit Criteria

The test cycle will end when all of the following conditions are met:

• 100% of the identified test cases are completed or mutually agreed that they won’t be executed.

• There are no outstanding Severity Level 1 or Severity Level 2 CRs generated during the test cycle.

• The joint Customer/Supplier team agrees that other outstanding CRs generated during the test cycle are not of sufficient concern to prevent installation of the software on a production system as determined by the lead Product Managers.

• All outstanding CRs generated during the test cycle will be documented in the Test Results section of this document.

4.5 Test Suspension and Resumption Criteria

Suspension Criteria – Testing will be suspended if a defect is encountered that prevents any further testing from occurring.

Resumption Criteria – The appropriate code change or updated procedure is approved by the Parties and implemented. The test (or tests) that resulted in the original defect will be re-executed in order to resume testing.

4.6 Problem/Change Request Tracking

Supplier’s ticketing system will be used to track all defect and enhancement requests identified during the test interval.

5.0 QA Risk Assessment

Timeframes: Access times required to access Customer’s subscriber database have to be determined. Sufficient time for testing needs to be available (three weeks).

6.0 Document and Version Control

• Supplier’s software version control tool is used to catalog all Supplier software.

• Supplier maintains all documents in the Supplier Document Library.

7.0 Schedule

• All test scenarios will have a test date. Network tests will be performed first, followed by GRIXE/GRISIP, VUI, and then by ECRC tests.

• As mentioned above, all circuits are expected to be available by prior to testing.

• The IPS1 and IPS0 are both expected to be available for testing.

8.0 Test Cases

The test cases included here are as follows:

Network Validation

N1. Physical interface ICMP test of Frame Relay to Longmont.

N2. Physical interface ICMP test of Frame Relay to Miami.

N3. Host-to-host ICMP – Location A

N4. Host-to-host ICMP – Location B (if needed)

N5. Host-to-hosts ICMP for ACL verification.

GRIXE/GRISIP and IPS

G1. PSAP routing information utilizing ESRN and ESQK.

G2. CPCQ with invalid Provider ID.

G3. CPCQ exceeds 3 seconds.

G4. Response exceeds 3 seconds on both IPSs.

G5. CPC heartbeat request and response.

G6. CPCQ with no lat/long match in CRDB.

G7. CPCQ with TN not provisioned.

VUI Provisioning Scenarios

VI. Process VUI Update request as expected.

V2. Update request fails MSAG validation.

V3. Update request fails geocoding process.

V4. Update request with required data element(s) missing.

V5. VUI error from provisioning system unavailability.

ECRC Scenarios

El. ECRC receives call and routes to appropriate PSAP based on ANI.

E2. ECRC receives two simultaneous calls; routes to PSAPs based on ANI.

E3. ECRC receives call and routes it using the caller’s address.

E4. ECRC receives a call and the caller can not speak. Route to PSAP based on ANI.

E5. ECRC receives call and caller can not speak. No address in the Supplier database. ECRC queries subscriber system with TN to obtain address.

E6. ECRC receives call – caller can not speak and there is no ANI. Call NOC to trace call, get address.

Network Validation Tests

Test Case Number N1	Name – Physical Interface ICMP test of Frame Relay to Supplier in Longmont.	Description – Test Physical interface between CUSTOMER and Supplier equipment interfaces.

General Comments: Test will determine whether the Layer 1 (Physical interface) is operational between the serial interfaces of the routers. Both sides will ping each other’s router at the serial interface.

a. Details: Frame Relay between Longmont and Customer location

Test Results:

Test Case Number N2	Name – Physical Interface ICMP test of Frame Relay to Miami.	Description – Test Physical interface between CUSTOMER and Supplier equipment interfaces.

General Comments: Test will determine whether the Layer 1 (Physical interface) is operational between the serial interfaces of the routers. Both sides will ping each other’s router at the serial interface.

Details: Frame Relay between Longmont and Customer location.

Test Results:

Test Case Number N3	Name – Host to Host ICMP	Description – Perform ICMP test between CUSTOMER and Supplier Host equipment interfaces.

General Comments: Test will determine whether the Layer 3 (TCP/IP) is operational between the CUSTOMER and Supplier Host locations. Expected result is a successful time indication for each of the ping tests

Details: Test will determine whether the Host in [CUSTOMER LOCATION A] and the Supplier Hosts in Longmont, CO and Miami, FL are able to communicate.

Test Results:

Test Case Number N4	Name – Host to Host ICMP – [CUSTOMER location B] if needed	Description – Perform ICMP test between CUSTOMER and Supplier Host equipment interfaces.

General Comments: Test will determine whether the Layer 3 (TCP/IP) is operational between the CUSTOMER and Supplier Host locations. Expected result is a successful time indication for each of the ping tests.

Details: Test will determine whether the CUSTOMER Host in [ALTERNATE LOCATION B] and the Supplier Hosts in Longmont, CO and Miami, FL are able to communicate.

Test Results:

Test Case Number N5	Name – Host to Host ICMP for ACL verification	Description – Perform ICMP test between CUSTOMER and Supplier Host equipment interfaces. This test will verify implementation of Access Control List to limit host visibility.

General Comments: Test will determine whether the Layer 3 (TCP/IP) is operational between the Hosts terminating each point.

Detail:

Test Results:

GRIXE/GRISIP Test Precondition:

• CUSTOMER subscriber records populated in IPS with x,y coordinates;

• A few CUSTOMER subscriber records without x,y coordinates (error case);

• Fail over to validate access to mate IPS requires both nodes in service;

• Coordinate Routing Database in service and accessible by IPS;

• Multiple Subscriber TNs in varying demographic locations - demonstrate routing based on caller’s location.

Test Case Number G1 - ips 1.1_systest_00300	Name – PSAP DN returned	Description – CUSTOMER sends a CPCQ with subscriber TN. Intrado returns a CPCR with the PSAP DN and status code 6.

General Comments: Call routes to PSAP based on location of TN. PSAP DN and Status code 6 is returned to CUSTOMER in CPCR. Call is routed from the CPCR, through the selective router to the appropriate PSAP. The PSAP bids the ali and returns the correct V-911 information.

TNs to be tested are:

Test Results

Test Case Number G2 - ips l.l_systest_00415	Name – CPCQ with invalid Provider ID		Description – Send CPCQ with invalid Provider ID. A CPCR will be returned with status code 3.

General Comments – Validation of all queries is by the Company ID (NENA ID). All requests (except Heartbeat) must include the PROVIDER_ID with a value that is provisioned on the IPS. Any requests that contains an invalid (not recognized) ID will result in a CPCR with status code 3. Provisioned data is duplicated on both IPSs so if one fails, the other will as well. Validate the call is answered by the ECRC.

NENA ID is		PROVIDER_ID is		.

Test Results

Test Case Number G3	Name – CPCQ exceeds 3 seconds	Description – CUSTOMER has a timer set when it queries the IPS. For this test case, no response is received so CUSTOMER should fail over to query the mate IPS.

General Comments: This requires some manipulation of the primary route at the customers Softswitch. The actual primary IP of the Softswitch should be replaced at the customers Softswitch with an invalid IP. When the call is made, the initial query should time out. A secondary query should be sent to the secondary IP, and the call should process as it did in test case G1.

Test Results:

Test Case Number G4	Name – Response exceeds 3 seconds on both IPS	Description – CUSTOMER has a timer set when it queries the IPS, fails over to query the alternate and that query also times out. CUSTOMER should fail over and set call up to ECRC

General Comments – General Comments: This requires some manipulation of the primary and secondary IP addresses at the customer softswitch. The customer should enter a fictitious IP for both their primary and secondary ip routes to Intrado. The initial query as well as the secondary query should fail. At that point the customer softswitch should send the call to Intrado’s ECRC.

Test Results:

Test Case Number G5 - ips1.1_systest_00700	Name – CPC Heartbeat Request / Response	Description – CUSTOMER sends a CPC Heartbeat and sends a Heartbeat response. This just validates basic functionality.

General Comments

Testing Results

Test Case Number G6 ipsl.l_systest_00510	Name – CPCQ with no latitude / longitude match in CRDB	Description – For this test, a CUSTOMER record must exist in the subscriber record database with Lat/Longitude information which falls outside of our current CRDB PSAP coverage IPS will respond to CPCQ with a CPCR and status code 4. It is expected that CUSTOMER will query the mate link, fail that query with the same status code and then route to the ECRC.

General Comments – The record is still loaded in the Subscriber Record database (managed by Intrado) with a Lattitude/Longitude outside of the CRDB PSP coverage. The call will be routed to the primary IPS and then fail-over to the secondary IPS. The response will include the status code of 4. The call will then be sent from the customer softswitch to the Intrado ECRC.

TNs to be used are , ,

Results:

Test Case Number G7 - ips l.l_systest_00505	Name – CPCQ with TN not provisioned	Description – CUSTOMER sends a CPCQ with TN that is not provisioned in the subscriber record database. Intrado will return a CPCR with status code 8. It’s expected that CUSTOMER will query the mate IPS. On receipt of status code 8 from the mate IPS, CUSTOMER would then route the call to the ECRC.

General Comments: The subscriber record for this TN has not been populated on either IPS.

TNs to be tested are , ,

Test Results:

Validation and Update Interface Tests

Test Case Number V1	Process VUI Update request as expected.	Description: A valid update request is submitted and processes through MSAG validation and geocoding without err. A transaction is returned indicating successful provisioning.

General Comments –

Test Results:

Test Case Number V2	Update request fails MSAG validation.	Description: A valid update request is submitted and fails MSAG validation but processed through geocoding without err. A transaction is returned indicating unsuccessful MASG validation (error 701/709).

General Comments:

Test Results:

Test Case Number V3	Update request fails geocoding process.	Description: A valid update request is submitted and fails geocoding but processed through MSAG validation without err. A transaction is returned indicating unsuccessful geocoding (error 801/802).

General Comments:

Test Results:

Test Case Number V4	Update request with required data element(s) missing.	Description: An update request is submitted without a zip code. A transaction is returned indicating missing data element (error 793).

General Comments:

Test Results:

Test Case Number V5	VUI error from provisioning system unavailability.	Description: Attempt to submit an update request when the provisioning system is unavailable. Transaction is returned indicating the provisioning system is unavailable.

General Comments:

Test Results:

ECRC Scenario Tests

Test Case Number E1	Name – ECRC routes on ANI		Description: ECRC receives call and routes to PSAP based on ANI.

General Comments – The ECRC should be able to query the IPS using ANI to determine the appropriate PSAP to transfer the call to. This will also test the transfer functionality of the ECRC phones.

Step Number	Description	Check		Expected Results
1.	Query IPS with ANI provided	Test of IPS query application and IPS functionality		PSAP information should be returned.
2.	Transfer call to appropriate PSAP	Transfer functionality of the 9-1-1 call.		Call should be transferred to PSAP and the ECRC should be able to drop off the line and leave the caller and PSAP connected.

Test Results:

Test Case Number E2	Name – Simultaneous ECRC calls		Description – ECRC receives two calls and routes to appropriate PSAPs using ANI

General Comments – The ECRC should be able to query the IPS using ANI to determine the appropriate PSAP to transfer the calls to. This will also test the transfer functionality of the ECRC phones and the ECRC’s ability to handle multiple calls.

Step Number	Description	Check		Expected Results
1.	Query IPS with ANI provided	Test of IPS query application and IPS functionality		PSAP information should be returned.
2.	Transfer call to appropriate PSAP	Transfer functionality of the 9-1-1 call.		Call should be transferred to PSAP and the ECRC should be able to drop off the line and leave the caller and PSAP connected.

Test Results:

Test Case Number E3	Name – Call routed based on address.		Description – ECRC receives call and routes it using the caller’s address

General Comments – This will test the ECRC’s ability to route the call using the caller’s address.

TNs to be used

Step Number	Description	Check		Expected Results
1.	Obtain caller’s address and use GDT application to obtain lat and long	Tests functionality of the GDT application		Latitude and longitude of caller’s location should be returned.
2.	Copy and paste latitude and longitude into IPS/CRDB query tool.	Test copy and paste functionality		Should be able to copy and paste latitude and longitude into IPS Query application
3.	Query CRDB	Tests CRDB query		PSAP information returned
4.	Transfer call to appropriate PSAP	Transfer functionality of the phones		Call should be transferred to PSAP and the ECRC should be able to drop off the line and leave the caller and PSAP connected.

Test Results:

Test Case Number E4	Name – Caller can’t speak – route based on ANI.		Description – ECRC receives a call and caller cannot speak but ANI is provided. ECRC finds address in subscriber database based on ANI, and routes call to appropriate PSAP

General Comments – The ECRC should be able to query the IPS using ANI to determine the appropriate PSAP to transfer the call to. This will also test the transfer functionality of the ECRC phones.

TNs to be used

Step Number	Description	Check		Expected Results
1.	Query IPS with ANI provided	Test of IPS query application and IPS functionality		PSAP information should be returned.
2.	Transfer call to appropriate PSAP	Transfer functionality of the phones		Call should be transferred to PSAP and the ECRC should be able to drop off the line and leave the caller and PSAP connected.

Test Results:

Test Case Number E5	Name –Caller can’t speak / no ANI and no address in Supplier database.		Description – ECRC receives a call and the caller cannot speak. ANI is provided but address is not found in subscriber database. ECRC calls CUSTOMER NOC to obtain address. ECRC finds PSAP and routes call.

TNs to be used

Step Number	Description	Check		Expected Results
1.	Query IPS with ANI provided	Test of IPS query application and IPS functionality when a record is not in the database		PSAP information will not be returned.
2.	Call CUSTOMER NOC and provide them with ANI	Ability to quickly obtain subscriber address information from		CUSTOMER provides subscriber address information
3.	Use GDT application to obtain lat and long for subscriber address	Tests functionality of the GDT application		Latitude and longitude of caller’s location should be returned.
4.	Copy and paste latitude and longitude into IPS/CRDB query tool.	Test copy and paste functionality		Should be able to copy and paste latitude and longitude into IPS Query application
5.	Transfer call to appropriate PSAP	Transfer functionality of the phones		Call should be transferred to PSAP, ECRC should be able to drop off the line and leave caller and PSAP connected.

Test Results:

Test Case Number E6	Name – Caller can’t speak / no ANI provided.		Description - ECRC receives call but there is no ANI and caller cannot provide information. ECRC calls NOC to have a trace done on the call.

Step Number	Description	Check		Expected Results
1.	ECRC calls CUSTOMER NOC to do a trace on the call	Ability to obtain Subscriber address information from when the ECRC does not have ANI		CUSTOMER will provide subscriber address information.
2.	Query IPS with ANI provided	Test of IPS query application and IPS functionality when a record is not in the database		PSAP information will be returned.
3.	Transfer call to appropriate PSAP	Transfer functionality of the phones		Call should be transferred to PSAP and the ECRC should be able to drop off the line and leave the caller and PSAP connected.

Test Results:

Appendix H

Abbreviated Project Plan for VoIP V9-1-1^SM Mobility Services

The following Services tasks, responsibilities, and timelines are subject to change based on mutual agreement between the Parties:

TASK	PRIMARY RESPONSIBILITY	ESTIMATED EFFORT DURATION (BUSINESS DAYS)	TARGET START DATE	TARGET END DATE
*Customer Setup – Data Connectivity For Provisioning*
Establish network connectivity for provisioning Subscriber records
• Circuit (see establish network connectivity below)	Intrado/Customer	50

*Customer Setup – Subscriber Record Submission*
Establish Customer accounts on V9-1-1 provisioning systems for Subscriber record submission
• VUI	Intrado/Customer	5
Develop to provisioning interface	Customer	50
Submit test records	Customer	5
Provision test records	Intrado	5

*Customer Setup – Call Flow*
Establish network connectivity for emergency call routing queries
• Frame Relay (PVC)	Intrado/Customer	20
• Frame Relay (New)	Intrado/Customer	50
• T1	Intrado/Customer	50
Develop to GRIXE Interface for call routing instructions	Customer	30
Submit test queries – Lab	Customer/Intrado	5
Submit test queries – Production	Customer/Intrado	5

*Customer Setup – ECRC Setup*
Establish connectivity to ECRC for emergency call routing query fail over	Intrado	10
Establish DN for Customer on Circuit 1 PRI-Tl
• Update PBX to accept Customer ECRC fail-over calls	Intrado	5
• Test circuit/ECRC setup	Intrado	5

*Customer Setup – Web-Based Application*
Establish access to the Customer’s VoIP Subscriber database	Customer	30

Test access to Customer’s VoIP Subscriber database	Intrado	2

*Services Readiness*
Train ECRC	Intrado	5
Train Customer NOC	Customer	10
Test with select Customer Subscribers	Intrado/Customer	5

*V9-1-1 Launch*
Acceptance Go/No-Go	Customer/Intrado	5
Launch – Services Turn-up	Customer	3

Appendix I

Intrado Deployment Schedule and Timeline

Provided Intrado’s performance is not prevented or made commercially impracticable by the non-cooperation of the applicable ILECs, PSAPs, state and local governmental agencies, 9-1-1 authorities and any other requisite third-party, Intrado will provide Customer with the Services (which will be provided via dedicated connectivity) in the following markets, which will be fully operational and available to Customer (including the satisfactory completion of all acceptance testing) on or prior to November 28^th, 2005.

Geographic Area/MSA
Boston, MA
New York City, NY
N. New Jersey
Connecticut
Philadelphia/Delaware
S. New Jersey
Atlantic City/Philadelphia
Atlanta
Miami
Washington DC/N. Virginia
Baltimore/Maryland
Dallas
Houston
Detroit
Minneapolis
Seattle
Chicago
Cleveland
Los Angeles
San Francisco

In the event (i) Services have not been deployed in one or more of the above markets by Intrado by November 28, 2005; or (ii) Services do not support all functional requirements of 47 CFR Part 9 in any of the above geographic areas where Services have been deployed by November 28, 2005, Customer may terminate this SOW and all applicable Attachments without penalty and without regard to whether such failure is caused by the non-cooperation of any of the above-described third parties.

AMENDMENT #1 TO
AGREEMENT FOR SERVICES
BETWEEN
INTRADO INC. AND VONAGE NETWORK INC.

This Amendment #1 (“Amendment”) to the Agreement for Services is hereby entered into by and between INTRADO INC. (“INTRADO”) and VONAGE NETWORK INC. (“CUSTOMER”), collectively referred to herein as the “Parties” and individually as “Party.”

RECITALS

WHEREAS, INTRADO and CUSTOMER executed that certain Agreement for Services bearing a date of April 27, 2005, but executed on or about July 13, 2005 (“Agreement”)

WHEREAS, the Parties desire to memorialize the rates to be charged under the Agreement for certain records falling outside of Intrado’s V9-1-1 footprint and to clarify further Appendix A to the VoIP V9-1-1 Mobility Services Statement of Work (“SOW”) attached to the Agreement as Attachment B thereto.

NOW, THEREFORE, in consideration of the mutual promises and covenants set forth herein and other valuable consideration, the receipt and sufficiency of which is hereby acknowledged, the Parties agree as follows:

1. Effective Date of this Amendment

This Amendment shall be effective upon execution by both Parties.

2. Replacement of Appendix A to SOW

The Agreement is hereby amended by deleting Appendix A to the SOW in its entirety and substituting therefor the attached Appendix A.

3. Defined Terms

Capitalized terms not defined herein shall have the meaning ascribed to them in the Agreement.

4. Modification of the Agreement and this Amendment #1

Upon execution by the Parties, this Amendment shall become part of the Agreement. All terms and conditions of the Agreement that are not inconsistent herewith and are not modified by this Amendment shall remain unaffected and in full force and effect. Inconsistent terms or conditions, as between the Agreement and this Amendment, shall be governed by this Amendment.

WITNESSETH, The Parties have indicated their acceptance and agreement to the terms and conditions of this Amendment, as indicated by the signatures of the authorized individuals below.

INTRADO INC.		VONAGE NETWORK INC.


/s/ MARY HESTER		/s/ LOUIS MAMAKOS
Signature		Signature

MARY HESTER, SR. VP		LOUIS MAMAKOS, PRESIDENT
Printed Name and Title		Printed Name and Title

10/4/05		30 SEPT 2005
Date		Date

Appendix A: Services Fees

The following fee(s) and payment schedule for Services as described in this SOW will apply:

I. One-Time Fees:

Fee Descriptions:		At Contract Signing
Service Licensing and Activation, One Time Fee (“OTF”)		$75,000

SoftSwitch connection to pair of IntelliVector Position Servers, OTF		Waived

II. Recurring Fees:

Fee Descriptions		Fee:
Monthly Recurring Charge (“MRC”)
• Begins upon Effective Date hereof • Does not Include NYC Gateway Services ($10K per Month)		$*, per month

Telephone Number, recurring fee for Records outside of Intrado V9-1-1 Footprint treated as ECS records		$0.05 per TN

Telephone Number, recurring fee for Records within Intrado V9-1-1 Footprint (ALI and CBN delivered with Service) • TNs within Each Tier take on that Tier’s Pricing
• 0 — 1,000000 TNs		$* per TN
• 1,000,001 — 1,500,000 TNs		$* per TN
• 1,500,001 — 2,000,000 TNs		$* per TN
• 2,000,001 — 2,500,000 TNs		$* per TN
• 2,500,001 — 3,000,000 TNs		$* per TN
• 3,000,001 — 3,500,000 TNs		$* per TN
• 3,500,001 — 4,000,000 TNs		$* per TN
• Tiering Continues at Intervals of 500K TNs and 1 penny reduction until 10,000,000 TNs are reached
• >10,000,000 TNs		$.09 per TN
Per V9-1-1 Query, recurring fee		$*, per query
Per Automated ECS Query (PSAP 24x7 Line Returned)j V9-1-1 Address Geocoding, recurring fee		$* per query
• Automated address geocoding		$*, per address
• Manual address geocoding and error resolution		$* per hour
• Emergency Call Relay Center • To apply only until execution of Intrado Call Center Solutions (ICCS) SOW		$* per call

• The pricing set forth will not be binding on either party unless the SOW is executed by both parties by September 29th, 2005.

MRC and other recurring fees will be prorated on a thirty (30) calendar day month for the first monthly recurring fee invoice billing.