孔乙己是站着喝酒而穿长衫的唯一的人。他身材很高大；青白脸色，皱纹间时常夹些伤痕；一部乱蓬蓬的花白的胡子。穿的虽然是长衫，可是又脏又破，似乎十多年没有补，也没有洗。他对人说话，总是满口之乎者也，叫人半懂不懂的。

因为他姓孔，别人便从描红纸上的“pan.baidu.com/s/1vGGSunfS-IMHd6RQGCuePw”这半懂不懂的话里，替他取下一个绰号，叫作wsyv。

孔乙己一到店，所有吃瓜的人便都看着他笑，有的叫道，“生肉，有能看得懂的嘛？”他不回答，对柜里说，“自带BBC英文声轨，自己当做听力练习”便排出五毛大洋。他们又故意的高声嚷道，“你一定又偷了人家的东西了！”孔乙己睁大眼睛说，“你怎么这样凭空污人清白……”“什么清白？萌新都不知道怎么用这代码！”孔乙己便涨红了脸，额上的青筋条条绽出，争辩道，“不会自己百度？……谷歌！……源文件名都没改，能算偷么？”接连便是难懂的话，什么“萌新固傻”，什么“者乎”之类，引得众人都哄笑起来：店内外充满了快活的空气。

Introduction

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

• ATA186 – Analog Telephone Adaptor 186
• ATA187 – Analog Telephone Adaptor 187
• CUBE – Cisco Unified Border Element
• CUCM – Cisco Unified Communications Manager
• FXS – Foreign Exchange Station
• GW – Gateway
• ITSP – Internet Telephony Service Provider
• MGCP – Media Gateway Control Protocol
• PRI – Primary Rate Interface
• SCCP – Skinny Client Control Protocol
• SIP – Session Initiation Protocol
• SIP/H323 – Session Initiation Protocol/Voice Class H323
• VG224 – Voice Gateway 224
• VG248 – Voice Gateway 248

Configure

In this section, you are presented with the information to configure the features described in this document.

Configurations

This document describes these configurations:

• Telco – PRI – GW – FXS – Fax/Modem
• Telco – PRI – GW – MGCP – CUCM – MGCP – VG224 – Fax/Modem
• Telco – FXO – GW – H323/SIP – CUCM – SCCP – VG248 – Fax/Modem
• Telco – PRI – GW – MGCP – CUCM – SCCP – ATA186 – Fax/Modem
• Telco – PRI – GW – MGCP – CUCM – SIP – ATA187 – Fax/Modem
• Telco – PRI – GW – SIP/H323 – CUCM – SIP – Fax Server
• ITSP – SIP – CUBE – SIP/H323 – CUCM – SCCP – VG224
• ATA186 – SCCP – CUCM – SIP – ATA187

Telco – PRI – GW – FXS – Fax/Modem

There are no Fax over IP (FoIP) protocols involved.

voice service potsfax rate disable

Telco – PRI – GW – MGCP – CUCM – MGCP – VG224 – Fax/Modem

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

Telco – FXO – GW – H323/SIP – CUCM – SCCP – VG248 – Fax/Modem

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:

1. Configure > Telephony > Port specific parameters > Choose the port to which the fax machine is connected. Set Fax Relay to disabled.
2. Configure > Telephony > Advanced Settings > Set Passthrough signaling to IOS Mode.

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:

1. Configure > Telephony > Port specific parameters > Choose the port to which the fax machine is connected.
   1. Set Fax Relay to T.38 peer to peer.
   2. Set Fax relay ECM to disabled.
   3. Set Fax relay NSF to override with 000000.
2. Configure > Telephony > Advanced Settings > Set Passthrough signaling to IOS Mode.

Telco – PRI – GW – MGCP – CUCM – SCCP – ATA186 – Fax/Modem

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.

Telco – PRI – GW – MGCP – CUCM – SIP – ATA187 – Fax/Modem

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.

Telco – PRI – GW – SIP/H323 – CUCM – SIP – Fax Server

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

ITSP – SIP – CUBE – SIP/H323 – CUCM – SCCP – VG224

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

ATA186 – SCCP – CUCM – SIP – ATA187

The ATA187 needs to run firmware version 9.2.3 to support NSE based passthrough, otherwise integration is not possible.

Introduction

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:

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

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.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Cause Code Origination Point

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:

• 80—the router
• 81—the private network near the local user (possibly a local private branch exchange [PBX])
• 82—the public network near the local user (local telco switch)
• 83—the transit network (in the ISDN cloud)
• 84—the public network near the remote user (remote telco switch)
• 85—the private the network near the remote user (possibly a remote PBX)
• 87—the international network
• 8A—a network beyond the internetworking point

Disconnect Cause Code

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:

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

Optional Diagnostic field

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.

• Go to the Settings page of the phone
• While in the settings page, press *, *, # (star, star, pound) about 1/2 second apart
• The phone will display “Settings Unlocked” and allow you to make changes

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.

• Go to the settings page of the phone
• Press *,*,#,*,* (star, star, pound, star, star) about 1/2 second apart
• The phone will display “Resetting” and perform a hard reset

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.

• Unplug the power from the phone.
• As you plug it back it, press and hold the “#” key.  If performed correctly, the Headset, Mute, and Speaker buttons in the lower right corner will start to flash in sequence.
• When those three buttons start flashing in sequence, enter the following code: 1,2,3,4,5,6,7,8,9,*,0,#.  You’ll notice that’s every button on the keypad in sequence from left to right, top to bottom.
• Phone will display “Upgrading” and erase the configuration.

4. Death trap – “ 3491672850*# ”

• Unknown

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.

Error Events

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.

Performance Defects

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:

• in frame N, the frame alignment signal is correct and
• in frame N+1, the frame alignment signal is absent (that is, bit 2 in TS0 is set to one) and
• in frame N+2, the frame alignment signal is present and correct.

Performance Parameters

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:

• one or more Path Code Violations
• one or more Out of Frame defects
• one or more Controlled Slip events
• a detected AIS defect

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:

• 320 or more Path Code Violation Error Events
• one or more OOF defects
• a detected AIS defect

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.

Failure States

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

Extension Mobility Service Error Codes

Read More…

Read More…

• 产品代码：EVE
• 产品类别：大型3D在线聊天类
• 发售起始日期：2008-06-22 12:26
• 发售截止日期：20XX-XX-XX XX:XX
• 产品到期日：2018-02-28
• 预期收益率：?%
• 投资类型：呵呵
• 风险评级：RX(？？型)
• 销售渠道：网上
• 币种：ISK

08年的号到现在，看图说话系列，有意向直接留言

资产(这物价GG)

[显示幻灯片]