Exhibit 10.15


 


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-1SM Mobility Services for City of New
York Statement of Work for Vonage Network Inc. and Attachment B - VOIP V9-1-1SM
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.


 


2

















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.


3

















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.


 


4

















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 


 


5

















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.


 


6

















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

  
					



 


 


7














 


Attachment


 


VoIP V9-1-1SM Mobility

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:


© 2004-2005 Intrado Inc. All rights reserved.


 


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


 


ii

















 


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

  	
   

  



 


iv

















 


1                                         Introduction


 


This Statement of Work (“SOW”), effective as of July 8th,
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-1SM 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 VonageTM – IntradoTM 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-1SM 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-1SM
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 


 


1

















 


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.


 


2

















 


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.


 


3

















 


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

















 


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.


 


5

















 


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.


 


6

















 


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.


 


7

















 


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.


 


8

















 


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.


 


9

















 


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.


 


10

















 


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.


 


11

















 


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

  	
   

  



 


12

















 


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 (1st) day of such 






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


 


1

















 


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.


 


2

















 


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.


 


1

















 


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.


 


2

















 


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

  



 


i

















 


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


 


1

















 


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.


 


2

















 


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

















 





 


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.


 


4

















 





 


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:


 


5

















 





 


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:


 





 


6

















 


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:


 


7

















 





 


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.


 


8

















 


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.


 


9

















 


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:


 


10

















 





 


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.


 


11

















 


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


 


1

















 


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

  



 


2

















 


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


 


3

















 


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


 


4

















 


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.


 


5

















 


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>


<Payload>


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


 


6

















 


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:


 


<VUI
ver=“1.0”>


<HDR>


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


</HDR>


<Payload>


[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
ver=“1.0”>


<RC1 message=“UNABLE TO PARSE XML”>3</RC1>


<REQ><![CDATA[(original XML request message)]]>


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


 


<MSAGQueryRequest
ver=“1.0” [required] recordLimit=“l00” [required, 1-999]
continuation=“queryIdentification” [optional, refer to section 3.3.2] >


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


 


7

















 


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:


 


<STN>MAIN</STN>


<POD>S</POD>


<STS>ST</STS>


 


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


 


<STN>MAIN ST S</STN>


 


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:


 


<STN>MAIN</STN>


<POD>S</POD>


 


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:


 


<MSAGQueryResponse
ver=“1.0”>


<RC1 message=“SUCCESS”>0</RC1>


<MSAGData>


<PRD>


<STN>


<MCN>


<STA>


<COI>


<MSAGRange>


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


 


8

















 


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


 


<RC1 message=“SUCCESS>0</RC1>


<RC2 message=“Additional records
found”>0</RC2>


 


<RC1 message=“SUCCESS. Additional records
found>0</RC1>


<RC2 message=“Additional records
found”>0</RC2>


 


...


...


 


<RC1 message=“SUCCESS>0</RC1>


<RC2 message=“No additional records
exist”>1</RC2>


 


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


 


<MSAGValidationRequest ver=“1.0”>


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


 


9

















 


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
ver=“1.0”>


<RC1 message=“VALID, one or more records
found”>0</RC1>


</MSAGValidationResponse>


 


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


 


<MSAGValidationResponse
ver=“1.0”>


<RC1 message=“INVALID”>1</RC1>


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


 


<ALIQueryRequest
ver=“1.0”>


<CPN>3035815600</CPN> [required]


</ALIQueryRequest>


 


3.5.2       TN Query Response


 


<ALIQueryResponse
ver=“1.0”>


<RC1 message=“SUCCESS”>0</RC1>


<ALIData>


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


 


10

















 


<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


 


<ALIUpdateRequest
ver= “1.0” [required] FOC=“C” [required-refer to Section 4.0 for all valid
entries]>


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


 


11

















 


3.6.2       TN Update Response Structure


 


<ALIUpdateResponse
ver=“1.0”>


<CPN>3035551212</CPN>


<RC1 message=“SUCCESS”>0</RC1>


<RC2>0</RC2>


<RC3>0</RC3>


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


 


12

















 


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

  
	
  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 

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

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

  



 


13

















 


	
  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

  



 


14

















 


	
  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

  



 


15

















 


	
  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

  



 


16

















 


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

  



 


17

















 


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.

  



 


18

















 


	
  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

  



 


19

















 


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


 


20

















 


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

  	
   

  



 


21

















 


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

  



 


22














 


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


 


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.


 


2

















 


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

  
					



 


3

















 


1.0                               Overview


 


This specification describes the interface between a
Call Processing Center (CPC)(1) and Intrado’s IntelliVectorSM
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.

  



 


4

















 


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)


 


5

















 


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.


 


6

















 





 


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.


 


7

















 


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.


 


8

















 


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.


 


9

















 


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:


 


<CPCQ type=“Q” version=“1.0”>


 


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


 


10

















 


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:


 


<CPCR type=“R” version=“1.0”>


 


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.


 


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.


 


11

















 


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:


 


<CPCQ type=“T” version=“1.0”>


 


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.


 


12

















 


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


 


<CPCQ type=“H” version=“1.0”>


 


elements


 


</CPCQ>


 


PS to CPC


 


<CPCR type=“H” version=“1.0”>


 


elements


 


</CPCR>


 


13

















 


Appendix
A: XML Message Examples


 


CPC Query and Response – Returning ESQK and ESRN


 


	
  Query (CPCQ)

  	
   

  	
  Response (CPCR)

  
	
   

  	
   

  	
   

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

  <CPCQ
  type=“Q” version=“1.0”>

  <PROVIDER>

  <PROVIDER_ID>MyCPC</PROVIDER_ID>

  <POS>5011</POS>

  <SPN>2125552000</SPN>

  </PROVIDER>

  <ADS>20030730</ADS>

  <ATS>133045</ATS>

  <Message_ID>101</Message_ID>

  <Subscriber_TN>6305551212</Subscriber_TN
  >

  </CPCQ>

   

   

   

   

   

   

  	
   

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

  <CPCR
  type=“R” version=“1.0”>

  <ESQK>6305111234</ESQK>

  <ESRN>6305530074</ESRN>

  <ADS>20030730</ADS>

  <ATS>133046</ATS>

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

  <CPCQ
  type=“Q” version=“1.0”>

  <PROVIDER>

  <PROVIDER_ID>MyCPC</PROVIDER_ID>

  <POS>5011</POS>

  <SPN>2125552000 </SPN>

  </PROVIDER>

  <ADS>20030730</ADS>

  <ATS>123034</ATS>

  <Subscriber_TN>6305551212</Subscriber_TN
  >

  </CPCQ>

   

   

   

   

   

  	
   

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

  <CPCR
  type=“R” version=“1.0”>

  <PSAPDN>8155614325</PSAPDN>

  <ADS>20030730</ADS>

  <ATS>123035</ATS>

  <STATUS type=“6”> PSAP DN Delivery

  </STATUS>

  </CPCR>

  



 


14

















 


CPC Query and Response — Error Response


 


	
  Query (CPCQ)

  	
   

  	
  Response (CPCR)

  
	
   

  	
   

  	
   

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

  <CPCQ
  type=“Q” version=“1.0”>

  <PROVIDER>

  <PROVIDER_ID>MyCPC</PROVIDER_ID>

  <SPN>2125552000</SPN>

  </PROVIDER>

  <ADS>20030730</ADS>

  <ATS>153034</ATS>

  <Subscriber_TN>63055554444</Subscriber_TN
  >

  </CPCQ>

   

   

   

   

   

  	
   

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

  <CPCR
  type=“R” version=“1.0”>

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

  </STATUS>

  <ADS>20030730</ADS>

  <ATS>153035</ATS>

  </CPCR>

  



 


CPC
Call Termination


 


	
  CPC CC Sends Call Termination

  	
   

  	
   

  
	
   

  	
   

  	
   

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

  <CPCQ
  type=“T” version=“1.0”>

  <PROVIDER>

  <PROVIDER_ID>MyCPC</PROVIDER_ID>

  <SPN>2125552000</SPN>

  </PROVIDER>

  <Subscriber_TN>63055512127</Subscriber_TN
  >

  <ADS>20030730</ADS>

  <ATS>133559</ATS>

  </CPCQ>

  	
   

  	
   

  



 


CPC Heartbeat


 


	
  CPC CC Initiates Heartbeat

  	
   

  	
  Position Server Heartbeat
  Response

  
	
   

  	
   

  	
   

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

  <CPCQ
  type=“H” version=“1.0”>

  <ADS>20030730</ADS>

  <ATS>143034</ATS>

  </CPCQ>

   

   

  	
   

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

  <CPCR
  type=“H” version=“1.0”>

  <ADS>20030730</ADS>

  <ATS>143035</ATS>

  </CPCR>

  



 


15

















 


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


 





 


16

















 


element CPCQ


 





 


element CPCQ/Subscriber_TN


 





 


17

















 





 


element CPCR


 


18

















 


element CPCR/ESRN


 





 


element CPCR/ESQK


 





 


element CPCR/PSAPDN


 





 


19

















 


element CPCR/STATUS


 





 


element Message_ID


 





 


20

















 


element PROVIDER


 





 





 


element PROVIDER/PROVIDER_ID


 





 


element PROVIDER/POS


 





 


21

















 


element PROVIDER/POS


 





 


22






 










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


 


2

















 


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

  
				



 


3

















 


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

  



 


4

















 


	
   

  	
   

  	
  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.


 


5

















 


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


 


6

















 


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


 


7

















 


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


 


8

















 


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


 


9

















 


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.


 


10

















 


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: 
  

  



 


11

















 


	
  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:  

  



 


12

















 


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:

  



 


13

















 


	
  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:

  



 


14

















 


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:

  	
   

  	
   

  	
   

  	
   

  



 


15

















 


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:

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
									



 


16

















 


	
  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:

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
									



 


17

















 


	
  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:

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
									



 


18

















 


Appendix
H


Abbreviated Project Plan for VoIP V9-1-1SM
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

  	
   

  	
   

  	
   

  	
   

  	
   

  



 


19

















 


	
  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

  	
   

  	
   

  	
   

  	
   

  	
   

  



 


20

















 


 


	
   

  	
  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 28th, 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.


 


1














 


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.


 


1

















 


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

  



 


2

















 


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.


•                                          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 (1st) day
of such 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.