孔乙己是站着喝酒而穿长衫的唯一的人。他身材很高大；青白脸色，皱纹间时常夹些伤痕；一部乱蓬蓬的花白的胡子。穿的虽然是长衫，可是又脏又破，似乎十多年没有补，也没有洗。他对人说话，总是满口之乎者也，叫人半懂不懂的。
因为他姓孔，别人便从描红纸上的“pan.baidu.com/s/1vGGSunfS-IMHd6RQGCuePw”这半懂不懂的话里，替他取下一个绰号，叫作wsyv。
孔乙己一到店，所有吃瓜的人便都看着他笑，有的叫道，“生肉，有能看得懂的嘛？”他不回答，对柜里说，“自带BBC英文声轨，自己当做听力练习”便排出五毛大洋。他们又故意的高声嚷道，“你一定又偷了人家的东西了！”孔乙己睁大眼睛说，“你怎么这样凭空污人清白……”“什么清白？萌新都不知道怎么用这代码！”孔乙己便涨红了脸，额上的青筋条条绽出，争辩道，“不会自己百度？……谷歌！……源文件名都没改，能算偷么？”接连便是难懂的话，什么“萌新固傻”，什么“者乎”之类，引得众人都哄笑起来：店内外充满了快活的空气。
When considering a new VOIP phone system for your office, among all the discussions surrounding requirements, usage cases and call flows, the question of how you get dial tone and how you host your system will come up. Depending on who you’re having this conversation with, you may find yourself a bit overwhelmed. Relax. It’s normal. Take a deep breath … that’s good … let it out … there we go. Now let’s discuss your options, their pros and cons, and maybe demystify some things.
No matter what phone system type you choose, you need to get your calls into it and out of your system. Some come with their own connectivity, some are bring-your-own-dial-tone. If you go with a phone system provided by your telco, they will usually take care of that connectivity for you. However, most telecom providers have the ability to provide that connectivity to any phone system you decide to go with.
A PRI is a T-1 line supporting 23 voice channels, meaning it will support up to 23 concurrent calls. The telco brings in the PRI as a physical cable, and as such, if you want to add more lines than 23 they have to run another physical cable. A major benefit to having a PRI is that there is zero dependency on your internet bandwidth. It also allows for a high-quality voice experience, and if you add a second PRI, can be set up for circuit failover. Unfortunately, as this is a physical cable, there’s going to be some drawbacks. If you want to add lines, the telco has to physically run another PRI and will also have to implement changes on their side to support the additional PRI, so making changes may take longer.
There are a lot of folks out there still using PRI, and a lot of folks getting new PRIs installed. It’s not a bad technology but it can be cumbersome. I’ve also seen quite a few organizations who maintain their old PRI even after moving to a SIP trunk because it makes a great failover connection.
So now we’ve got PRI out of the way, lets move to SIP trunking. SIP is a set of standards for establishing calls between a voice over IP (VOIP) line and another phone number such as your cell phone or that old rotary dial at your grandparents’ house. A SIP trunk is how we refer to the connection that the SIP is being delivered over.
This can be a breakout to a Session Border Controller (SBC) from your telco or can be SIP over the Internet where the provider just points at your public IP and you set up your SBC to communicate. Concurrent sessions are generally provisioned on an as-needed basis, one line at a time, so if you’ve currently got it set up for 20 concurrent calls but you know you’ve got that big all-hands meeting coming up next weekend, you can bump it up to 25, 30, heck, go crazy, 50 concurrent calls, and then drop it back to 20 when everyone’s cleared out again. The max number of concurrent calls you can possibly have will be dictated by your SBC or PBX at this point.
SIP tends to be quite a bit less expensive than PRI. It is extremely flexible in that you can add call paths as needed. It allows for more than just voice, such as video. Yet, just as I have you thinking it’s all sunshine and unicorns with SIP, there are still considerations. SIP uses internet bandwidth. If you’ve got a five megabyte down / two megabyte up internet connection, your Quality of Service is going to be very poor. As such, you’ll want to have a high bandwidth reliable pipe to the internet.
You’ll also need to be concerned about toll fraud. I’m here to tell you that it’s real and it happens. Trust me, you don’t want to get that call from your carrier on a Monday morning saying they’ve shut down your international calling on your primary trunk because of suspicious calls to the Dominican Republic. This means that you will need to implement additional data security measures that you don’t have to worry about with a physical line such as a PRI.
When clients ask us to upgrade their phone system, we always begin with your dial tone delivery.
As we said before, if you have a single PRI, you’re capped at 23 concurrent calls. If you have a problem that sometimes you can’t dial out and people have stated that sometimes they can’t call in, your limited PRI could be the culprit. Your options are to have a second PRI installed (which may give you sticker shock) or you can switch to SIP. There’s a bit more flexibility and it costs less. As long as you’re okay with an internet-based dial tone or have a redundancy plan, SIP might be a great option.
Then, your dial tone delivery mechanism influences the rest of your phone system roll out.
You’ve got some different phone system options: cloud based and on-premises. Both have similar feature sets, so let’s just discuss the SIP trunking. Cloud-based phone systems usually provide their own SIP service. You port your numbers to them and you pay a monthly fee based on usage. The associated cost varies from one vendor to the next. Benefits? Oh yeah. If your building burns down, you can set up next day from nearly anywhere with an internet connection. Yes, really. Seriously. It’s an Internet-based PBX, so you can technically receive calls while you’re at the beach, McDonald’s, or even Starbucks.
An on-premises phone system means, well, on the premises. In house. Your system will be located inside your company where you have direct control. Dial tone is delivered to you and your phone system sends calls where they need to go. Yes, they can be setup for remote connectivity, so you’ve got phone calls at the beach and the bar, but now there’s single point of failure: your office. If the power goes out, your phones are down. If a plane crashes into your building, your phones are down.
Oh, and let’s not forget direct routing with Microsoft Teams!
The long and short of it is that there’s no easy answer to what’s the best way to get calls to your phones, have phones, use phones … It’s always some variation of, “Well it, depends”.
If you want something we like to call “set it and forget it” where you don’t have to worry about power requirements and redundancy and all that other stuff, go with a cloud-hosted service and just be done with it. You’ll pay a little extra, but you’ll get some extra usually in return, in its ease of use, ease of maintenance, or just plain lack of ever having to deal with anything more than adding a user.
If you want something that is more in your power, more under your control, go with an on-premises system. You’ll have the keys to the kingdom and be able to do number manipulations and failover routing and all sorts of fun things. Bear in mind that Microsoft is pushing hard to move everyone to Office 365 and Teams and Skype for Business 2019 is the last on-premises phone system they will be making.
This document lists the most commonly encountered fax/modem call flows for which Cisco customers open Technical Assistance Center (TAC) Service Requests (SRs), along with a baseline configuration that should be present on the gateways.
With the number of fax protocols supported by Cisco devices and service providers, it is easy to get confused with all the possibilities. The important point to note is that in a fax call flow, all the devices on VoIP need to utilize the same fax protocol for a fax call to be successful. Fax protocols, unlike audio calls, cannot be transcoded.
A fax call begins as an audio call and then switches over to a fax call. Two of the most common switchover mechanisms are Named Signalling Events (NSE) (Cisco propriety) and protocol-based (Standards) switchover. Just like the fax protocols, the switchover mechanism also needs to be the same in a fax call flow.
Acronym List
In this section, you are presented with the information to configure the features described in this document.
This document describes these configurations:
There are no Fax over IP (FoIP) protocols involved.
voice service potsfax rate disable
This configuration performs both Passthrough (NSE) and T38.
The configuration for both GW and VG224 that do Modem Passthrough (NSE) is:
no ccm-manager fax protocol cisco
mgcp modem passthrough voip mode nse
mgcp modem passthrough voip codec g711ulaw
The configuration for both GW and VG224 that do T38 is:
no ccm-manager fax protocol cisco
no mgcp fax t38 inhibit
mgcp package-capability fxr-package
mgcp default-packagefxr-package
no mgcp fax t38 ecm
This configuration performs both Passthrough (NSE) and T38 (NSE). Protocol-based switchover is not supported with SCCP.
The configuration for a GW that does Modem Passthrough (NSE) is:
dial-peer voice <tag> voip
modem passthrough nse codec g711ulaw
Or, if there is no specific configuration on the dial-peer, then this information displays when you enter the voice service voip command.
modem passthrough nse codec g711ulaw
The configuration for a VG248 that does Modem Passthrough (NSE) is:
The configuration for a GW that does T38 (NSE) is:
dial-peer voice <tag> voip
fax protocol t38 nse ls-redundancy 0 hs-redundancy 0 fallback
pass-through <g711ulaw or g711alaw>
fax-relay ecm disable
fax-relay sg3-to-g3
Or, if there is no specific configuration on the dial-peer, then this information displays when you enter the voice service voip command.
fax protocol t38 nse ls-redundancy 0 hs-redundancy 0 fallback
pass-through <g711ulaw or g711alaw>
fax-relay ecm disable
fax-relay sg3-to-g3
The configuration for a VG248 that does T38 (NSE) is:
This configuration performs Passthrough (NSE).
The configuration for a GW that does Modem Passthrough (NSE) is:
no ccm-manager fax protocol cisco
mgcp modem passthrough voip mode nse
mgcp modem passthrough voip codec g711ulaw
For an ATA186 that does Modem Passthrough (NSE), refer to Configuring and Troubleshooting the Cisco ATA 186 with Fax.
This configuration performs both Passthrough and T38.
The configuration for a GW that does Modem Passthrough is:
no ccm-manager fax protocol cisco
mgcp modem passthrough voip mode nse
mgcp modem passthrough voip codec g711ulaw
The configuration for a GW that does T38 is:
no ccm-manager fax protocol cisco
no mgcp fax t38 inhibit
mgcp package-capability fxr-package
mgcp default-package fxr-package
no mgcp fax t38 ecmmgcp fax t38 nsf 000000
For ATA187, refer to Cisco ATA 187 Analog Telephone Adaptor Administration Guide for SIP, Version 1.0.
This configuration mostly uses T38, but you need to confirm this on the fax server.
The configuration for a GW that does T38 is:
dial-peer voice <tag> voip
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback
pass-through <g711ulaw or g711alaw>
fax-relay ecm disable
fax-relay sg3-to-g3
Or, if there is no specific configuration on the dial-peer, then this information should display when you enter the voice service voip command.
voice service voip
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback
pass-through <g711ulaw or g711alaw>
fax-relay ecm disable
fax-relay sg3-to-g3
VG224 needs to be an MGCP GW for this setup to work. NSE switchover is only specific to Cisco devices and providers do not support NSE based switchovers. Hence, this call flow will not work and VG224 must be converted to an MGCP GW for T38 faxing to work. After it is converted, the relevant faxing configuration will look as listed here.
The configuration for a CUBE that does T38 is:
dial-peer voice <tag> voip
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback
pass-through <g711ulaw or g711alaw>
fax-relay ecm disable
fax-relay sg3-to-g3
Or, if there is no specific configuration on the dial-peer, then this information displays when you enter the voice service voip command.
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback
pass-through <g711ulaw or g711alaw>
fax-relay sg3-to-g3
The configuration for a VG224 that does T38 is:
no ccm-manager fax protocol cisco
no mgcp fax t38 inhibit
mgcp package-capability fxr-package
mgcp default-package fxr-package
no mgcp fax t38 ecm
The ATA187 needs to run firmware version 9.2.3 to support NSE based passthrough, otherwise integration is not possible.
This document explains how to interpret Integrated Services Digital Network (ISDN) disconnect cause codes. The ISDN disconnect cause code appears in the debug isdn q931 command output, and indicates the reason for call disconnection.
Note: Activate the debug isdn q931 command for this exercise. Remember that the debug isdn q931 command generates a large volume of debugs. Refer to Important Information on Debug Commands for more information on the safe use of debugs.
Here is a sample output of the debug isdn q931 command. The output indicates the disconnect cause code for a failed ISDN call:
Calling#ping 10.10.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
20:52:14: ISDN BR0: TX -> SETUP pd = 8 callref = 0x2E
20:52:14: Bearer Capability i = 0x8890
20:52:14: Channel ID i = 0x83 20:52:14: Keypad Facility i = '5551111'
20:52:15: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0xAE
20:52:15: Channel ID i = 0x89
20:52:16: ISDN BR0: RX <- PROGRESS pd = 8 callref = 0xAE
20:52:16: Progress Ind i = 0x8A81 - Call not end-to-end ISDN,
may have in-band info
20:52:16: Signal i = 0x01 - Ring back tone on
20:52:34: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xAE
20:52:34: Cause i =0x829F08 - Normal,unspecified or Special intercept,
call blocked group restriction
20:52:34: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x2E
20:52:34: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0xAE
The 0x in the disconnect code indicates that the subsequent bytes are in hexadecimal format and are not part of the actual code. This table provides a breakdown of the code after you strip the 0x from the debug output:
| Cause i = | 0x829F08 | ||
|---|---|---|---|
| Parsed Hex Bytes | 82 | 9F | 08 |
| Description | Cause Code Origination Point | Disconnect Cause Code | Optional Diagnostic field |
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
The information in this document is based on the devices in a specific lab environment. All of the devices in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
The first byte (most significant) after 0x indicates the point in the circuit path where the disconnect cause code appears. Consider the sample output in the Introduction section. 82 indicates that the call disconnects from the local telco switch. Here is a list of cause code origination points that help you interpret where the call disconnects from:
The next byte (9F in the sample output) that follows the cause code origination point byte is the Disconnect Cause Code. This byte helps you to troubleshoot the disconnection.
Use this table to associate a Disconnect Cause Code (in Hex) and the Cause Description to determine the disconnect reason:
| Hex Code | Cause Description | Additional Information |
|---|---|---|
| 80 | Normal Disconnect | The call disconnects normally. |
| 81 | Unallocated or unassigned number | The switch receives the ISDN number in the correct format. However, the number does not belong to destination equipment. |
| 82 | No route to specified network | The ISDN exchange receives a request to route the call through an unrecognized intermediate network. This cause indicates that the equipment receives a request to route the call through a particular transit network. However, the equipment does not recognize the network. The equipment that sends this cause does not recognize the transit network due to one of these reasons: The transit network does not exist. The transit network exists, but does not serve the equipment that sends this cause. This cause is supported on a network-dependent basis. |
| 83 | No route to destination | The call routes through an intermediate network that does not serve the destination address. This cause indicates that the called user is not reachable. A user is not reachable when the network used to route the call does not serve the required destination. This cause is supported on a network-dependent basis. |
| 84 | Send special information tone | The remote number you dialed is not reachable. Check the number you dial. Verify if you need any prefixes to access the network. For example, you need to dial 9 for outbound calls through a PBX. Contact your telco/PBX administrator for details. |
| 85 | Misdialled trunk prefix. | The remote number you dialed is not reachable. Check the number you dial. Verify if you need any prefixes to access the network. For example, you need to dial 9 for outbound calls through a PBX. Contact your telco/PBX administrator for details. |
| 86 | Channel unacceptable | The service quality of the specified channel is insufficient to accept the connection. The call attempt fails because the channel is unusable. If you use a PBX, check the configuration of the PBX. For a PRI, find out how many channels your telco provides. |
| 87 | Call awarded and delivered in established channel | The user assigns an incoming call that connects to an already established call channel. This cause indicates that the user receives an incoming call, which connects to a channel already in use for similar calls (for example, packet-mode X.25 virtual calls). |
| 88 | Preemption | Your call is blocked. Calls are sometimes blocked if another call has a higher priority than your call. This situation is common with voice calls. Wait and call again later. If you use a PBX (or the remote site to which you connect uses a PBX), check the configuration of the PBX. If the condition persists, contact your telco. |
| 89 | Preemption, circuit reserved for re-use | Your call is blocked. Calls are sometimes blocked if another call has a higher priority than your call. This situation is common with voice calls. Wait and call again later. If either side uses a PBX, check the configuration of the PBX. If the condition persists, contact your telco. |
| 90 | Normal call clearing | Normal call clearing occurs. You do not need to perform any action. This cause indicates that the call disconnects because one of the users involved in the call has made a request to clear the call. Under normal situations, the network is not the source of this cause. If the call fails with this Disconnect Cause Code, the call most likely fails at a higher layer protocol such as PPP, authentication or idle timeout related issues. Verify the router configuration. Also, if you have requested a callback, the remote device disconnects the call, generates this code, and then calls you back. |
| 91 | User busy | The called system acknowledges the connection request. However, the system cannot accept the call because all B-channels are in use. The user equipment is compatible with the call in this situation. Note: If you have multiple ISDN circuits, the telco can configure them in a “hunt-group”, in which calls switch to the next available circuit. |
| 92 | No user response | The connection fails because the destination does not respond to the call. This cause indicates that a user does not respond to a call establishment message within the prescribed period. The user must respond with either an alert or connect indication according to ITU-T Q.931, when either timer T303 or T310 expires. |
| 93 | No answer from user | The destination responds to the connection request but fails to complete the connection within the prescribed time. This cause indicates that a user has provided an alert indication, but has not provided a connect indication within a prescribed period. Q.931 procedures do not necessarily generate this cause. Internal network timers sometimes generate this cause. The problem is at the remote end of the connection. |
| 94 | Subscriber absent | The remote device you attempt to reach is unavailable and is disconnected from the ISDN network. Contact the person responsible for that device. |
| 95 | Call rejected | The destination is able to accept the call but rejects the call for an unknown reason. This cause indicates that the equipment that sends this cause does not want to accept this call. Note: The equipment is able to accept the call because the equipment that sends this cause is neither busy nor incompatible. However, the equipment rejects the call. |
| 96 | Number changed | The ISDN number used to set up the call does not belong to a system. A caller receives this cause when the called party number is no longer assigned. You can optionally include the new called party number in the diagnostic field. If a network does not support this capability, the caller receives cause No. 81, unassigned (unallocated) number. |
| 97 | Redirection to new destination | Your call is routed to a different ISDN number. Check the number you call. Also verify the PBX configuration (if you use PBX). |
| 99 | Exchange routing error | Your call cannot be successfully routed to the remote party. Check the number you call. Also verify the PBX configuration (if you use PBX). |
| 9A | Non-selected user clearing | The destination is able to accept the call. However, the destination rejects the call because the call is not assigned to a user. |
| 9B | Destination out of order | The destination is not reachable because of an interface malfunction. In addition, a signaling message cannot be delivered. This condition can be temporary. However, the condition can last for an extended period in some cases. This cause indicates that a signaling message could not be delivered to the remote user. For example, a physical layer or data link layer fails at the remote user end, and the user equipment is off-line (turned off). |
| 9C | Invalid number format | The connection fails because the destination address is in an unrecognizable format, or is incomplete. Verify whether the format of the number is correct. This includes any appropriate digits for a PBX, and long distance. |
| 9D | Facility rejected | The network cannot provide the facility that the user requests. |
| 9E | Response to STATUS ENQUIRY | The status message appears in direct response to the receipt of a status inquiry message. |
| 9F | Normal, unspecified | This message reports the occurrence of a normal event when no standard cause applies. No action is required. |
| A1 | Circuit out of order | The call cannot go through due to some problem in the ISDN network. |
| A2 | No channel available | The connection fails because no appropriate channel is available to take the call. |
| A3 | Destination unattainable | The destination is not reachable through the Telco network. Contact the Telco. |
| A4 | Out of order | Some part of the network necessary to route the call is out of order. The destination is not reachable because of a network malfunction. The condition can last for an extended period. An immediate attempt to reconnect will probably fail. If you use a long distance carrier, try to use a Presubscribed Inter-exchange Carrier (PIC). For example, you can use a 10-10-xyz carrier. A PIC enables you to verify whether the problem lies with the long distance carrier. |
| A6 | Network out of order | The destination is not reachable because of a network malfunction. The condition can last for an extended period. An immediate attempt to reconnect will probably fail. If you use a long distance carrier, try to use a Presubscribed Inter-exchange Carrier (PIC). For example, you can use a 10-10-xyz carrier. A PIC enables you to verify whether the problem lies with the long distance carrier. |
| A7 | Permanent frame mode connection out of service | This message indicates that equipment failure probably terminates the permanent connection. If the problem persists, contact your telco |
| A8 | Permanent frame mode connection operational | This message occurs when the permanent connection is fully operational again after a termination. Equipment failure probably terminated the connection previously. |
| A9 | Temporary failure | An error occurs because of a network malfunction. Contact the telco if the problem persists. |
| AA | Switching equipment congestion | The destination is not reachable because of a temporary overload on the network switching equipment. Try again later. |
| AB | Access information discarded | The network cannot provide the access information that the user requests. This cause indicates that the network is unable to deliver access information to the remote user. For example, user-to-user information, low layer compatibility, high layer compatibility, or a sub-address as the diagnostic indicates. Note: You have the option to include the particular type of discarded access information in the diagnostic. |
| AC | Requested channel not available | The remote equipment cannot provide the channel that the user requests, due to an unknown reason. This problem is usually temporary. |
| AF | Resources unavailable, unspecified | The channel or service that the user requests is unavailable for an unknown reason. This problem is usually temporary. |
| B1 | Quality of service (QoS) unavailable | The network cannot provide the quality of service that the user requests. This issue can occur due to a subscription problem. This cause reports that the network cannot provide the QoS as defined in Recommendation X.213. For example, this cause code appears when the network cannot support throughput or transit delay. |
| B2 | Requested facility not subscribed | The remote equipment supports the supplementary service by subscription only. This cause indicates that the network cannot provide the supplementary service that the user requests. The user has probably not completed the necessary administrative arrangements with the supporting networks. The ISDN network can also return this cause code when a user makes a call attempt, but does not enter the SPIDs, or enters the SPIDs incorrectly. Ensure that your SPIDs are correct, or contact your telco to verify your SPIDs. Also verify the speed of the outgoing call that the ISDN network supports (56k or 64k). |
| B4 | Outgoing calls barred | There is some restriction on outgoing calls. The ISDN network does not allow you to make outgoing calls. |
| B5 | Outgoing calls barred within CUG1 | There is some restriction on outgoing calls. The ISDN network does not allow you to make outgoing calls. |
| B6 | Incoming calls barred | The ISDN network does not allow you to receive calls. Contact your telco. |
| B7 | Incoming calls barred within CUG1 | The ISDN network does not allow you to receive calls. Contact your telco. |
| B9 | Bearer capability not authorized | A subscription problem usually causes this issue. This cause indicates that the user requests a bearer capability that the equipment implements, but the user does not have the authorization to use the capability. |
| BA | Bearer capability not presently available | The network normally provides the bearer capability that the user requests. However, if the capability is unavailable currently, this cause appears. A temporary network problem or a subscription problem can cause this issue. If the incoming call is Analog (modem call), verify whether you have an ISDN incoming voice-modem under the PRI or BRI physical interface. |
| BF | Service/option not available, unspecified | The network or remote equipment cannot provide the service option that the user requests, due to an unspecified reason. A subscription problem can cause this issue. |
| C1 | Bearer capability not implemented | The network cannot provide the bearer capability that the user requests. Contact the telco to troubleshoot further. |
| C2 | Channel type not implemented | The network or the destination equipment does not support the channel type that the user requests. |
| C5 | Requested facility not implemented | The remote equipment does not support the supplementary service that the user requests. |
| C6 | Only restricted digital info bearer capability available | The network cannot provide unrestricted digital information bearer capability. This cause indicates that a device requests an unrestricted bearer service. However, the equipment only supports the restricted version of the bearer capability. |
| CF | Service/option not implemented, unspecified | The network or remote equipment cannot provide the service option that the user requests, due to an unspecified reason. A subscription problem can cause this issue. |
| D1 | Invalid call reference value | The remote equipment receives a call with a call reference that is not currently in use on the user-network interface. |
| D2 | Identified channel does not exist | The user requests the receiving equipment to use a channel that is not activate on the interface for calls. This cause indicates that the equipment receives a request to use an inactive channel on the interface for a call. For example, if a user subscribes to those channels on a primary rate interface numbered from 1 to 12 and the user equipment or the network attempts to assign a call to channels 13 through 23, this cause code appears. |
| D3 | Suspended call exists, but call id does not | The network receives a call resume request. The call resume request contains a Call Identify (ID) information element that indicates the call ID that represents a suspended call. This cause indicates that a user attempts to resume a call with a call ID which differs from the ID in use for any currently suspended call(s). |
| D4 | Call id in use | The network receives a call resume request. The call resume request contains a Call ID information element that indicates the resume request is for a suspended call. This cause indicates that the network receives a call suspend request. The call suspend request contains a call ID (including the null call ID). This ID is already in use for a suspended call within the domain of interfaces over which the call can be resumed. |
| D5 | No call suspended | The network receives a call resume request when there is no suspended call pending. You can resolve this transient error through successive call retries. This cause code indicates that the network receives a call resume request. The call resume request contains a call ID information element that currently does not indicate any suspended call within the domain interfaces over which calls can be resumed. |
| D6 | Call with requested call id has been cleared | This cause indicates that the network receives a call resume request. The call resume request contains a call ID information element that originally indicated a suspended call. However, either a network timeout or a remote user clears the suspended call. |
| D7 | User not member of CUG1 | Your call does not go through, probably due to one of these reasons: You dial an incorrect ISDN number. You request a service that you are not authorized to use (you have not subscribed to this service). The remote device is not authorized to use a service that you use. Check the number you call. If the problem persists, contact your telco. |
| D8 | Incompatible destination | This cause indicates an attempt to connect to non-ISDN equipment. For example, an analog line. This cause indicates that the equipment receives a request to establish a call that has a low layer compatibility, high layer compatibility, or other compatibility attributes (for example, data rate) that the equipment cannot accommodate. This code often appears when the calling device dials the wrong number, and reaches a non-ISDN device. Therefore, ensure that you dial the correct number. This cause can also occur when a a data call is made to a voice number, or a voice call is made to a number that only supports data. If the number is correct, check whether the telco has configured their switch incorrectly. |
| DA | Non-existent CUG1 | Your call does not go through, probably due to one of these reasons: You dial an incorrect ISDN number. You request a service that you are not authorized to use (you have not subscribed to this service). The remote device is not authorized to use a service that you use. Check the number you dial. If the problem persists, contact your telco. |
| DB | Invalid transit network selection | The device requests the ISDN exchange to route the call through an unrecognized intermediate network. This cause indicates that the ISDN exchange receives a transit network identification of an incorrect format. Annex C of ITU-T Q.931 provides this definition. |
| DF | Invalid message, unspecified | An invalid message appears with no standard cause. This problem usually occurs due to a D-channel error. If the error occurs systematically, report the error to your ISDN service provider. |
| E0 | Mandatory IE missing | The receiving equipment receives a message that does not include one of the mandatory information elements. This cause indicates that the equipment receives a message that does not contain an information element that is necessary for the equipment to process the message. This problem occurs due to a D-channel error. Ensure that you configure the switch type correctly. Upgrade your Cisco IOS® Software on the router to solve this issue. If the error occurs systematically, report the error to your ISDN service provider. |
| E1 | Message type not implemented | The receiving equipment receives an unrecognized message, because either the message type is invalid, or the equipment does not support the message type. A problem with the remote configuration or with the local D-channel causes this issue. |
| E2 | Message not compatible with call state or not implemented | The remote equipment receives an invalid message with no standard cause. This cause indicates that the equipment receives a message that is not permissible in the call state according to the procedures. This cause can also indicate that the equipment receives a STATUS message to indicate an incompatible call state. The issue occurs due to a D-channel error. If the error recurs, report the error to your ISDN service provider. |
| E3 | IE not implemented | The remote equipment receives a message that includes information elements that the equipment cannot recognize. This cause indicates that the equipment receives a message that includes information elements that the device cannot recognize. This problem can occur when the equipment does not define or implement the information element identifier. However, the message does not need to contain the information element in order for the equipment to process the message. This issue occurs due to a D-channel error. If the error recurs, report the error to your ISDN service provider. |
| E4 | The remote equipment receives a message that includes invalid information in the information element. This cause indicates that the equipment receives an information element that is implemented, but one or more of the fields in the information element are coded differently. This issue occurs due to a D-channel error. | |
| E5 | Message not compatible with call state | The remote equipment receives an expected message that does not correspond to the current state of the connection. This issue occurs due to a D-channel error. |
| E6 | Recovery on time expiry | Your call does not go through, probably because an error occurs. For example, a state synchronization error. Wait and try again later. If the problem persists, contact your ISDN service provider. |
| E7 | Parameter not implemented | Your call does not go through because the ISDN network does not support a service you need to use. Contact your ISDN service provider. |
| EF | Protocol error, unspecified | This cause indicates an unspecified D-channel error with no other standard cause. |
| FF | Interworking, unspecified | This cause indicates that an event occurs, but the network does not provide causes for the action. The precise problem is unknown. |
| ?? | Unknown Cause value | The cause value is unknown. |
1 CUG: Closed User Group is a facility in X.25 and ISDN networks that allows a called number to be available only to a limited number of other users (in a virtual private network). Contact your telco for more information.
The last two hexadecimal digits (08 in the example) are optional. You do not commonly use these digits for diagnostic purposes. However, you can sometimes use this byte to furnish additional information for the Disconnect Cause Code. The debug isdn q931 output can sometimes contain these digits.
There are many things in this world that are hidden just beneath the surface that make our lives easier. Whether it be the Secret Menu at In-n-Out Burger or the good old Konami Code, the good stuff that we need is often just out of reach unless you know the code. This is also the case when dealing with Cisco phones. There are three key combinations that will help you immensely when configuring these devices, provided you know what they are.
1. Unlock Settings – *, *, #. When you check the settings on a Cisco phone, you’ll notice that you can look at the values but you can’t change any of them. Many of these values are set at the Cisco Unified Communications Manager (CUCM) level. However, once common issue is the phone not being able to contact the CUCM server or the phone having the wrong address/TFTP server information from DHCP. While there are a multitude of ways to correct these issues in the network, there is a quick method to unlock the phone to change the settings.
It’s that easy. There won’t be a whole lot to do with the phone Telephony User Interface (TUI), but you can make quick changes to DHCP, IP address, or TFTP server address entries to verify the phone configuration is correct. By the way, when putting in an IP address via TUI, the “*” key can be used to put a period in an IP address. That should save you an extra keystroke or two.
2. Hard Reset – *,*,#,*,*. Sometimes, you just need to reboot. There are a variety of things that can cause a phone to need to be reset. Firmware updates, line changes, or even ring cadence necessitate reboots. While you can trigger these from the CUCM GUI, there are also times that they may need to be done from the phone itself in the event of a communications issue. Rebooting is also a handy method for beginning to troubleshoot issues.
But Tom? Why not just pull the network cable from the back of the phone? Won’t disconnecting the power reboot?
True, it will. What if the phone is mounted to the wall? Or if the phone is running from an external power supply? Or positioned in such as way that only the keypad is visible? Better to know a different way to reboot just in case. Here’s where the reboot cheat code comes in handy.
This sequence will cause the phone to reboot as if the power cable had been unplugged and force it to pull a new configuration from CUCM. Once common issue I find when entering this code is the keypresses not registering with the phone. Try it a couple of times until you develop a rhythm for entering it about 1/2 second apart. Much more than that and the phone won’t think you’re entering the code. Quicker than that and the keys might not all register.
3. Factory Reset – “1,2,3,4,5,6,7,8,9,*,0,#”. When all else fails, nuke the phone from orbit. It’s the only way to be sure. Some settings are so difficult to change that it’s not worth it. Or you’ve got a buggy firmware that needs to be erased. In those cases, there is a way to completely reset a phone back to the shipping configuration. You’ll need access to unplug the power cable, as well as enough dexterity to press buttons on the front as you plug it back in.
4. Death trap – “ 3491672850*# ”
Don’t worry if you press a key twice on accident. The phone will still accept the code. However, you do need to be quick about things. The phone will only accept the factory reset code for 60 seconds after the Headset, Mute, and Speaker buttons start flashing in sequence.
Many of the terms listed below are directly visible in the show controllers t1 or show controllers e1 command output. For more information, refer to the document Understanding the show controllers e1 Command.
Bipolar Violation (BPV) Error Event
A BPV error event for an alternate mark inversion (AMI)-coded signal is the occurrence of a pulse of the same polarity as the previous pulse. A BPV error event for a B8ZS- or HDB3- coded signal is the occurrence of a pulse of the same polarity as the previous pulse without being a part of the zero substitution code.
Controlled Slip (CS) Error Event
A Controlled Slip is the replication or deletion of the payload bits of a digital signal level 1 (DS1) frame. A Controlled Slip may be performed when there is a difference between the timing of a synchronous receiving terminal and the received signal. A Controlled Slip does not cause an Out of Frame defect.
Excessive Zeroes (EXZ) Error Event
An EXZ error event for an AMI-coded signal is the occurrence of more than fifteen contiguous zeroes. For a binary 8-zero substitution (B8ZS) coded signal, the defect occurs when more than seven contiguous zeroes are detected.
Line Coding Violation (LCV) Error Event
An LCV is the occurrence of either a Bipolar Violation or Excessive Zeroes error event.
Path Coding Violation (PCV) Error Event
A PCV error event is a frame synchronization bit error in the D4 and E1-no cyclic redundancy check (CRC) formats, or a CRC error in the Extended Super Frame (ESF) and E1-CRC formats.
Alarm Indication Signal (AIS) Defect
For D4 and ESF links, the ‘all ones’ condition is detected at a DS1 line interface upon observing an unframed signal with a one’s density of at least 99.9 percent present for a time equal to or greater than T, where 3 ms is less than or equal to T, which is less than or equal to 75 ms. The AIS is terminated upon observing a signal not meeting the one’s density or the unframed signal criteria for a period equal to or greater than than T.
For E1 links, the ‘all-ones’ condition is detected at the line interface as a string of 512 bits containing fewer than three zero bits.
Out Of Frame (OOF) Defect
An OOF defect is the occurrence of a particular density of Framing Error events.
For T1 links, an OOF defect is declared when the receiver detects two or more framing errors within a 3 msec period for ESF signals and 0.75 msec for D4 signals, or two or more errors out of five, or fewer consecutive framing-bits.
For E1 links, an OOF defect is declared when three consecutive frame alignment signals have been received with an error.
When an OOF defect is declared, the framer starts searching for a correct framing pattern. The OOF defect ends when the signal is in-frame.
In-frame occurs when there are fewer than two frame bit errors within a 3 msec period for ESF signals and 0.75 msec for D4 signals.
For E1 links, in-frame occurs when:
All performance parameters are accumulated in fifteen minute intervals and up to 96 intervals (covering a 24 hour period ) are kept by an agent. Fewer than 96 intervals of data will be available if the agent has been restarted within the last 24 hours. In addition, there is a rolling 24-hour total of each performance parameter.
There is no requirement for an agent to ensure a fixed relationship between the start of a fifteen minute interval and clock time; however some agents may align the fifteen minute intervals with quarter hours.
Bursty Errored Seconds (BES)
A Bursty Errored Second (also known as Errored Second type B) is a second with fewer than 320 and more than one Path Coding Violation error events, no Severely Errored Frame defects and no detected incoming AIS defects. Controlled slips are not included in this parameter.
This is not incremented during an Unavailable Second.
Controlled Slip Seconds (CSS)
A Controlled Slip Second is a one-second interval containing one or more controlled slips.
Degraded Minutes
A Degraded Minute is one in which the estimated error rate exceeds 1E-6 but does not exceed 1E-3.
Degraded Minutes are determined by collecting all of the Available Seconds, removing any Severely Errored Seconds grouping the result in 60-second long groups and counting a 60-second long group (minute) as degraded if the cumulative errors during the seconds present in the group exceed 1E-6. Available seconds are merely those seconds which are not unavailable as described below.
Errored Seconds (ES)
For ESF and E1-CRC links an Errored Second is a second with one of the following:
For D4 and E1-noCRC links, the presence of Bipolar Violations also triggers an Errored Second. This is not incremented during an Unavailable Second.
Line Errored Seconds (LES)
A Line Errored Second, according to T1M1.3, is a second in which one or more Line Code Violation error events were detected.
While many implementations are currently unable to detect the zero strings, it is expected that interface manufacturers will add this capability in deference to ANSI; therefore, it will become available in time.
In the T1M1.3 specification, near end Line Code Violations and far end Line Errored Seconds are counted. For consistency, we count Line Errored Seconds at both ends.
Severely Errored Framing Second (SEFS)
An Severely Errored Framing Second is a second with either one or more OOF defects or a detected AIS defect.
Severely Errored Seconds (SES)
A Severely Errored Second for ESF signals is a second with one of the following:
For E1-CRC signals, a Severely Errored Second is a second with either 832 or more Path Code Violation error events or one or more OOF defects.
For E1-noCRC signals, a Severely Errored Second is a 2048 LCVs or more.
For D4 signals, a Severely Errored Second is a count of one-second intervals with Framing Error events, or an OOF defect, or 1544 LCVs or more.
Controlled slips are not included in this parameter.
This is not incremented during an Unavailable Second.
Unavailable Seconds (UAS)
Unavailable Seconds are calculated by counting the number of seconds that the interface is unavailable. The DS1 interface is said to be unavailable from the onset of ten contiguous SESs, or the onset of the condition leading to a failure (see Failure States). If the condition leading to the failure was immediately preceded by one or more contiguous SESs, then the DS1 interface unavailability starts from the onset of these SESs. Once unavailable, and if no failure is present, the DS1 interface becomes available at the onset of ten contiguous seconds with no SESs. Once unavailable, and if a failure is present, the DS1 interface becomes available at the onset of 10 contiguous seconds with no SESs, if the failure clearing time is less than or equal to ten seconds. If the failure clearing time is more than ten seconds, the DS1 interface becomes available at the onset of ten contiguous seconds with no SESs, or the onset period leading to the successful clearing condition, whichever occurs later. With respect to the DS1 error counts, all counters are incremented while the DS1 interface is deemed available. While the interface is deemed unavailable, the only count that is incremented is UASs.
A special case exists when the ten or more second period crosses the 900 second statistics window boundary, as the foregoing description implies that the Severely Errored Second and Unavailable Second counters must be adjusted when the Unavailable Signal State is entered. Successive “gets” of the affected dsx1IntervalSESs and dsx1IntervalUASs objects will return differing values if the first get occurs during the first few seconds of the window. This is viewed as an unavoidable side-effect of selecting the presently-defined managed objects.
The following failure states are received or detected failures that are reported. The conditions under which a DS1 interface would, if ever, produce the conditions leading to the failure state are described in the appropriate specification.
Alarm Indication Signal (AIS) Failure
The Alarm Indication Signal failure is declared when an AIS defect is detected at the input and the AIS defect still exists after the Loss Of Frame failure (which is caused by the unframed nature of the ‘all-ones’ signal) is declared. The AIS failure is cleared when the Loss Of Frame failure is cleared.
Far End Alarm Failure(Yellow Alarm)
The Far End Alarm failure is also known as a Yellow Alarm in the T1 case and a Distant Alarm in the E1 case.
For D4 links, the Far End Alarm failure is declared when bit 6 of all channels has been zero for at least 335 ms and is cleared when bit 6 of at least one channel is non-zero for a period T, where T is usually less than one second and always less than five seconds. The Far End Alarm failure is not declared for D4 links when a Loss of Signal is detected.
For ESF links, the Far End Alarm failure is declared if the Yellow Alarm signal pattern occurs in at least seven out of ten contiguous 16-bit pattern intervals and is cleared if the Yellow Alarm signal pattern does not occur in ten contiguous 16-bit signal pattern intervals.
For E1 links, the Far End Alarm failure is declared when bit 3 of time-slot zero is received set to one on two consecutive occasions. The Far End Alarm failure is cleared when bit 3 of time-slot zero is received set to zero.
Far End Loss Of Multiframe Failure
The Far End Loss Of Multiframe failure is declared when bit 2 of TS16 of frame 0 is received set to one on two consecutive occasions. The Far End Loss Of Multiframe failure is cleared when bit 2 of TS16 of frame 0 is received set to zero. The Far End Loss Of Multiframe failure can only be declared for E1 links operating in Channel Associated Signalling mode.
Loopback Pseudo-Failure
The Loopback Pseudo-Failure is declared when the near end equipment has placed a loopback (of any kind) on the DS1. This allows a management entity to determine from one object whether the DS1 can be considered to be in service or not (from the point of view of the near end equipment).
Loss Of Frame(LOF) Failure
For T1 links, the Loss Of Frame failure is declared when an OOF or LOS defect has persisted for T seconds, where T is more than or equal to two, but less than or equal to ten. The Loss Of Frame failure is cleared when there have been no OOF or LOS defects during a period T is more than or equal to zero, but less than or equal to twenty. Many systems will perform “hit integration” within the period T before declaring or clearing the failure.
For E1 links, the Loss Of Frame Failure is declared when an OOF defect is detected.
Loss Of MultiFrame Failure
The Loss Of MultiFrame failure is declared when two consecutive multiframe alignment signals (bits 4 through 7 of TS16 of frame 0) have been received with an error. The Loss Of Multiframe failure is cleared when the first correct multiframe alignment signal is received. The Loss Of Multiframe failure can only be declared for E1 links operating with framing (sometimes called Channel Associated Signalling mode).
Loss Of Signal (LOS) Failure
For T1, the Loss Of Signal failure is declared upon observing 175 +/- 75 contiguous pulse positions with no pulses of either positive or negative polarity. The LOS failure is cleared upon observing an average pulse density of at least 12.5 percent over a period of 175 +/- 75 contiguous pulse positions starting with the receipt of a pulse.
For E1 links, the Loss Of Signal failure is declared when greater than ten consecutive zeroes are detected.
TS16 Alarm Indication Signal Failure
For E1 links, the TS16 Alarm Indication Signal failure is declared when time-slot 16 is received as all ones for all frames of two consecutive multiframes. This condition is never declared for T1.
How to determine the connection of application
Start “Task Manager”—click “Processes”—select “PID” box in “view-select Colunms”
Find out the PID of the application
Input the command “ netstat –ano | findstr “PID”
—————— pac file ——–
function FindProxyForURL(url, host)
{
url = url.toLowerCase();
host = host.toLowerCase();
//——————————————————-
// Traffic should go via proxy
//——————————————————-
if (
shExpMatch(host, “163.44.159.68”) || //Entry for this VPS
shExpMatch(host, “*.kkmg.vip”) || //Entry for this VPS
)
return “PROXY 127.0.0.1:1080”;
// Default Traffic Forwarding
return ” DIRECT “;
}
Extension Mobility Application Error Codes
| Table 1 Extension Mobility Application Error Codes | |||
| Error Code | Phone Display | Quick Description | Reason |
| 201 | Please try to login again (201) | Authentication Error | If the user is an EMCC user, this error can occur if “EMCC” is not activated on the Intercluster Service Profile window. |
| 202 | Please try to login again (202) | Blank userid or pin | The user enters a blank user ID or PIN. |
| 204 | Login is unavailable (204) | Directory server error | The EMApp sends this error to the phone when IMS could not authenticate the user with the given PIN. |
| 205 | Login is unavailable (205)
Logout is unavailable (205) |
User Profile Absent | Occurs when the user profile information cannot be retrieved from the cache or the database. |
| 207 | Login is unavailable(207)
Logout is unavailable(207) |
Device Name Empty | Occurs when the device or name tag is missing in the request URI. This cannot happen with real devices and can occur only if the request is sent from third-party applications. |
| 208 | Login is unavailable(208)
Logout is unavailable(208) |
EMService Connection Error | The visiting EMApp cannot connect to any Visiting EMService. (The service is down or not activated.)
The visiting EMService cannot connect to the Home EMService (the WAN is down or certificates are not trusted.) |
| 210 | Login is unavailable(210)
Logout is unavailable(210) |
Init Fail-Contact Admin | An error (such as a database connection failure) occurred while initializing EMApp. The error can occur because of a failure to connect to the database during startup. |
| 211 | Login is unavailable(211)
Logout is unavailable(211) |
EMCC Not Activated | Occurs when the PSTN is not activated in the Intercluster Service Profile window of the visiting cluster. |
| 212 | Login is unavailable(212) | Cluster ID is invalid | Occurs when a remote cluster update fails by sending an incorrect cluster ID to the remote cluster. |
| 213 | Login is unavailable(213)
Logout is unavailable(213) |
Device does not support EMCC | Occurs when a device does not support EMCC. |
Extension Mobility Service Error Codes
| Table 2 Extension Mobility Service Error Codes | |||
| Error Code | Phone Display | Quick Description | Reason |
| 0 | Login is unavailable(0)
Logout is unavailable(0) |
Unknown Error | The EMService failed for an unknown reason. |
| 1 | Login is unavailable(1)
Logout is unavailable(1) |
Error on parsing | When the EMService cannot parse the XML request from the EMApp or EMService. This error occurs when third-party applications send an incorrect query to login XML (EM API). The error can also occur because of a version mismatch between home and visiting clusters. |
| 2 | Login is unavailable(2) | EMCC Authentication Error | The EMCC user credentials cannot be authenticated because the user entered an incorrect PIN. |
| 3 | Login is unavailable(3)
Logout is unavailable(3) |
Invalid App User | Invalid application user. This error commonly occurs because of the EM API. |
| 4 | Login is unavailable(4)
Logout is unavailable(4) |
Policy Validation error | The EM Service sends this error when it cannot validate the login or logout request because of an unknown reason, an error while querying the database or an error while retrieving information from the cache. |
| 5 | Login is unavailable(5)
Logout is unavailable(5) |
Dev. logon disabled | A user logs into a device that has Enable Extension Mobility unchecked in the Phone Configuration window. |
| 6 | Login is unavailable(6)
Logout is unavailable(6) |
Database Error | Whenever the database returns an exception while executing the query or stored procedure that the EM Service requests (login/logout or device/user query), the EM Service sends this error code to EMApp. |
| 8 | Login is unavailable(8)
Logout is unavailable(8) |
Query type undetermined | No valid query was sent to the EMService (DeviceUserQuery and UserDeviceQuery are valid ones). This error occurs because of the EM API or incorrect XML input. |
| 9 | Login is unavailable(9)
Logout is unavailable(9) |
Dir. User Info Error | This error appears in two cases:
|
| 10 | Login is unavailable(10)
Logout is unavailable(10) |
User lacks app proxy rights | The user tries to log in on behalf of another user. By default, a CCMSysUser has administrative rights. |
| 11 | Login is unavailable(11)
Logout is unavailable(11) |
Device Does not exist | The phone record entry is absent in the device table. |
| 12 | Phone record entry is absent in the device table | Dev. Profile not found | No device profile is associated with the remote user. |
| 18 | Login is unavailable(18) | Another user logged in | Another user is already logged in on the phone. |
| 19 | Logout is unavailable(19) | No user logged in | The system attempted to log out a user who has not logged in. This error occurs when sending logout requests from third-party applications (EM API). |
| 20 | Login is unavailable(20)
Logout is unavailable(20) |
Hoteling flag error | Enable Extension Mobility is unchecked in the Phone Configuration window. |
| 21 | Login is unavailable(21)
Logout is unavailable(21) |
Hoteling Status error | The current user status was not retrieved from either the local cache or database. |
| 22 | Login is unavailable(22) | Dev. logon disabled | Occurs when EM is not enabled on device and the request is sent via EM API or when the services button is pressed on phone. |
| 23 | Login is Unavailable (23)
Logout is Unavailable (23) |
User does not exist | Occurs when the given user ID is not found (in any of the remote clusters). |
| 25 | Login is unavailable(25) | User logged in elsewhere | The user is currently logged in to some other phone. |
| 26 | Login is unavailable(26)
Logout is unavailable(26) |
Busy, please try again | Occurs when the EMService has currently reached the threshold level of Maximum Concurrent Requests service parameter. |
| 28 | Login is unavailable(28)
Logout is unavailable(28) |
Untrusted IP Error | Occurs when the Validate IP Address service parameter is set to True and the user tries to log in or log out from a machine whose IP address is not trusted. For example, a third-party application or EM API from a machine is not listed in the Trusted List of Ips service parameter. |
| 29 | Login is unavailable(29)
Logout is unavailable(29) |
ris down-contact admin | The Real-Time Information Server Data Collector (RISDC) cache is not created or initialized, and the EMService is unable to connect to RISDC. |
| 30 | Login is unavailable(30)
Logout is unavailable(30) |
Proxy not allowed | When login and logout occur through proxy (“Via” is set in HTTP header) and the Allow Proxy service parameter is set to False. |
| 31 | Login is unavailable(31)
Logout is unavailable(31) |
EMCC Not Activated for the user | Occurs when the Enable Extension Mobility Cross Cluster check box is not checked in the End User Configuration window of the home cluster. |
| 32 | Login is unavailable(32)
Logout is unavailable(32) |
Device does not support EMCC | Occurs when a device model does not have EMCC capability. |
| 33 | Login is unavailable(33)
Logout is unavailable(33) |
No free EMCC dummy device | Occurs when all the EMCC dummy devices are in use by other EMCC logins. |
| 35 | Login is unavailable(35)
Logout is unavailable(35) |
Visiting Cluster Information is not present in Home Cluster | Occurs when the home cluster does not have an entry for this visiting cluster. |
| 36 | Login is unavailable(36)
Logout is unavailable(36) |
No Remote Cluster | Occurs when the administrator has not added a remote cluster. |
| 37 | Login is Unavailable (37)
Logout is Unavailable (37) |
Duplicate Device Name | Occurs when the same device name exists in both the home cluster and visiting cluster. |
| 38 | Login is unavailable(38)
Logout is unavailable(38) |
EMCC Not Allowed | Occurs when the home cluster does not want to allow EMCC login (The Enable Extension Mobility Cross Cluster check box is not checked in the home cluster). |
| 43 | Login is unavailable(43) | Device Security mode error | The Device Security Profile that is associated to the EMCC device should be set to Nonsecure for its Device Security Mode. |
| 45 | Login is unsuccessful(45) | Remote Cluster version not supported | Occurs during EMCC login when the visiting cluster version is 9.x and is in mixed mode, the phone is in secure mode, and the home cluster version is 8.x. |
| 46 | Login is unsuccessful(46) | Remote Cluster security mode not supported | Occurs during EMCC login when the visiting cluster security mode is in mixed mode, the phone is in secure mode, and the home cluster is in nonsecure mode. |
| Character | Description | Examples |
| @ | (@) 通配符匹配 所有 National Numbering Plan numbers.
每个 route pattern 只允许存在1个@ 通配符. |
Route pattern ‘9.@’ 可以 routes 或者 blocks 所有 National Numbering Plan 可以识别的号码.
下列的 route patterns examples 显示了通配符 @ 包含的 National Numbering Plan numbers:
|
| X | (X)通配符表示匹配范围从0到9的任何单个数字 | Route pattern ‘9XXX’ 可以 routes 或 blocks 范围从9000 到 9999的所有号码. |
| ! | (!) 通配符表示匹配 范围从0到9的单个或任意多个数字. | Route pattern ‘91!’ 可以routes 或 blocks 范围从 910 到 91999999999999999999999的所有号码. |
| ? | (?) 通配符表示匹配值的零个或多个的出现. | Route pattern ‘91X?’ 可以 routes或blocks 范围从91 到 91999999999999999999999 的所有号码. |
| + | (+)通配符表示匹配值的一个或多个的出现. | Route pattern ‘91X+’ 可以 routes 或 blocks 范围从 910 到 91999999999999999999999的所有号码. |
| [ ] | ([ ]) 通配符表示匹配这几个数字内的一个. | Route pattern ‘813510[012345]’ 可以 routes 或 blocks 范围从8135100 到 8135105的所有号码. |
| – | (-) 通配符与 方括号 一起使用,表示一个值的范围. | Route pattern ‘813510[0-5]’ 可以 routes 或 blocks 范围从8135100 到 8135105 的所有号码. |
| ^ | (^) 通配符与 方括号 一起使用, 表示否定这一系列的值.
务必确保该通配符为方括号后的第一个字符 ([). 另外每个 route pattern 只允许有一个(^)通配符. |
Route pattern ‘813510[^0-5]’ 可以 routes 或 blocks 范围从8135106 至8135109的所有号码. |
| . | (.) 通配符,用作分隔符,多 用于在Cisco Unified Communications Manager(CUCM)从号码(directory number)区分出access code.
使用这个特殊通配符, 配合丢弃数字操作(discard digits),可以在 Cisco Unified Communications Manager(CUCM) 将号码发出前将 access code 剥离. 每个 route pattern 只允许有一个 (.) 通配符. |
Route pattern ‘9.@’ 可以识别出 9 是一个 Cisco Unified Communications Manager 在National Numbering Plan 的一个 access code. |
| * | (*) 通配符可以为特殊拨号号码提供额外的数字. | 可以配置route pattern ‘*411’ 可以拨打到任何号码的内部拨号. |
| # | (#) 通常表示拨号操作的结束.
确保# 通配符是位于这个pattern最后一个. |
Route pattern ‘901181910555#’ 可以routes 或 blocks 从National Numbering Plan 的一个国际呼叫. 这里的 (#)通配符表示之前的(5)是呼叫队列中的最后一个数字. |
| \+ | 反斜杠后的一个加号,就是(\+)通配符，表示你想要配置国际转义符+.
使用 (\+) 表示这里的 (+) 是国际转移符号用 可以拨打的,不是作为(+)通配符使用. |
具体案例, 参考 Use the International Escape Character. |
