The format for system messages is as follows, starting with the percent sign (%). The System Message’s italicised and bolded sections are optional, while the italicised sections are required.
the%FACILITY-SUBFACILITY-SEVERITY-message-text MNEMONIC’s
The FACILITY code, which may be any length and consists of two or more capital letters, designates the facility to which the message is referring. A facility might be a piece of operating system-related hardware, a protocol, or a software module.
Table 1 displays the facility codes for the system.
When switches from the Cisco Catalyst 6500 series are used in a dispersed network environment, they include a capability called SUBFACILITY that is unique to those switches. A single code or two codes separated by a hyphen may be used to identify the subfacility, which identifies the distributed system component from which the message is being received. For instance, the system message %DIAG-SP-STDBY-6-RUN MINIMUM is identical to the message %DIAG-6-RUN MINIMUM delivered by the switch processor (SP) that is in redundancy or standby mode (STDBY).
The SEVERITY scale spans from 0 to 7, and a single-digit code representing the illness’s severity that ranges from 0 to 7 is used. The situation is more serious the smaller the number. Table 2 displays the severity levels.
MNEMONIC is a code that fully distinguishes the system message from other messages.
The Message-text is the text string that explains the circumstance. Additional details regarding the event may be included in this section of the message, such as terminal port numbers, network addresses, or addresses that point to specific locations in the system memory’s address space. Because the data in these variable fields varies for each message, it is shown below as a sequence of brief strings enclosed in square brackets ([ ]). For instance, decimal numbers are denoted by the symbol [dec]. Table 3 provides an overview of the representations of variable fields and the data they hold.
An example of a message from the system is as follows:
interface with an unknown input point ([chars]). %LINK-2-BADVCALL:
Other messages include specific information about the card and slot that are reporting the error.
Real-Time Streaming Protocol Client Implementation
RTSP is an application-level protocol used to control the flow of real-time data during transmission. As a result of the robust infrastructure RTSP provides, real-time data may be sent on demand and under control. You may use RTSP, for example, to control the dissemination of audio streams hosted on an audio server.
An RTSP client included into a VoIP gateway allows conversations to be joined with audio streams from a remote audio server. Extra benefits consist of the following:
• Lightens the load on the central processing unit
•Enables the playing of more prominent prompts
•Lessens gateway RAM needs since packetization isn’t happening.
•Enables the use of a remote audio host. This third-party audio server removes limits on both the total number of prompts and their individual sizes.
Incoming IP Calls Trigger IVR Messages
Incoming POTS or VoIP call legs may be programmed with IVR Version 2.0 scripts to play announcements to users or collect user feedback (digits). Callers may access the IVR 2.0 prompts from either the PSTN or IP end of the call. Because of this feature, the audio files (or cues) may be played anywhere in the IP network.
When directed towards a VoIP call leg, IVR scripts must adhere to the following guidelines:
•Use G.711 mu-law encoding for playing prompts.
These calls must continue to use G.711 mu-law encoding even after prompt playout has concluded.
There is no DSP on the IP leg, thus the script can’t initiate a tone.
Using Cisco IOS Release 12.1(3)T, the system may receive G.711 calls from the IP side and then send them on to the terminating gateway using the same codec.
About Post Author
You must log in to post a comment.