Outgoing calls to PSTN or PBX network through a Cisco IOS gateway fail with a re-order tone before the complete number is dialed

[TCC_2]

Core Issue

The resolution discusses a case where the re-order tone is heard before all the digits are dialed. This case applies to both MGCP and H.323 controlled gateways.

Outgoing calls to Public Switched Telephone Network (PSTN) through an H.323 gateway could fail with these symptoms:

• No ringback. Refer No ringback when an IP phone registered to Cisco CallManager makes an outbound call to a third-party H323 gateway or H323 gatekeeper .
• For Silence or dead air issue refer the document  A Cisco IP phone user does not hear busy tones.
• Call never completes. If the call never completes through a T1/Primary Rate Interface (PRI) link, refer the document Outgoing calls from IP phones to a PSTN through a T1, E1, or PRI link.

  If the circuit is an Analog E&M or Analog Foreign Exchange Office (FXO)/Foreign Exchange Station (FXS) port, verify that those circuits are operational. For more help, refer to the following:

  • How to troubleshoot the Analog E&M Circuits.
  • Common issues with the Analog FXO/FXS circuits.
• Re-order tone. If the re-order tone is heard after the complete number is dialed, refer the document Outgoing calls to PSTN/PBX network through an H.323 gateway.

For other issues with calls to PSTN or PBX networks through an Media Gateway Control Protocol (MGCP) gateway, refer to the following:

• Silence or dead air. This could be due to one-way voice audio. Refer to Troubleshooting One Way Voice Issues
• Re-order tone. If the re-order tone is heard after the complete  number is dialed, refer the document Outgoing calls to a PSTN or PBX network.

Resolution

To resolve this problem, refer to these options:

• If the calling phone is associated with a Calling Search Space (CSS), and the route pattern that matches the called number is in a partition, ensure that the partition of the route pattern is listed under the calling phone's CSS.
• If the phone's CSS already includes the route pattern's partition as described, reset the CSS and the calling phone. If the failure persists, refer to Setting up Cisco CallManager Traces for the TAC and present them to the Cisco Technical Support Website for further diagnosis.
• If the calling phone is associated with a CSS, but the router pattern that matches the called number is not in a partition, reset the CSSand the calling phone. If the failure persists, refer to Setting up Cisco CallManager Traces for the TAC and present them to Cisco Technical Support Website for further diagnosis.
• If the calling phone is not associated with any CSS, ensure the route pattern that matches the called number is in a partition. If it does, either remove the partition information from the route pattern, or add the partition to a CSS of the calling phone (based on your class of service policies).
• If no CSS or partitions are used, reset the calling phone to ensure the Distinguished Name (DN) is updated in Structured Query Language (SQL) database.

If the above options do not resolve the problem, refer to Troubleshooting Cisco IP Phone-to-Cisco IOS Gateway Calls (4.0 release). For other versions of CallManager, refer to the CallManager Troubleshooting Guides index, select the appropriate troubleshooting guide and navigate to the relevant chapter.

For more information on CSS and partitions, refer to Understanding and Using Partitions and Calling Search Spaces With Cisco CallManager 3.0.