Requesting Carrier Clause Samples

Requesting Carrier will monitor the 9-1-1 circuits for the purpose of determining originating network traffic volumes. Requesting Carrier will notify Ameritech if the traffic study information indicates that additional circuits are required to meet the current level of 9-1-1 call volumes.
View SourceView Similar (12)
Requesting Carrier and Ameritech shall work cooperatively to install and maintain a reliable network. Requesting Carrier and Ameritech shall exchange appropriate information (e.g., maintenance contact numbers, network information, information required to comply with law enforcement and other security agencies of the government and such other information as the Parties shall mutually agree) to achieve this desired reliability.
View SourceView Similar (8)
Requesting Carrier grants to Ameritech during the Term a non-exclusive, license to use the DA listings provided pursuant to this Agreement. DA listings provided to Ameritech by Requesting Carrier under this Agreement will be maintained by Ameritech only for purposes of providing DA information to Requesting Carrier Customers, and will not be disclosed to third parties. This section does not prohibit Ameritech and Requesting Carrier from entering into a separate agreement which would allow Ameritech to provide or sell Requesting Carrier's DA listing information to third parties, but such provision or sale would only occur under the terms and conditions of the separate agreement.
View SourceView Similar (2)
Requesting Carrier shall provide its Requesting Carrier Directory Customer Listings to Ameritech or its Publisher in a form and format acceptable to Ameritech or its Publisher. Requesting Carrier acknowledges that Ameritech or its Publisher may impose a charge for changes to Requesting Carrier Directory Customer Listings previously provided by Requesting Carrier to Ameritech or its Publisher.
View Source
Requesting Carrier. If utilizing Ameritech's database to perform the query function, Ameritech will ▇▇▇▇ the Requesting Carrier (or the Initial Billing Company (as defined in the MECAB)) for the query charges at Ameritech's tariffed rate.
View Source
Requesting Carrier and Ameritech shall work cooperatively to apply sound network management principles by invoking network management controls to alleviate or to prevent congestion. III.8 9-1-1 Service. III.8.1 Ameritech shall provide 9-1-1 Service to Requesting Carrier as described in this Section 3.9 in each Rate Center in which (i) Requesting Carrier is authorized to provide local Telephone Exchange Service and (ii) Ameritech is the 9-1-1 service provider.
View Source
Requesting Carrier shall access Ameritech’s Interoffice Transmission Facilities via Collocation or any technically feasible method pursuant to Section 2.2 of Schedule 9.5 at the Ameritech Central Office where that element exists and each DSX or OCN circuit will be delivered to Requesting Carrier’s Collocation space for an additional charge by means of a Cross-Connection, Requesting Carrier shall order Interoffice Transmission Facilities from Ameritech by delivering to Ameritech a valid and complete service order via an electronic Access Services Request interface. If after the Effective Date Ameritech makes available the ability to order Interoffice Transmission Facilities via the Provisioning EI. Requesting Carrier agrees to transition its ordering of such facilities from ASR to the Provisioning EI within thirty (30) days after Ameritech is capable of receiving such orders via Provisioning EI.
View Source
Requesting Carrier shall provide, at a minimum, the following information with respect to each piece of equipment it intends to Collocate in Ameritech’s Premises: (1) Name of Hardware and Software Manufacturer; (2) Model and Release Number; and (3) Third-party certification by an independent qualified testing facility and any necessary documentation that evidences compliance with the standards set forth in Section 12.4.2. Ameritech will review and confirm or deny Requesting Carrier’s list and description of equipment within ten
View Source
Requesting Carrier shall establish the Provisioning El on or before the Service Start Date so that it will submit all requests for CSRs and all orders for LNP through Ameritech's Provisioning EI. Ameritech shall have no obligation to accept manual or faxed requests for CSRs or provision any manual or faxed LNP Orders except as set forth in Section 10,13.2(b). ------------------
View Source

Related to Requesting Carrier

  • Acceptable Estimating System The Contractor shall maintain the acceptable status of their Estimating System and submit updates to the current status, if applicable

  • Directory Listing and Directory Distribution 41 5. Voice Information Service Traffic 43 6. Intercept and Referral Announcements 44 7. Originating Line Number Screening (OLNS) 44 8. Operations Support Systems (OSS) Services 44 9. Poles, Ducts, Conduits and ▇▇▇▇▇▇-▇▇-▇▇▇ ▇▇ ▇▇. Telephone Numbers 51 11. Routing for Operator Services and Directory Assistance Traffic 51 12. Unauthorized Carrier Change Charges 52 13. Good Faith Performance 52 INTERCONNECTION ATTACHMENT. 53 1. General 53 2. Points of Interconnection and Trunk Types 53 3. Alternative Interconnection Arrangements 57 4. Initiating Interconnection 58 5. Transmission and Routing of Telephone Exchange Service Traffic 59

  • Registration Data Directory Services Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with ▇▇▇ ▇▇▇▇, and a web-­‐based Directory Service at <whois.nic.TLD> providing free public query-­‐based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-­‐five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry. 1.1. The format of responses shall follow a semi-­‐free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database. 1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value. 1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together. 1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.

  • Loop Testing/Trouble Reporting 2.1.6.1 Telepak Networks will be responsible for testing and isolating troubles on the Loops. Telepak Networks must test and isolate trouble to the BellSouth portion of a designed/non-designed unbundled Loop (e.g., UVL-SL2, UCL-D, UVL-SL1, UCL-ND, etc.) before reporting repair to the UNE Customer Wholesale Interconnection Network Services (CWINS) Center. Upon request from BellSouth at the time of the trouble report, Telepak Networks will be required to provide the results of the Telepak Networks test which indicate a problem on the BellSouth provided Loop. 2.1.6.2 Once Telepak Networks has isolated a trouble to the BellSouth provided Loop, and had issued a trouble report to BellSouth on the Loop, BellSouth will take the actions necessary to repair the Loop if a trouble actually exists. BellSouth will repair these Loops in the same time frames that BellSouth repairs similarly situated Loops to its End Users. 2.1.6.3 If Telepak Networks reports a trouble on a non-designed or designed Loop and no trouble actually exists, BellSouth will charge Telepak Networks for any dispatching and testing (both inside and outside the CO) required by BellSouth in order to confirm the Loop’s working status. 2.1.6.4 In the event BellSouth must dispatch to the end-user’s location more than once due to incorrect or incomplete information provided by Telepak Networks (e.g., incomplete address, incorrect contact name/number, etc.), BellSouth will ▇▇▇▇ ▇▇▇▇▇▇▇ Networks for each additional dispatch required to repair the circuit due to the incorrect/incomplete information provided. BellSouth will assess the applicable Trouble Determination rates from BellSouth’s FCC or state tariffs.

  • Listing Application If shares of any class of stock of the Company shall be listed on a national securities exchange, the Company shall, at its expense, include in its listing application all of the shares of the listed class then owned by any Investor.