Table Of Contents
Provisioning the Cisco HSI
Cisco HSI Configuration
HSI Configuration Data
Restarting the HSI in a Live Network
HSI Configuration File Maintenance
MML Configuration Commands
Introduction to MML Command Operation for HSI
Initiating an MML Session to Enable DTMF on the HSI
Verifying the Configuration
Reverting to the Base Configuration
HSI Data Categories
SYS_CONFIG_STATIC Parameters
SYS_CONFIG_DYNAMIC Parameters
H323_SYS Parameters
Q931 Parameters
RAS Parameters
H.245 Parameters
Codec Selection
CCPackage Parameters
Quick Reference for Important Parameters
HSI Feature Configuration
Asymmetric Codec Treatment
Empty Capability Set
H.323 Hairpin
T.38 Fax
Configuring T.38 Fax on the Cisco PSTN Gateway
Configuring T.38 Fax on a Cisco IOS H.323 Gateway
Configuring T.38 Fax on a Cisco IOS MGCP Gateway
H.225 Information Message Support
HSI Support for Tech Prefixes
H.323/SIP Interworking
HSI Notify Message Support
Adjustable Packetization
Enabling Dynamic Packetization
Carrier Code Mapping
Configuring Clear Channel on the Cisco HSI
Configuring G.726 on the Cisco HSI
Configuring G.729 Annex and G.729 Annex B
Using the Cisco HSI without a Gatekeeper (Non-RAS Mode)
Enabling the NON-RAS Mode of Operation on the Cisco HSI
Disabling the Non-RAS Mode of Operation on the Cisco HSI
H.323 Annex M.1 Support for Enhanced Interworking
Enabling Outbound H.323 Annex M.1 Support
Enabling Inbound H.323 Annex M.1 Support
Advertising H.323 Annex M.1 Support
Additional H.323 Annex M.1 Parameters
Alternate Endpoints
Configuring the Alternate Endpoints Feature
Per Call Support for the G.723.1 Codec
Provisioning the Cisco HSI
Revised: April, 2010, OL-11616-08
This chapter describes the data that must be provisioned for the Cisco H.323 Signaling Interface (HSI).
Cisco HSI Configuration
The Cisco HSI software provides an initial configuration file in /opt/GoldWing/currentPM/etc/GWmain.conf. (All configuration data is contained within configuration files.) The GWmain.conf file is created during the software installation and its contents are created when you enter values in response to prompts in the installation script.
If you issue the MML command prov-sta, the new configuration is stored in the directory /opt/GoldWing/currentPM/var/prov. This directory contains a link named active_config, which points to the currently active configuration. If you issue the MML command prov-rtrv:list, the command displays the contents of the directory in a column listing and marks the active configuration with an asterisk.
Note
If a configuration file name is longer than 9 characters, the asterisk does not appear in the column.
Typically, you use the following five MML commands to configure the Cisco HSI:
•
prov-sta—Starts an HSI configuration session
•
prov-ed—Edits a configuration file
•
prov-add—Adds a parameter to the configuration file
•
prov-dlt—Deletes a configured parameter
•
prov-cpy—Stores and deploys the configuration
HSI Configuration Data
There are three types of configuration data.
•
Permanent (constant, or internal) data—A user cannot modify permanent data, which are used internally by the Cisco HSI. For example, Application.Hardware and H323.maxTimers are present in the configuration but cannot be modified.
•
Immediate (dynamic) data—Immediate data takes effect when the prov-cpy command is executed. An example is sys_config_dynamic.UseRealSourceIP. Most sys_config_dynamic data is immediate data, but this is not always the case.
•
Restart data—Restart data takes effect immediately after the MML command prov-cpy is executed; but, this data requires a software restart (that is, /etc/init.d/CiscoGW [stop | start] or the MML command restart-softw). An example of restart data is ras.timeToLive. All sys_config_static data always requires a software restart.
Tip
We recommend that you always restart the Cisco HSI after you change the configuration. Doing so eliminates the risk that you would modify data that requires a restart but then forget to execute the restart.
Restarting the HSI in a Live Network
To change Restart data, first you must determine an acceptable off-peak time during which to change the configuration. The following steps show how to change a configuration while the HSI is operating in a live network.
Step 1
Start a provisioning session (prov-sta, srcver=active, dstver=xxx)
Step 2
Modify the parameters you want to change using the MML commands prov-add, prov-ed, and prov-dlt.
Step 3
Activate the configuration using the prov-cpy command.
Step 4
If it is not acceptable to cut off calls immediately, proceed to Steps 5-8. If it is acceptable to cut off calls immediately, issue the command restart-softw::confirm to stop the HSI from accepting new calls. The HSI will restart in 20 seconds.
Step 5
If it is not acceptable to cut off calls immediately, issue the command stp-callproc as follows:
This command stops the HSI from accepting new calls; but, it sustains existing connected calls for a period of 600 seconds.
Step 6
When the time-out period expires, ensure that all traffic has ceased by issuing the command rtrv-ne-health.
Step 7
Restart the HSI by issuing the command restart-softw.
In response to the restart-softw command, the software displays the message:
Then the software displays the message:
Step 8
To ensure that traffic processing has resumed, issue the command rtrv-ne-health.
HSI Configuration File Maintenance
As you modify a configuration during a provisioning session, the HSI software verifies that parameters are provisioned within allowable ranges. The software generates a checksum of the configuration file and writes the checksum as opt/GoldWing/currentPM/var/prov/configname/checksum.dat.
When the Cisco HSI starts, it attempts to read the active configuration, ensures that the configuration has been verified, and confirms that the checksum matches. If the active configuration is not verified or if the checksum is faulty, the HSI software reverts to using the configuration file opt/GoldWing/currentPM/etc/GWmain.conf.
All configuration data that can exist in the system is defined in the Skeleton Configuration file (see Appendix B, "Skeleton Configuration File." The Skeleton Configuration file (/opt/GoldWing/currentPM/etc/H323SkeletonFileSimple.dat) defines the data names and types (strings or numbers), and defines whether the data is modifiable or permanent. You can view this file; but, you should never modify it. Furthermore, you should not modify any configuration file directly. You should create configurations only by using the MML command line interface.
MML Configuration Commands
There are three types of MML configuration command:
•
Configuration session commands that work with entire provisioning data files (see Table 3-1)
•
Configuration component or parameter commands that perform actions on components or parameters affecting a specific data file (see Table 3-2)
•
Configuration export command (prov-exp)
For more information about MML configuration commands, see Appendix A, "MML User Interface and Command Reference."
Note
Parameter names used in MML commands are not case sensitive.
Table 3-1 Configuration Session Commands
Command
|
Description
|
prov-sta
|
Starts a provisioning session to create a new configuration or to modify an existing configuration
|
prov-cpy
|
Activates the configuration settings in the current provisioning session
|
prov-stp
|
Terminates the provisioning session and saves the configuration
|
Table 3-2 Configuration Component or Parameter Commands
Command
|
Description
|
prov-add
|
Adds a component to the Cisco HSI
|
prov-dlt
|
Deletes a provisioned component
|
prov-ed
|
Modifies a provisioned component
|
prov-rtrv
|
Retrieves information about an existing provisioning session
|
The configuration export command is prov-exp, which exports the currently provisioned configuration of the Cisco HSI to a file.
Introduction to MML Command Operation for HSI
After the HSI software is installed, you can configure additional features. The following MML command examples show how to enable DTMF capability on the HSI. (For a description of the sys_config_static entry and the DTMF parameters, please see the section (HSI Data Categories).
Initiating an MML Session to Enable DTMF on the HSI
The following MML command example shows how to start an MML session and enable DTMF support of the HSI:
Step 1
As root user, issue the following command:
/etc/init.d/CiscoGW start
Step 2
As mgcusr, begin an MML session by issuing the following command:
mml
Step 3
To enable DTMF support on the HSI, issue the following set of commands:
prov-sta:srcver=active, dstver=myconf
Note
The preceding command creates a new configuration, based on the current configuration, called myconf.
prov-add:name=sys_config_static, dtmfsupportedtype=dtmf
prov-add:name=sys_config_static, dtmfsupporteddirection=both
Note
Certain configuration changes do not take effect until the HSI is restarted. After the restart-softw command is issued, the HSI restarts in approximately 20 seconds.
Caution 
Use MML commands to perform all HSI configuration. Never manually edit system configuration files because they do not undergo the same parse checks as MML commands. In addition, the HSI uses a machine-generated checksum to verify the system files. If you modify the system configuration files manually, the HSI cannot use them and reverts to the base configuration.
Verifying the Configuration
The following MML command examples show how to verify that configuration changes have been correctly processed:
Step 1
To retrieve information about the current provisioning session, issue the following command:
Note
Cisco recommends limiting the length of configuration file names to 9 characters. If a configuration file name is 9 or fewer characters, when you issue the command prov-rtrv:list, the software prints an asterisk next to the currently active configuration among the listed files.
If configuration file names are longer than 9 characters, you can query for the currently active configuration file name by listing the contents of the /opt/GoldWing/currentPM/var/prov directory to examine the "active_config" link.
Step 2
To display the entire configuration, issue the following command:
To display a subset of the configuration, you can issue a command such as the following:
rtrv-config:sys_config_static
Step 3
To exit the MML command interpreter, issue the following command:
Reverting to the Base Configuration
The following MML command examples show how to revert to the base HSI configuration:
Step 1
To begin an MML session, issue the following command:
Step 2
To revert to the base HSI configuration, issue the following command:
Note
In the restart-softw:init command, "init" is a keyword that enables the restart-softw command to revert to the original configuration, which is derived from the user responses to prompts in the initial installation procedure. (See Step 6 in the "Installing Cisco HSI" section on page 2-5.)
To return to the configuration "myconf," one would issue the command restart-softw:myconf.
The following sections describe the SYS_CONFIG_STATIC, SYS_CONFIG_DYNAMIC, H323_SYS, Q931, RAS, H245 and CCPackage parameters in detail. The section "Quick Reference for Important Parameters" collects the most useful parameters into a single location for easy reference.
HSI Data Categories
The Cisco HSI data is divided into categories. The main categories are:
•
Application
•
CCPackage
•
EISUP
•
Gapping
•
H245
•
H323
•
Logging
•
Q931
•
RAS
•
SYS_CONFIG_DYNAMIC
•
SYS_CONFIG_STATIC.
The category names and names of configurable parameters are not case-sensitive; they also can be typed in lower-case. The individual parameters in these categories are all described in detail in the next section. The section "Quick Reference for Important Parameters" describes the most commonly modified values.
The section "HSI Feature Configuration" describes the configuration tasks required to enable specific features.
SYS_CONFIG_STATIC Parameters
Static data can be activated only at startup.
In the following example, the prov-add command adds the static parameter VSCA_PORT_NUMBER1 to a static configuration file. The prov-ed command modifies the value of the VSCA_PORT_NUMBER1 parameter. The prov-dlt command deletes the VSCA_PORT_NUMBER1 parameter from the static configuration file.
Example
prov-add:name=sys_config_static,vsca_port_number1=8003
prov-ed:name=sys_config_static,vsca_port_number1=8002
prov-dlt:name=sys_config_static,vsca_port_number1
The parameters in Table 3-3 are written to a static configuration file or to a section within a file.
Table 3-3 SYS_CONFIG_STATIC Parameters
Parameter
|
Type
|
Description
|
HOST_PORT_NUMBER1
|
[0-65535]
|
The first port number used by the Cisco HSI. The default value is 0.
Note This value must match the peer port setting on the PGW1 2200 EISUP IPLNK object.
|
HOST_PORT_NUMBER2
|
[0-65535]
|
The second port number used by the Cisco HSI. The default value is 0.
Note This parameter is used only for configuring redundant network interfaces.
|
HOST_IPADDR1
|
STRING
|
The primary IP address of HSI.
|
HOST_IPADDR2
|
STRING
|
The secondary IP address of HSI.
Note This parameter is used only for configuring redundant network interfaces.
|
VSCA_IPADDR1
|
STRING
|
The primary IP address of the primary PGW 2200.
|
VSCA_IPADDR2
|
STRING
|
The secondary IP address of the primary PGW 2200.
Note This value must match that of VSCA_IPADDR1.
|
VSCB_IPADDR1
|
STRING
|
The primary IP address of the secondary PGW 2200.
Note This parameter is not used in a standalone PGW configuration.
|
VSCB_IPADDR2
|
STRING
|
The secondary IP address of the secondary PGW 2200.
Note The value of this parameter must match that of VSCB_IPADDR1. This parameter is not used in a standalone PGW configuration.
|
VSCA_PORT_NUMBER1
|
[0-65535]
|
The first port number of the primary PGW 2200.
|
VSCA_PORT_NUMBER2
|
[0-65535]
|
The second port number of the primary PGW 2200.
Note This value must match that of VSCA_PORT_NUMBER1.
|
VSCB_PORT_NUMBER1
|
[0-65535]
|
The first port number of the secondary PGW 2200.
Note This parameter is not used in a standalone PGW configuration.
|
VSCB_PORT_NUMBER2
|
[0-65535]
|
The second port number of the secondary PGW 2200.
Note The value of this parameter must match that of VSCA_PORT_NUMBER2. This parameter is not used in a standalone PGW configuration.
|
ClipClirSupported
|
STRING
|
CLI presentation or restriction is enabled if this parameter is present and set to anything other than "". For example, to enable CLIP/CLIR support, set this parameter explicitly to "Enabled."
Note Setting this parameter to "enabled" also enables use of Caller ID.
|
RaiSupported
|
STRING
|
RAI support is enabled if this parameter is present and set to anything other than "". For example, to enable RAI support, set this parameter to "Enabled."
|
DtmfSupportedDirection
|
STRING
|
This is set to "both", "tx," or "rx". If this parameter is not present or is set to any value other than "both," "tx," or "rx," the DTMF Relay feature is disabled.
|
DtmfSupportedType
|
STRING
|
This is set to "dtmf" or "basicString." If this parameter is not present or set to any other value, the DTMF Relay feature is disabled.
|
H225PavoSupported
|
STRING
|
Pavo support is enabled if this parameter is present and set to anything other than "". For example, set it to "Enabled."
|
PavoRedirScreeningInd
|
[0-3]
|
The value of the Pavo redirecting number screening indicator. (If this parameter is not provisioned, the default is Q.931 zero—user provided, not screened.)
|
PavoRedirReason
|
[0-15]
|
The value of the Pavo redirecting number reason field. This parameter has no default. If this parameter is not provisioned, the redirecting number parameter does not contain the Reason for Redirection field (octet 3b).
|
PavoRedirPresInd
|
[0-3]
|
The value of the Pavo redirecting number presentation indicator. (If this parameter is not provisioned, the default is Q.931 zero—no indication.)
|
CliInDisplaySupported
|
STRING
|
If this parameter is present and set to anything other than "", the Calling Number is also sent in the DISPLAY IE. The NetMeeting endpoint retrieves the calling party number from the DISPLAY IE in the H.225 Setup message. To enable this parameter, set it to "Enabled."
|
T38MaxVal
|
STRING
|
Note Values for the following attributes must be expressed in hexadecimal format.
• MaxBit—[0x0—0xFFFFFFFF]. Specifies the maximum bit rate in units of 100 bits per second at which a transmitter can transmit or a receiver can receive T.38 FAX data. The default value is 0x90.
• FxMaxBuf—[0x0—0xFFFFFFFF]. Specifies the maximum buffer size for the "t38FaxMaxBuffer" parameter for the T.38 over UDP option. The default value is 0xc8.
• FxMaxData—[0x0—0xFFFFFFFF]. Specifies the maximum datagram size for the "t38FaxMaxDatagram" parameter for the T.38 over UDP option. The default value is 0x48.
|
T38Options
|
STRING
|
• FxFillBit—[0 or 1] The default value is 0.
• FxTransMMR—[0 or 1] The default value is 0.
• FxRateTransJBIG—[0 or 1] The default value is 0.
• FXRate—[Local or Trans] The default value is Trans.
• FxUdpEC—[Red or FEC] The default value is Red.
|
T38Disabled
|
STRING
|
If this parameter is present and set to any text value other than "" (blank), the Cisco HSI disables T38 support. To re-enable fax support, the parameter must be deleted or set to blank ("").
|
AsymmetricHandlingSupported
|
STRING
|
Asymmetric Codec Treatment support is enabled if this parameter is present and set to anything other than "". To enable Asymmetric Codec Treatment, set this parameter to "Enabled."
|
UseConfID
|
STRING
|
Use this parameter to specify the precedence of extracting the Global Call ID from the Conference ID or the GUID in the H.225 Setup message. The provisioning of this property to a value other than "" gives precedence to the Conference ID. For example, set it to "Enabled." To set the precedence to the GUID field, the crafts person can either delete the property from the config or set it to "".
|
DualCLISupported
|
STRING
|
To enable Dual CLI support (see H.246 Annex C), set this parameter to anything other than "". For example, to explicitly enable Dual CLI support, set this parameter to "Enabled."
|
InjectPI8
|
STRING
|
Some PSTN networks do not notify the PGW/HSI that inband information is available. Typically, such information would be included in the ISUP ACM message, in the Optional Backward Call Indicator (OBCI) parameter.
For networks that do not supply the OBCI parameter in ACM messages, it is possible to configure the HSI to insert a progress indicator (PI) value 8 (indicating inband information is available) into the H.225 alerting message automatically. To do so, set the InjectPI8 parameter to a text value (for example, "enabled" or "true"). If the incoming ACM message does contain an OBCI, the InjectPI8 parameter has no effect. This parameter should be configured only if required, because it might be undesirable to insert PI8 automatically when no OBCI is present.
In HSI Release 4.3(2) and later, the behavior of the InjectPI8 parameter has been extended. If it is set to the specific text value of "NoOptBCI" (case-sensitive), in additional to the above behavior, the HSI also inserts PI8 into the alerting message for cases in which the incoming ISUP CPG (call progress) message does not contain an OBCI parameter either.
If the InjectPI8 parameter is set to the specific text value of "NoInBand" (case-sensitive), the HSI (in addition to the original behavior referred to earlier), inserts PI8 into the alerting message for the case in which the CPG message contains an OBCI parameter and the PSTN network has set the inband information indicator to the value 0 (no indication).
If the InjectPI8 parameter is set to the specific text value of "NoOptBCIorNoInBand" (case-sensitive), (again in addition to the original behavior), the HSI inserts PI8 into the alerting message for cases in which the CPG message contains no OBCI, or in which the OBCI has the inband information indicator set to 0.
|
InformationMsgDisabled
|
STRING
|
The H.225 information message conveys ringing tone information. Support for this can be disabled by setting this parameter to any text value. To re-enable the H.225 information message support, delete the parameter or set it to blank ("").
|
GRQMsgEnabled
|
STRING
|
The HSI can be configured to broadcast a gatekeeperRequest message if the gatekeeper returns a gatekeeperReject message. In most circumstances, Cisco recommends not enabling this support, to prevent the HSI from registering to undesirable gatekeepers in the network. If the broadcast must be enabled, to do so, set this parameter to any text value (for example, "enabled" or "true"). To return to the default behavior, delete the parameter or set it to blank ("").
|
NotifyMsgEnabled
|
STRING
|
The H.225 notify message conveys connected name and connected number information. To enable support for this message, set this parameter to any text value (for example, "enabled" or "true"). To disable support, delete the parameter or set it to blank ("").
|
CarrierCodeMapping
|
STRING
|
For some H.323 networks, the H.323 gatekeeper might have the capability to route calls depending on the destination circuit ID "group" field in the H.225 admissionRequest message. You can enable the Cisco HSI to interpret a "magic number" in the Cisco PGW dial plan as a command to insert such an ID into the admissionRequest message, for PSTN to H.323 calls. This is described in detail in the "Carrier Code Mapping" section. To enable the feature, set the parameter to any text value (for example, "enabled" or "true"). To disable the parameter, delete it or set it to blank ("").
|
Q931RedirSupported
|
STRING
|
H.225 Setup messages can contain a Q.931 redirecting number parameter. To enable support of this parameter, set the Q931RedirSupported parameter to any text value (for example, "enabled" or "true"). To disable support, delete the parameter or set it to blank ("").
Note The parameter H225PavoSupported will override this parameter. To enable Q931RedirSupported, the parameter H225PavoSupported must not be present or it must be set to blank ("").
|
UseIncomingGkDestInfo
|
STRING
|
If this parameter is set to any text value (for example, "enabled" or "true"), the Cisco HSI modifies the called-party number (for calls that originate in the H.323 network) depending on the value returned by the gatekeeper in the destinationInfo field in H.225 admissionConfirm messages.
|
UseG726StaticPayload
|
STATIC
|
If this parameter is set to any text value, the HSI uses the static RTP/AVP payload value "2" to represent G.726 32kbit/sec to the MGCP gateway in the session description protocol (SDP) content. If the parameter is deleted or set to an empty string (""), the default behavior occurs (dynamic payload value).
|
AltEpSupported
|
STATIC
|
If this parameter is set to any text value (for example, "enabled" or "true"), for calls terminating in the H.323 network, the Cisco HSI uses the alternateEndpoints field in admissionConfirm messages to attempt multiple H.323 endpoints/gateways in sequential order. To disable the feature, delete the parameter or set it to blank (""). (See the section "Alternate Endpoints" for additional information.)
|
AltEpUseAliasAddr
|
STATIC
|
This parameter can be set to any text value (for example, "enabled" or "true"). The AltEpSupported parameter must be present for this parameter to take effect. (See the section "Alternate Endpoints" for additional information.)
|
AltEpCauseAllowed
|
STATIC
|
This parameter can be set to a string of cause codes (for example, "38 42") or set to blank (""). The AltEpSupported parameter must be present for this parameter to take effect. (See the section "Alternate Endpoints" for additional information.)
|
AltEpCauseDisallowed
|
STATIC
|
This parameter can be set to a string of cause codes (for example, "38 42") or set to blank ("").The AltEpSupported parameter must be present for this parameter to take effect. (See the section "Alternate Endpoints" for additional information.)
|
OutgoingCallUnansweredRelWait
|
STRING
|
If set to any non-empty value, the HSI waits for the other side to release a call when the call is not answered.
|
UseSysTimeEnabled
|
STRING
|
If set to any non-empty value, the HSI uses system-time instead of UTC time in the platform.log
|
IpTOS
|
[0-184]
|
Valid values for IpTOS are 0, 32, 40, 64, 72, 96, 104, 128, 136, 184. If you specify any other value in the range 0-184, the HSI sets the value to the default 96.
|
ConnectedCallsMaxDuration
|
[0-100]
|
Enables an operator to set a maximum duration (in hours) for a connected call. If a call exceeds the maximum duration, the HSI removes it from the connected state. Default is 0, which represents an infinite duration.
|
SYS_CONFIG_DYNAMIC Parameters
Dynamic data can be activated during system run time.
To modify the SYS_CONFIG_DYNAMIC parameters in Table 3-4, use the sys_config_dynamic MML name variable for the prov-add, prov-dlt, and prov-ed commands. You need not halt and restart call processing for the changes to take effect.
In the following example, the prov-add command adds the dynamic parameter OVLDLEVEL1PERCENT to a dynamic configuration file. The prov-ed command modifies the value of the OVLDLEVEL1PERCENT parameter. The prov-dlt command deletes the OVLDLEVEL1PERCENT parameter from the dynamic configuration file.
Example
prov-add:name=sys_config_dynamic,OVLDLEVEL1PERCENT=20
prov-ed:name=sys_config_dynamic,OVLDLEVEL1PERCENT=25
prov-dlt:name=sys_config_dynamic,OVLDLEVEL1PERCENT
The MML commands write the parameters in Table 3-4 to a dynamic configuration file or to a section within a file.
Table 3-4 SYS_CONFIG_DYNAMIC Parameters
Parameter
|
Description
|
Default
|
LOGDIRECTORY
|
Specifies the directory used when the active log file is created, and also specifies the directory where the rotated log file is stored.
Note Cisco recommends using the default directory.
|
/var/log/
|
LOGFILENAMEPREFIX
|
Specifies the filename prefix used when the log files are created or rotated. The .log prefix is appended to the end of the filename to establish the name of the active log file.
Note Cisco recommends using the default prefix.
|
platform.log
|
LOGPRIO
|
Determines the logging level at system startup. Once the system is running, this log level is not used.
Note Cisco recommends that you never modify the default setting (TRACE).
|
TRACE
|
LOGFILEROTATESIZE
|
Triggers a log file rotation based on the size of the active file. The application regularly checks the current size of the file to determine whether a rotation is required. If a file rotation is triggered by this parameter, the rotated file might be slightly larger than the size specified by this parameter. This parameter triggers a file rotation and also resets the timer associated with the LOGFILEROTATEINTERVAL parameter.
Note Cisco recommends that you never modify the default setting.
|
10 Mb
|
LOGFILEROTATEINTERVAL
|
Triggers a log file rotation based on the time elapsed since the previous rotation. This timer is reset after any rotation occurs, regardless of the cause or trigger of the rotation.
Note Cisco recommends that you never modify the default setting.
|
1440 minutes (24 hours)
|
OVLDSAMPLERATE
|
Defines the frequency of CPU sampling and threshold checking.
Note Cisco recommends that you never modify the default setting.
|
3000 millisecond (ms) polling rate
|
OVLDLEVEL1PERCENT
|
Indicates what percentage of calls should be rejected when an overload condition occurs. This parameter is used in conjunction with the OVLDLEVEL1FILTER parameter. The overload level 1 value is the lowest level of overload and must be less than or equal to the provisioned values for OVLDLEVEL2PERCENT and OVLDLEVEL3PERCENT.
Note If this value is set to zero, no overload level 1 treatment occurs.
Note Contact the Cisco TAC before you modify the default setting.
|
20
|
OVLDLEVEL1FILTER
|
Indicates what call types should be gapped if an overload level 1 condition occurs. The possible values are:
• Normal—Calls with an emergency or priority indication are not gapped.
• All—All calls are gapped, regardless of type.
Note If the overload percentage is set to 100, all calls are gapped irrespective of this setting.
Note Cisco recommends that you never modify the default setting (Normal).
|
Normal
|
OVLDLEVEL1THRESHLOWERCALLS
|
The number of active calls below which the application load must fall before the system removes the overload level 1 condition.
Note Cisco recommends that you never modify the default setting.
|
9000
|
OVLDLEVEL1THRESHUPPERCALLS
|
The number of simultaneous active calls that triggers an overload level 1 condition.
Note Cisco recommends that you never modify the default setting.
|
9100
|
OVLDLEVEL1THRESHLOWERCPU
|
The CPU utilization level below which the application must fall before the system removes the overload level 1 condition.
Note Cisco recommends that you never modify the default setting.
|
60
|
OVLDLEVEL1THRESHUPPERCPU
|
The level of CPU utilization that triggers an overload level 1 condition.
Note Cisco recommends that you never modify the default setting.
|
65
|
OVLDLEVEL2PERCENT
|
Indicates what percentage of calls should be rejected when an overload condition occurs. The parameter is used in conjunction with the OVLDLEVEL2FILTER parameter. This is the second level of overload and must be less than or equal to the provisioned value of OVLDLEVEL3PERCENT and greater than or equal to the provisioned value of OVLDLEVEL1PERCENT.
Note If this value is set to zero, no overload level 1 or 2 treatment occurs (by definition, the level 1 value must also be zero).
Note Contact the Cisco TAC before you modify the default setting.
|
75
|
OVLDLEVEL2FILTER
|
Indicates what call types should be gapped if an overload level 2 condition occurs (see OVLDLEVEL1FILTER).
|
Normal
|
OVLDLEVEL2THRESHLOWERCALLS
|
Determines the number of active calls below which the application load must fall in order for the overload level 2 condition to be removed.
Note Cisco recommends that you never modify the default setting.
|
9200
|
OVLDLEVEL2THRESHUPPERCALLS
|
Determines how many simultaneous active calls trigger an overload level 2 condition.
Note Cisco recommends that you never modify the default setting.
|
9600
|
OVLDLEVEL2THRESHLOWERCPU
|
Determines the level of CPU utilization below which the application must fall in order for the overload level 2 condition to be removed.
Note Cisco recommends that you never modify the default setting.
|
70
|
OVLDLEVEL2THRESHUPPERCPU
|
Determines the level of CPU utilization that triggers an overload level 2 condition.
Note Cisco recommends that you never modify the default setting.
|
80
|
OVLDLEVEL3PERCENT
|
Indicates what percentage of calls should be rejected when an overload condition occurs. The parameter is used in conjunction with the OVLDLEVEL3FILTER parameter. This is the highest level of overload and must be greater than or equal to the provisioned values for OVLDLEVEL1PERCENT and OVLDLEVEL2PERCENT.
Note If this value is set to zero, no overload treatment occurs (by definition, the level 1 and level 2 values must also be zero).
Note Contact the Cisco TAC before you modify the default setting.
|
90
|
OVLDLEVEL3FILTER
|
Indicates what call types should be gapped if an overload level 3 condition occurs (see OVLDLEVEL1FILTER).
|
Normal
|
OVLDLEVEL3THRESHLOWERCALLS
|
Determines the number of active calls below which the application load must fall in order to remove the overload level 3 condition.
Note Cisco recommends that you never modify the default setting.
|
9700
|
OVLDLEVEL3THRESHUPPERCALLS
|
Determines how many simultaneous active calls trigger an overload level 3 condition.
Note Cisco recommends that you never modify the default setting.
|
9800
|
OVLDLEVEL3THRESHLOWERCPU
|
Determines the level of CPU utilization below which the application must fall in order to remove the overload level 3 condition.
Note Cisco recommends that you never modify the default setting.
|
85
|
OVLDLEVEL3THRESHUPPERCPU
|
Determines the level of CPU utilization that triggers an overload level 3 condition.
Note Cisco recommends that you never modify the default setting.
|
95
|
ALARMDEBOUNCETIME
|
Specifies the length of time that an alarm condition must persist before being reported, and any associated action taken.
Note Cisco recommends that you never modify the default setting.
|
0
|
DISKUSAGELIMIT
|
Represents a percentage of disk occupancy.
The application continually polls the system for disk occupancy, and if the percentage rises above the limit set by DISKUSAGELIMIT, the LOW_DISK_SPACE alarm is raised.
DISKUSAGELIMIT has a default value of 98 percent. The value range is 0-100, inclusive. When dynamically provisioned, the parameter DISKUSAGELIMIT, if not set within that range, is set to the default value (98) and the CONFIGURATION_ FAILURE alarm is raised.
|
98
|
RegFailureReleaseCause
|
Specifies the Q.850 release cause, which the HSI uses after the HSI fails three times to register to a gatekeeper.
This parameter is assigned a value in the range 1—127.
|
—
|
EnableOutboundAnnexM1
|
Enables or disables the transmission of tunneled QSIG signaling protocol messages from the HSI, according to the H.323 Annex M.1 specification.
To enable the feature, set this parameter to any text value (for example, "true" or "enabled"). To disable the feature, delete the parameter or set to it to blank ("").
|
"-"
|
EnableInboundAnnexM1
|
Enables or disables the reception of tunneled QSIG signaling protocol messages by the HSI.
To enable the feature, set this parameter to any text value (for example, "true" or "enabled"). To disable the feature, delete the parameter or set it to blank ("").
|
"-"
|
IncludeAnnexM1inRRQ
|
If this parameter is set to any text value (for example, "enabled" or "true"), the Cisco HSI advertises that it supports Annex M.1 functionality in H.225 registrationRequest messages in the supportedTunnelledProtocols field.
|
"-"
|
IncludeAnnexM1inARQ
|
If this parameter is set to any text value (for example, "enabled" or "true"), the Cisco HSI indicates in H.225 admissionRequest messages that it desires Annex M.1 as a tunneled protocol. It will indicate this in the desiredTunnelledProtocol field.
|
"-"
|
AlternateGatekeeperIp
|
Specifies the IP address of an alternate gatekeeper. (The Cisco HSI also supports alternate gatekeepers specified in H.225 registrationConfirm messages).
If this parameter is deleted, the Cisco HSI receives alternate gatekeeper information only through H.225 registrationConfirm messages.
|
"-"
|
AlternateGatekeeperPort
|
Specifies the H.225 RAS port of the alternate gatekeeper. For this parameter to take effect, AlternateGatekeeperIp also must be configured.
If AlternateGatekeeperPort is not configured, port 1719 is used by default.
|
"-"
|
AlternateGatekeeperId
|
Specifies the gatekeeper ID to use when communicating with the alternate gatekeeper.
|
"-"
|
MapUsiToBearerCap
|
If this parameter is set to any text value (for example, "true" or "enabled"), for PSTN originated calls, the Cisco HSI maps the "User service information" field in the ISUP IAM message into the bearer capability field in the outgoing H.225 Setup message. If this parameter is deleted or set to blank (""), the HSI maps the "Transmission medium requirement" field in ISUP IAM messages into the bearer capability instead.
|
"-"
|
AltEpGkXlateCdpnToRadius
|
If Alternate Endpoints functionality is enabled on the HSI (by enabling the AltEpSupported parameter), by configuring this parameter for PSTN originated calls, the Cisco HSI sends the destination H.323 called party number (as sent by the gatekeeper in the alternateEndpoints field) to the Cisco PGW for RADIUS record accounting purposes. To disable this feature, delete this parameter or set it to blank ("").
|
"-"
|
IgnoreTunnReq
|
By default, if the calling H.323 endpoint/gateway sets the tunnellingRequired parameter in the tunnelledSignallingMessage field of the H.225 Setup message, the Cisco HSI does not proceed with the call if Annex M.1 support is disabled on the Cisco HSI.
By setting the IgnoreTunnReq parameter to any text value (for example, "true" or "enabled"), the HSI does proceed with the call. To revert to the default behavior, delete this parameter or set it to blank ("").
|
"-"
|
UseRealSourceIP
|
By default, for calls originating from H.323, the Cisco HSI passes the H.225 Setup message sourceCallSignalAddress to the PGW, for recording purposes (for example, RADIUS accounting). If the UseRealSourceIP parameter is set to any text value (for example, "true" or "enabled"), the Cisco HSI sends the TCP/IP address of the H.225 connection instead. This is useful for cases in which the sourceCallSignalAddress cannot be trusted. To revert to the default behavior, delete this parameter or set it to blank ("").
|
"-"
|
InitiateTCSAfterFSCall
|
For fast start calls, you can configure the HSI to attempt to open a TCP/IP connection for H.245 communication after fast start. To enable this feature, set the parameter to any text value (for example, "true" or "enabled"). To disable the feature, delete this parameter or set it to blank ("").
|
"-"
|
TransmitTCSAfterFSCall
|
For fast start calls, you can configure the HSI to attempt to send a H.245 terminalCapabilitySet message if the H.245 communication channel is open. To enable this feature, set the parameter to any text value (for example, "true" or "enabled"). To disable the feature, delete this parameter or set it to blank ("").
|
"-"
|
DefaultBCLayer1Protocol
|
For PSTN originated calls, you can configure the Cisco HSI to insert a bearer capability "User info layer 1 protocol" value into the outgoing Setup message. This is useful for interworking to H.323 devices that expect a particular value. The valid values for this parameter are:
• 0—Unknown (default)
• 2—G.711 u-law
• 3—G.711 A-law
• 5—H.221 and H.242
|
"-"
|
DynamicPacketizationSupported
|
Enables the Cisco HSI to drop the media packetization period from its advertised value. This is useful for cases in which it is desirable to conform to the remote endpoint packetization size. If the feature is enabled and the Cisco HSI advertises a 20 msec packetization period in the H.245 terminalCapabilitySet message, but the remote endpoint sends an openLogicalChannel message containing 10 msec, the Cisco HSI also responds with the lower 10 msec value.
To enable the feature, set the parameter to any text value (for example, "true" or "enabled"). To revert to the default behavior, delete the parameter or set it to blank ("").
|
"-"
|
SendAnnexM1inOverlapFacility
|
If this parameter is configured for PSTN originated Annex M.1 calls, the Cisco HSI sends the tunneled content to the H.323 endpoint/gateway in H.225 facility messages while establishing overlap calls. The default action is to send the tunneled content in H.225 information messages. Enable the parameter by setting it to any text value (for example, "true" or "enabled"). To revert to the default action, delete the parameter or set it to blank ("").
|
"-"
|
TermAliasInARQ
|
By default, for calls originating from the H.323 network, the Cisco HSI sends an admissionRequest message to the gatekeeper that contains a value in srcInfo, which is derived from the incoming H.225 Setup message sourceAddress field. Some non-standard gatekeepers require a fixed value in the srcInfo field. If TermAliasInARQ is set to any text value (for example, "enabled" or "true"), the Cisco HSI inserts the contents of the RAS.terminalAlias[1].h323ID parameter into the srcInfo field. For the default behavior, delete the TermAliasInARQ parameter or set it to blank (""). Cisco recommends the default setting unless the gatekeeper is incompatible.
|
"-"
|
FSIgnoreFraming
|
By default, the Cisco HSI attempts to match the codec technology (for example, G.711, G.729, etc.) and the packetization size (for example, 20 msec) between the H.323 network and the MGCP voice gateway, in order to establish successful calls. In some extremely limited scenarios, it might be desirable to match codec technology only, and ignore incompatibilities in packetization sizes. To achieve this, set this parameter to any text value (for example, "enabled" or "true"). To revert to the default behavior, delete the parameter or set it to blank (""). Cisco strongly recommends that you use the default.
|
"-"
|
carriercodemapping
|
The PGW can use the Carrier Code, ##xxx#, as a prefix in the CDPN. The HSI uses this information as carrier code in the ARQ message.
|
"-"
|
mapusitobearercap
|
When set to a non-empty value, the HSI maps EISUP/ISP User-Service-Information to Q931/H225 BearerCap information.
|
"-"
|
RelCallOnFailedChanNegotiation
|
When set to a non-empty value, the HSI releases calls when H.245 channel negociation fails.
|
"-"
|
HandleDelayedSDPAfterCallProc
|
When set to a non-empty value, the HSI supresses H.245 address if the HSI does not receive SDP from the PGW 2200.
|
|
IamToSetupDisplayDisabled
|
When set to a non-empty value, the HSI disables display-name mapping from the Cisco PGW 2200 to H.323.
|
"-"
|
InjectPI8InAlerting
|
When set to a non-empty value, the HSI inserts the ProgressIndicator=8 into the outgoing ALERTING message.
|
"-"
|
RelCallOnFailedChanNegotiation
|
When set to a non-empty value, the HSI releases calls when H.245 channel negociation fails.
|
"-"
|
SubAddrIn
|
When set to a non-empty value, the HSI enables a calling/called-party sub-address in incoming H.323 calls.
|
"-"
|
SubAddrOut
|
When set to a non-empty value, the HSI enables a calling/called-party sub-address in outgoing H.323 calls.
|
"-"
|
EnforceTunnReq
|
When set to a non-empty value, the HSI checks for "tunnelledSignallingMessage.tunnellingRequired" in the incoming Q931/H225 SETUP message and enforces the requirement by releasing the call if "EnableInboundAnnexM1" is not configured.
|
"-"
|
WaitTCSAfterCallResume
|
When set to a non-empty value, the HSI waits for TCS from the CCM side before sending out MSD.
Note Enable this parameter only if the HSI is connected to CCM 5.1 and is experiencing call hold/resume problems.
|
"-"
|
UsePayloadTypeMapping
|
When set to a non-empty value, the HSI negotiates the SDP payload type to be identical to the value received from the Cisco PGW 2200. By default, this parameter is disabled (set to an empty value). In the default case, the HSI uses the payload type that is hardcoded (static) in the HSI.
To enable payload mapping issue the following MML command:
prov-add:name=sys_config_dynamic,
UsePayloadTypeMapping="true"
To disable payload mapping issue the following MML command:
prov-ed: name=sys_config_dynamic,
UsePayloadTypeMapping=""
|
"-"
|
enableAnnexEinRRQ
|
When enabled, the parameter enableAnnexEinRRQ sets the "H.323 Annex.E transport address" as an alternate signalling address. By default, this parameter it is not set. Currently, Cisco recommends retaining the default setting for this parameter, which is disabled.
|
"-"
|
EnableFramePerPacketMapping
|
When enabled, the HSI maps between H.245 fpp (frames per packet) and EISUP SDP ptime.
|
"-"
|
H323_SYS Parameters
The parameters in Table 3-5 are required for Cisco HSI initialization. For normal conditions, you should not need to modify these parameters.
Caution 
Please contact Cisco Systems before you attempt to modify any of these parameters.
Table 3-5 H323_SYS Parameters
Parameter
|
Description
|
Type
|
Example
|
maxCalls*
|
Maximum number of concurrent calls allowed
|
INTEGER(0 through 65535)
|
2500
|
maxChannels*
|
Maximum number of concurrent channels allowed
|
INTEGER(0 through 65535)
|
2
|
maxDescs
|
Maximum numbers of file descriptors allowed.
|
INTEGER(0 through 80000)
|
30000
|
Note
The asterisk (*) after a parameter name in the first column of Table 3-5 denotes a mandatory RADVision parameter that has an inbuilt default value if a value is not set during provisioning.
Q931 Parameters
To modify the parameters listed in Table 3-6, use the q931 MML name variable for the prov-add, prov-dlt, and prov-ed commands.
In the following example, the prov-add command sets the Q.931 parameter responseTimeOut to the value 5.
Example
prov-add:name=q931,responseTimeOut=5
If you modify any of the Q931 parameters, you must restart the HSI to enable them to take effect.
Table 3-6 Q.931 Parameters
Parameter Name
|
Description
|
Type
|
Example
|
responseTimeOut
|
If you set this parameter to a numeric value in the range [1-200], the HSI uses this value as the number of seconds to wait, after sending a H.323 Setup message, for a backward response (callProceeding). The default setting is 60 seconds. For networks in which the gatekeeper is expected to provide a list of alternate endpoints, it is advisable to set this parameter to a low value.
|
INTEGER (1 through 200)
|
60
|
connectTimeOut
|
The maximum time (in seconds) the that stack waits for call establishment after the first response is received. If this time expires, the call is disconnected.
|
INTEGER (1 through 20000)
|
180
|
callSignalingPort
|
The number of the port receiving the calls destined for the PGW 2200.
|
INTEGER (0 through 65535)
|
1720
|
maxCalls
|
The maximum number of simultaneous calls permitted. If this parameter is exceeded, the next call attempt returns busy.
|
INTEGER (0 through 65535)
|
10000
|
overlappedSending
|
Because the Q.931 configuration flag indicates that both parties support overlap sending, this state notifies the other party that it can send an overlap sending message.
Cisco recommends that you do not modify the default setting.
|
NULL
|
Present
|
earlyH245
|
This is an internal parameter that should not be modified.
|
|
|
H245tunneling
|
This is an internal parameter that should not be modified.
|
|
|

Note
The Q.931 parameter overlappedSending has been combined with the RAS overlappedSending parameter. If you set the Q.931 overlappedSending parameter, you also set the RAS overlappedSending parameter.
RAS Parameters
The parameters in Table 3-7 are required for RAS stack initialization. To modify the RAS parameters, use the ras MML name variable for the prov-add, prov-dlt, and prov-ed commands.
In the following example, the prov-add command sets the RAS parameter maxfail to the value 3.
Example
prov-add:name=ras,maxfail=3
The array index [i] in some of the parameter names in the first column of Table 3-7 must be replaced with a valid braced index from 1 to 20, and must be continuous and unique (that is, it must contain no duplicates).
The Update Type column in Table 3-7 shows when the change to a parameter takes effect after it is modified:
•
Immediate means that the effect of the change is immediate.
•
Restart means that the application needs to be restarted for the change to take effect.
•
Next Call means that the next call has the new parameter set.
Note
Immediate and next call update types are dynamic system data.
Table 3-7 RAS Parameters
Parameter Name
|
Description
|
Type
|
Example
|
Update Type
|
manualRAS
|
Typically, the Cisco HSI operates in conjunction with a gatekeeper. However, it is possible to use the HSI in networks without a gatekeeper. In this case, the PGW dial plan contains the destination IP address for H.323 terminated calls. To enable this non-gatekeeper feature on the HSI, enter the MML command:
prov-add:name=RAS, manualRAS (It has no value)
To disable the feature (and use a gatekeeper) enter the MML command:
prov-dlt:name=RAS, manualRAS
Note If you enable this feature on the HSI, you must ensure that the feature is also enabled on the PGW.
By default, the feature is disabled and the Cisco HSI uses a gatekeeper.
|
NULL
|
—
|
Restart
|
responseTimeOut
|
The time, in seconds, that the HSI waits for the response to a RAS transaction (admissionRequest- admissionConfirm).
|
INTEGER(1, 200)
|
10
|
Immediate
|
maxFail
|
This is an internal parameter that should not be modified.
|
INTEGER(1, 200)
|
3
|
Immediate
|
timeToLive
|
The time, in seconds, that the Cisco HSI waits before re-registering with the gatekeeper. This is used as a keepalive mechanism to check periodically that the gatekeeper is still up and running.
Note The gatekeeper can override the timeToLive value in the registrationConfirm message.
|
INTEGER(1, 65535)
|
400
|
Immediate
|
rasPort
|
The number of the port that receives all RAS transactions. Set this parameter to 0 to enable the HSI to search for the available port.
|
INTEGER(0, 65535)
|
0
|
Restart
|
compare15bitRasCrv
|
If this parameter is present and set to a blank ("") value, the stack ignores the call reference value (CRV) most significant bit (MSB) in RAS messages. If this parameter is deleted, all 16 bits of the CRV are analyzed. For maximum compatibility with H.323 endpoints, Cisco recommends that you never change the default setting.
|
NULL
|
—
|
Immediate
|
maxRetries
|
Maximum number of RAS retransmissions.
|
INTEGER(1, 200)
|
3
|
Immediate
|
maxMulticastTTL
|
Maximum duration of multicast time to live (TTL).
|
INTEGER(0, 200)
|
3
|
Restart
|
preGrantedArqUse
|
By default, the Cisco HSI does not use the H.323 pre-granted ARQ method of establishing call admission control. To enable the feature, set this parameter to the text value "direct". To revert to the default behavior (which is recommended), delete this parameter.
|
STRING
|
direct
|
Next Call
|
manualDiscovery.ipAddress
|
The IP address of the gatekeeper to which the Cisco HSI should register.
|
STRING
|
10.70.54.53
|
Restart
|
manualDiscovery.port
|
The UDP port number for the gatekeeper. Typically, the setting for most gatekeepers is port 1720.
|
INTEGER(0, 65535)
|
1719
|
Restart
|
gateway.prefix[i]
|
The telephone prefix that the Cisco HSI uses to register to the gatekeeper. The gatekeeper then can direct all calls that contain a called party number bearing the same prefix to the HSI and into the PSTN.
|
STRING
|
0208
|
Immediate
|
gatekeeperId
|
The gatekeeper identifier (a text field). This should be configured to match the gatekeeper configuration. For Cisco gatekeepers, the gatekeeper identifier is the text string in the IOS zone local command. The text field is case-sensitive. (The case of the gatekeeperID in the HSI configuration and in the gatekeeper configuration should match exactly.)
|
STRING
|
OuterLondon
|
Immediate
|
terminalAlias[i].h323ID
|
The alias name you can give to the Cisco HSI. If you are using a Cisco gatekeeper, this can be a name like hsi1@OxfordDomain.com. The IOS gatekeeper is configured "zone local OxfordGK OxfordDomain.com"
|
STRING
|
GW@ot.com.au
|
Immediate
|
endpointVendor.t35CountryCode
|
These parameters identify the manufacturer of the endpoint.
Note Cisco recommends that you do not change the default setting.
|
INTEGER(0, 255)
|
11
|
Immediate
|
endpointVendor.t35Extension
|
INTEGER(0, 255)
|
11
|
Immediate
|
endpointVendor.manufacturerCode
|
INTEGER(0, 65535)
|
9
|
Immediate
|
endpointVendor.productId
|
Data that the manufacturer assigns to each product.
Note Cisco recommends that you do not change the default setting.
|
STRING
|
H323ESP
|
Immediate
|
endpointVendor.versionId
|
Data that the manufacturer assigns to each version.
Note Cisco recommends that you do not change the default setting.
|
STRING
|
R0.2.4
|
Immediate
|
H.245 Parameters
To modify the H.245 parameters listed in Table 3-8, use the h245 MML name variable for the prov-add, prov-dlt, and prov-ed commands.
In the following example, the prov-add command sets the H.245 parameter masterSlave.timeout to the value 5.
Example
prov-add:name=h245,masterSlave.timeout=5
The Update Type column in Table 3-8 shows when a change to an H.245 parameter takes effect after it is modified:
•
Immediate means that the effect of the change is immediate.
•
Start means that the application needs to be restarted for the change to take effect.
•
Next Call means that the next call has the new parameter set.
Note
Immediate and Next Call update types are dynamic system data.
Table 3-8 H.245 Parameters
Parameter Name
|
Description
|
Type
|
Example
|
Update Type
|
masterSlave.terminalType
|
Defines the H.245 terminalType value that the Cisco HSI uses in H.323 master/slave negotiation. The default value is recommended.
|
INTEGER(0, 255)
|
60
|
Next Call
|
masterSlave.manualResponse
|
This is an internal parameter that should not be modified.
|
NULL
|
Present
|
Next Call
|
masterSlave.timeout
|
The maximum time (in seconds) that the stack waits before it gives up on the master/slave procedure.
The default value should not be modified.
|
INTEGER(0, 65535)
|
5
|
Immediate
|
channelsTimeout
|
The time (in seconds) that the stack waits for a response to a channel establishment message.
|
INTEGER(0, 65535)
|
10
|
Immediate
|
roundTripTimeout
|
The time (in seconds) that the stack waits for round-trip procedure completion.
The default value should not be modified.
|
INTEGER(0, 65535)
|
5
|
Immediate
|
requestCloseTimeout
|
The time (in seconds) that the stack waits for request close procedure completion.
The default value should not be modified.
|
INTEGER(0, 65535)
|
5
|
Immediate
|
requestModeTimeout
|
The time (in seconds) that the stack waits for request mode procedure completion.
The default value should not be modified.
|
INTEGER(0, 65535)
|
5
|
Immediate
|
caps.timeout
|
The maximum time (in seconds) that the stack waits before it gives up on the capability exchange procedure.
The default value should not be modified.
|
INTEGER(0, 65535)
|
5
|
Immediate
|
caps.maxAudioDelay
|
Maximum H.255 multiplex audio delay jitter.
The default value should not be modified.
|
INTEGER(0, 1023)
|
60
|
Immediate
|
mediaLoopTimeout
|
The timeout (in seconds) of the media loop procedure.
The default value should not be modified.
|
INTEGER(0, 65535)
|
5
|
Immediate
|
caps.manualOperation
|
This is an internal parameter that should not be modified.
|
|
|
|
masterSlave.manualOperation
|
This is an internal parameter that should not be modified.
|
|
|
|
Table 3-9, Table 3-10, and Table 3-11 list the parameters and modes related to the configuring of codecs. The array index [i] must be replaced with a valid braced index from 1 to 20. The braced index must be continuous and unique (that is, there must be no duplicates).
Table 3-9 H.245 Terminal Capability Codec Parameters
Parameter Name
|
Type
|
caps.table[i].entryNo
|
INTEGER(1, 65535)
|
caps.table[i].audio.g711Alaw64k
|
INTEGER(1, 256)
|
caps.table[i].audio.g711Alaw56k
|
INTEGER(1, 256)
|
caps.table[i].audio.g711Ulaw64k
|
INTEGER(1, 256)
|
caps.table[i].audio.g711Ulaw56k
|
INTEGER(1, 256)
|
caps.table[i].audio.g722at64k
|
INTEGER(1, 256)
|
caps.table[i].audio.g722at56k
|
INTEGER(1, 256)
|
caps.table[i].audio.g722at48k
|
INTEGER(1, 256)
|
caps.table[i].audio.g7231.maxAudioFrames
|
INTEGER(1,256)
|
caps.table[i].audio.g7231.silenceSuppression
|
INTEGER(0,1)
|
caps.table[i].audio.g728
|
INTEGER(1, 256)
|
caps.table[i].audio.g729
|
INTEGER(1, 256)
|
caps.table[i].audio.g729AnnexA
|
INTEGER(1, 256)
|
caps.table[i].audio.g729wAnnexB
|
INTEGER(1, 256)
|
Table 3-10 H.245 Channel Codec Parameters
Parameter Name
|
Type
|
chan[i].name
|
STRING
|
chan[i].audio.g711Alaw64k
|
INTEGER(1, 256)
|
chan[i].audio.g711Alaw56k
|
INTEGER(1, 256)
|
chan[i].audio.g711Ulaw64k
|
INTEGER(1, 256)
|
chan[i].audio.g711Ulaw56k
|
INTEGER(1, 256)
|
chan[i].audio.g722at64k
|
INTEGER(1, 256)
|
chan[i].audio.g722at56k
|
INTEGER(1, 256)
|
chan[i].audio.g722at48k
|
INTEGER(1, 256)
|
chan[i].audio.g7231.maxAudioFrames
|
INTEGER(1,256)
|
chan[i].audio.g7231.silenceSuppression
|
INTEGER(0,1)
|
chan[i].audio.g728
|
INTEGER(1, 256)
|
chan[i].audio.g729
|
INTEGER(1, 256)
|
chan[i].audio.g729AnnexA
|
INTEGER(1, 256)
|
chan[i].audio.g729wAnnexB
|
INTEGER(1, 256)
|
Table 3-11 H.245 Modes
Parameter Name
|
Type
|
modes[i].name
|
STRING
|
modes[i].audio.g711Alaw64k
|
NULL
|
modes[i].audio.g711Alaw56k
|
NULL
|
modes[i].audio.g711Ulaw64k
|
NULL
|
modes[i].audio.g711Ulaw56k
|
NULL
|
modes[i].audio.g722at64k
|
NULL
|
modes[i].audio.g722at56k
|
NULL
|
modes[i].audio.g722at48k
|
NULL
|
modes[i].audio.g7231
|
INTEGER(1,256)
|
modes[i].audio.g728
|
NULL
|
modes[i].audio.g729
|
NULL
|
modes[i].audio.g729AnnexA
|
NULL
|
modes[i].audio.g729wAnnexB
|
NULL
|
Codec Selection
The Cisco HSI negotiates the media stream codec to establish a match between the PSTN MGCP media gateway (for example, the Cisco AS5xxx series or Cisco MGX series) and the H.323 endpoint or H.323 gateway. To match codecs, the MGCP gateway must be configured to match what is expected at the H.323 end. Similarly, the Cisco HSI also must be configured with the same codecs.
The Cisco HSI receives a list of codecs from the MGCP gateway and tries to match them to the codecs that are configured on the HSI. The HSI advertises all of the successful matches in the H.245 terminalCapabilitySet messaging with the H.323 endpoint.
In order to achieve a successful match, the HSI seeks to find common codec technologies (for example, G.711, G.729, etc) between the PSTN side and the H.323 network, and also common media payload packet sizes. The codecs that are to be supported are configured under the H245.caps, H.245.chan and H.245.modes parameters. These parameters reflect the structures used in the H.245 specification to describe media capabilities. Typically, each codec requires six configuration entries, although some codecs are slightly different (for example, G.723.1). The six basic entries are:
•
caps.table[i].audio.xxx
•
caps.table[i].entryNo
•
chan[i].audio.xxx
•
chan[i].name
•
modes[i].audio.xxx
•
modes[i].name
In the preceding entries, xxx is the codec name keyword, which can be:
•
g711Alaw64k
•
g711Ulaw64k
•
g728
•
g729
•
g7231
•
g729AnnexA
•
g729wAnnexB
•
g729AnnexAwAnnexB
•
g726-cisco
•
g726-generic
•
gclear
•
g722at64k
•
g722at56k
•
g722at48k
The value given to the caps[i].audio.xxx and chan[i].audio.xxx parameters is known as the "frames per packet" (fpp) value, which is a way of representing the packet size for a given codec technology (a frame is the smallest discrete quantity of bytes that can be encoded/decoded for that particular codec). Table 3-12 illustrates the relationship between packet size, packetization period (that is, audio duration) and byte size of the payload, for some popular codecs and common packetization periods. Notice that G.711 does not have a concept of frames per packet because there is no encoding into frames, but a value of eight 8-bit samples (or bytes) per frame is the convention.
Table 3-12 HSI Codec Matrix
Codec
|
Frames Per Packet
|
Packetization Period (msec)
|
Packet Size (bytes)
|
G.711A/u-law
|
10
|
10
|
80
|
20
|
20
|
160
|
G.729/a/b
|
2
|
20
|
20
|
3
|
30
|
30
|
G.723.1
|
1
|
30
|
24
|
2
|
60
|
48
|
The configuration for G.726 and G.clear is described in detail in the "Configuring G.726 on the Cisco HSI" section.
Sample Codec Configuration
The following example shows the series of MML commands required to configure the codec G723.1:
Example
prov-add:name=h245, caps.table[x].entryNo = 7231
prov-add:name=h245, caps.table[x].audio.g7231.maxAudioFrames = 12
prov-add:name=h245, caps.table[x].audio.g7231.silencesuppression = 1
prov-add:name=h245, chan[x].name = g7231
prov-add:name=h245, chan[x].audio.g7231.maxAudioFrames = 12
prov-add:name=h245, chan[x].audio.g7231.silencesuppression = 1
prov-add:name=h245, modes[x].audio.g7231
prov-add:name=h245, modes[x].name = g7231
It is important to determine and configure the fpp value correctly on the Cisco HSI per codec. If the value is incorrect, the codec may not be negotiated successfully between the HSI and the H.323 endpoint. It is also important to configure the MGCP gateway correctly. The gateway should be configured to provide static payload values for the required codecs, rather than dynamic payload types (see Table 4 in RFC 3551, Schulzrinne and Casner), although the Cisco HSI does support dynamic payload values for the particular codecs that require it.
CCPackage Parameters
The Cisco HSI uses the CCPackage configuration to map values for PSTN/H.323 message content. The majority of the CCPackage parameters are permanent data for internal HSI use, and are not modifiable. The parameters that are modifiable are recorded in the "Quick Reference for Important Parameters" section.
Quick Reference for Important Parameters
Table 3-13, Table 3-14, Table 3-15, and Table 3-16 can be used in initial HSI configuration. The tables present parameters that you might use frequently to align the Cisco HSI with an existing PSTN or Voice over IP network.
Table 3-13 presents important CCPackage parameters.
Table 3-13 Important CCPackage Parameters
Parameter Name
|
Parameter Value
|
Description
|
A_CC_oLinecall
|
0—Unknown
10—Ordinary
|
Calling party's category
|
A_CC_Clir
|
0—No indication
1—Presentation allowed
2—Presentation restricted
3—Address not available
|
Address presentation restricted indicator
|
A_CC_ANumDataSI
|
0—None
1—User provided not verified
2—User provided verified passed
3—User provided verified failed
4—Network provided
|
Screening indicator
|
A_CC_oIsdnAllTheWay
|
0—ISDN user part not used all the way
1—ISDN user part used all the way
|
Forward call indicator, ISUP indicator
|
A_CC_oIsdnPref
|
0—ISDN user part preferred all the way
1—ISDN user part not required all the way
2—ISDN user part required all the way
|
Forward call indicator, ISUP preference
|
A_CC_Interworking
|
0—No interworking encountered (SS7 all the way)
1—Interworking encountered
|
Backward call indicator, Interworking indicator
|
A_CC_Location
|
1—User
2—Private local
3—Public local
4—Transit
5—Public remote
6—Private remote
7—International
8—Interworking
9—Local interface
11—Local remote
12—Packet manager
13—Unknown
|
Cause indicator, Location
|
The following MML command example shows the command sequence used to provision the CCPackage parameters provided in the preceding table.
Example
prov-sta::srcver=active, dstver=myconf
prov-ed:name=CCPackage, A_CC_ANumDataSI=2
Table 3-14 presents important SYS_CONFIG_STATIC parameters.
Table 3-14 SYS_CONFIG_STATIC Parameters
Parameter Name
|
Parameter Values
|
Description
|
CarrierCodeMapping
|
• "enabled"—a string that indicates the feature is enabled.
• Blank ("")—indicates the feature is disabled.
• "deleted"—indicates that the feature is disabled.
|
Allows the mapping of a special tech prefix (the format of which is CCxCy) to the DestinationCircuitID "group" field in the ARQ message. This feature works only with IOS Gatekeeper build Release 12.2(15)T10 or later. See the section "Carrier Code Mapping" for more information.
|
ClipClirSupported
|
• "enabled"—a string that indicates the feature is enabled.
• Blank ("")—indicates the feature is disabled
• "deleted"—indicates that the feature is disabled
|
Allows transit of CLI presentation/screening information.
Note Setting this parameter to "enabled" enables use of Caller ID.
|
DtmfSupportedType
|
• "dtmf"—the recommended value for interworking with Cisco gateways. The H.245 UserInputIndicator's signalType (send and receive)
• "basicString"—H.245 UserInputIndicator's alphanumeric (receive)
• null (" ")—RFC2833 telephony-event method (default)
|
Selects the DTMF type during H.245 terminal capabilities exchange.
Note Set this parameter to "dtmf" and the DtmfSupportedDirection parameter to "both" to enable DTMF support.
|
DtmfSupportedDirection
|
• "tx"—transmit to H323 endpoint
• "rx"—receive from H.323 endpoint
• "both"—transmit and receive DTMF
• Blank (""), "deleted," or any other string, such as "disabled"—indicates the feature is disabled
|
Selects DTMF transit direction.
Note Set this parameter to "both" and the DtmfSupportedType parameter to "dtmf" to enable DTMF support.
|
H225PavoSupported
|
• "enabled"—a string that indicates the feature is enabled.
• Blank ("")—indicates the feature is disabled
• "deleted"—indicates that the feature is disabled
|
Allows transit of redirecting number parameter (contained in Cisco CallManager H.225 Setup messages—nonStandardControl field).
|
RaiSupported
|
For example:
• "enabled"—a string that indicates the feature is enabled.
• Blank ("")—indicates the feature is disabled
• "deleted"—indicates that the feature is disabled
|
Allows H.225 RAS RAI messages to be sent to the gatekeeper if the EISUP link fails or if the HSI is under heavy load.
Note Set this parameter to "enabled" to enable the HSI to support RAI messages.
|
NotifyMsgEnabled
|
For example:
• "enabled"—a string that indicates the feature is enabled.
• Blank ("")—indicates the feature is disabled
• "deleted"—indicates that the feature is disabled
|
Allows transit of connected number, display information, and generic notification indicator in H.225 Notify messages.
|
VSCB_IPADDR1/2
|
IP address, for example: "10.10.10.1"
|
Allows IP address configuration of second PGW.
|
VSCB_PORT_NUMBER1/2
|
Port number, for example: 8003
|
Allows port configuration of second PGW.
|
The following MML command example shows the command sequence used to provision the SYS_CONFIG_STATIC parameters provided in the preceding table.
Example
prov-sta::srcver=active, dstver=myconf
prov-ed:name=SYS_CONFIG_STATIC, DtmfSupportedType="dtmf"
Table 3-15 presents important RAS parameters.
Table 3-15 Important RAS Parameters
Parameter Name
|
Parameter Value
|
Description
|
gateway.prefix[1]
gateway.prefix[2]
|
For example: 020
|
HSI prefix (for gatekeeper registration)
|
timeToLive
|
Integer (to specify number of seconds) for example, 45
Note To enable lightweight RRQs, the value for this parameter should be set substantially lower than the default (600).
|
RAS registration time to live.
See Table 3-7.
|
The following MML command example shows the command sequence used to provision the RAS parameters provided in the preceding table.
Example
prov-sta::srcver=active, dstver=myconf
prov-ed:name=RAS, timeToLive=45
Table 3-16 presents common H.245 parameters for enabling the G.729 codec.
Table 3-16 Common H.245 Parameters
Parameter Name
|
Parameter Value
|
chan[i].name
|
For example:
prov-add:name="H245",chan[4].name="g729"
|
chan[i].audio.g729
|
For example:
prov-add:name="H245",chan[4].audio.g729="2"
|
caps.table[i].audio.g729
|
For example:
prov-add:name="H245",caps.table[4].audio.g729="2"
|
caps.table[i].entryNo
|
For example:
prov-add:name="H245",caps.table[4].entryno="729"
|
modes[i].name
|
For example:
prov-add:name="H245",modes[3].name="g729"
|
modes[i].audio.g729
|
For example:
prov-add:name="H245",modes[3].audio.g729="3].audio.g729=""
|
The following MML command example shows the command sequence used to provision the H.245 parameters provided in the preceding table for enabling the G.729 codec. Provisioning the G.729 codec on the Cisco HSI supports passing SS7 calls to the Cisco CallManager through a gateway running the Media Gateway Control Protocol (MGCP).
Example
prov-sta::srcver="active",dstver="g729"
prov-add:name="H245",caps.table[4].audio.g729="2"
prov-add:name="H245",caps.table[4].entryno="729"
prov-add:name="H245",chan[4].audio.g729="2"
prov-add:name="H245",chan[4].name="g729"
prov-add:name="H245",modes[3].audio.g729=""
prov-add:name="H245",modes[3].name="g729"
HSI Feature Configuration
This section describes how to enable the following HSI features:
•
Asymmetric Codec Treatment
•
Empty Capability Set
•
H.323 Hairpin
•
T.38 Fax
•
H.225 Information Message Support
•
HSI Support for Tech Prefixes
•
H.323/SIP Interworking
•
HSI Notify Message Support
•
Adjustable Packetization
•
Carrier Code Mapping
•
Configuring Clear Channel on the Cisco HSI
•
Configuring G.726 on the Cisco HSI
•
Configuring G.729 Annex and G.729 Annex B
•
Using the Cisco HSI without a Gatekeeper (Non-RAS Mode)
•
H.323 Annex M.1 Support for Enhanced Interworking
•
Alternate Endpoints
Asymmetric Codec Treatment
The Asymmetric Codec Treatment feature averts the potential for inconsistencies in codec selection, which can result if the open channel requests are sent by each endpoint at nearly the same time, so that neither side has received an open channel request prior to sending one. In practice, such asymmetric conditions occur only for slow start calls. When there is a fast start recipient, both channels agree to use the same codec in unison.
The Asymmetric Codec Treatment support is enabled if this parameter is present and set to anything other than "". For example, support is enabled if the parameter is explicitly set to "Enabled." To enable Asymmetric Codec Treatment, enter the following command:
prov-add:name=sys_config_static, asymmetrichandlingsupported = "Enabled"
Empty Capability Set
The Empty Capability Set feature enables an H.323 endpoint to send a TCS message with empty capabilities during a call. The TCS message causes the audio channels to close. This action enables the negotiation and opening of new audio channels.
The Empty Capability Set feature is useful if the H.323 endpoint wishes to change the audio codec during a call or if the endpoint needs to divert the media streams to a different location. Typically, the feature is used to place a call on hold to disable the media stream until the user presses the Resume button.
The Empty Capability Set feature on the HSI requires no provisioning.
Note
The Empty Capability Set feature is supported by the MGCP software running on the Cisco PGW 2200, Release 9.4(1) and later releases. See the Release Notes for the Cisco Media Gateway Controller Software Release 9.4(1).
H.323 Hairpin
The H.323 Hairpin feature can be used to connect a call between two H.323 endpoints without the use of resources on the media gateway. For example, the PGW can respond to the dialed number in an incoming H.323 call by routing the call to another HSI (perhaps the same HSI) rather than routing the call to the PSTN. In this case, the originating and terminating HSIs establish the call normally but pass the H.245 address of the H.323 endpoints. This enables the two endpoints to use H.245 to negotiate media channels with each other directly, independent of the HSI.
The H.323 Hairpin feature on the HSI requires no provisioning. However, to operate throughout the system, H.323 Hairpin must be enabled on the PGW. On the PGW, you enable H.323 Hairpin through a trunk group property by issuing the following commands:
prov-add:trnkgrpprop:name="2000",AllowH323Hairpin="1"
prov-add:trnkgrpprop:name="3000",AllowH323Hairpin="1"
Note
H.323 Hairpin must be enabled for both the ingress and egress EISUP trunk groups.
Refer to Cisco PGW 2200 and Cisco IOS documentation at www.cisco.com for further information on these commands.
T.38 Fax
The T.38 Fax feature enables the HSI to alter a call, initially established for voice, to support a fax transmission.
When a fax call is initiated, a voice call is established. When the terminating gateway detects the fax tone generated by the terminating fax machine, the gateway initiates a T.38 mode request using H.245 procedures from the terminating gateway. If the opposite end of the call acknowledges the T.38 mode request, the initial audio channel is closed and a T.38 fax relay channel is opened.
You enable T.38 Fax for the HSI by specifying static system data parameters. By default, T.38 is provisioned on the HSI by use of the following commands:
prov-add:name=sys_config_static,t38maxval="MaxBit 0x90, FxMaxBuf 0xc8, FxMaxData 0x48"
prov-add:name=sys_config_static,t38options="FxFillBit 0, FxTransMMR 0, FxTransJBIG 0,
FxRate Trans, FxUdpEC Red"
Table 3-3 describes the T.38 static system parameters. The T.38 parameters for HSI correspond to T.38 parameters proposed in the ITU T.38 recommendation.
Configuring T.38 Fax on the Cisco PSTN Gateway
To enable T.38 Fax throughout the system, you must enable T.38 Fax on the Cisco PGW. On the PGW, T.38 is enabled through a trunk group property by use of the following MML command:
prov-add:trnkgrpprop:name="2000",FaxSupport="1"
Configuring T.38 Fax on a Cisco IOS H.323 Gateway
Enable T.38 Fax on a Cisco IOS H.323 gateway by issuing the following IOS commands:
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback none
Configuring T.38 Fax on a Cisco IOS MGCP Gateway
Enable T.38 fax on a Cisco IOS MGCP gateway by issuing the following IOS commands:
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback none
mgcp package-capability fxr-package
Refer to Cisco PGW 2200 and Cisco IOS documentation at www.cisco.com for further information on these commands.
H.225 Information Message Support
Cisco CallManager uses the H.225 Information message (ringback tone) during transfer to indicate that ringback tone is on or off. The Cisco HSI now supports this message to correctly interoperate with Cisco CallManager.
Support for the H.225 Information message is enabled by default. A craftsperson can disable H.255 Information message support through a new property called Information MsgDisabled by issuing the following MML command:
prov-add:name=sys_config_static,informationmsgdisabled = "True"
HSI Support for Tech Prefixes
The Cisco HSI now maps the "*" (asterisk, or star) and "#" (number sign, or hash) H.225 prefixes to the PGW for H.323 to PSTN calls as follows:
•
"*" to the value provisioned in ccpackage.Star.
•
"#" to the value provisioned in ccpackage.Hash.
•
The current value for ccpackage.Star is "B".
•
The current value for ccpackage.Hash is "A".
The craftsperson can change these values by issuing the following MML command:
prov-ed:name=ccpackage,hash='C'
Cisco HSI now maps the EISUP "B" to "*" and "C" to "#" (Called Party Number) for PSTN to H.323 calls.
H.323/SIP Interworking
H.323 to SIP and SIP to H.323 interworking supports calls between SIP and H.323 based networks, which are connected through the Cisco PGW 2200's SIP interface. Support for SIP was introduced in the Cisco PGW 9.6 release. No additional HSI configuration is needed to support this feature.
In addition, the HSI supports advanced SIP call flows (including call transfer and call divert) through the use of Annex M.1 functionality, when interworking with H.323 endpoints/gateways that support this, such as Cisco Call Manager. This additional functionality is only available with the Cisco PGW 9.7 release.
HSI Notify Message Support
Cisco Call Manager uses H.225 Notify messages during call transfer to indicate the transferees name and number information to the calling party. That is, when A calls B, and B transfers the call to C, the information about C is sent to A by means of the H.225 Notify message.
The HSI supports this message to correctly interoperate with Cisco Call Manager.
To enable this functionality, enter the following commands in an MML provisioning session:
prov-add:name=sys_config_static, NotifyMsgEnabled=enabled
For this functionality to be disabled, the NotifyMsgEnabled parameter entry must be deleted or set to "", as shown in the following example:
prov-ed:name=sys_config_static, NotifyMsgEnabled=""
Adjustable Packetization
The Cisco HSI enables adjusting the payload size while opening media channels. The HSI can reduce the packetization from its advertised value to the value advertised by the remote endpoint. Rather than reject calls, the HSI reduces payload size from what is configured in the HSI to what is proposed by the Terminal Capability Set (TCS) exchange. This is useful when interworking with endpoints that operate at different packetization sizes from the HSI configuration. It may not be desirable always to enable this feature (for example, if it is preferable for the VoIP network to maintain a consistent packet size, or if some endpoints/MGCP gateways cannot cope with receiving RTP payload sizes different from the payload size for which they are configured).
Note
Adjustable packetization does not affect H.323 to H.323 hairpin calls because the HSI is not involved in the negotiation of the codec and packetization through H.245.
Adjustable packetization enables the HSI to negotiate a packetization period that might differ from that provisioned on the Media Gateway. The codec packetization is asymmetric, which can cause problems with some endpoints.
Figure 3-1 illustrates how the HSI synchronizes the packetization value with a remote endpoint.
Figure 3-1 Synchronizing Packetization Values
Enabling Dynamic Packetization
The SYS_CONFIG_DYNAMIC parameter DynamicPacketizationSupported is used to enable this adjustable packetization feature.
To enable Dynamic Packetization Support, issue the following MML command:
prov-add:name=sys_config_dynamic, DynamicPacketizationSupported="enabled"
To disable this feature, delete this parameter or set it to blank ("").
Carrier Code Mapping
Carrier Code Mapping enables routing based on a prefix or carrier identifier. When the HSI receives a called party number with the format CCxCy from the PGW 2200 (in which C is the single overdecadic digit C and x is the single- or multiple-digit carrier code and y is the single- or multiple-digit destination number), the HSI can advise the gatekeeper of the carrier code.
Figure 3-2 illustrates how carrier code mapping works. In this illustration, the call is to 0800123456, and the PGW determines that it is destined to be completed by the carrier numbered 999.
Figure 3-2 Carrier Code Mapping
The HSI inserts y into the e164 destinationInfo field of the ARQ message and into the H.225 Setup message; it inserts x into the DestinationCircuitID group field in the ARQ message.
The dial plan on the PGW 2200 must be configured to perform the appropriate digit modification to prepend the carrier ID to the called party number in the special CCxCy carrier-code format.
To configure the Cisco HSI to perform carrier code mapping, issue the following MML commands:
prov-add:name=sys_config_static, CarrierCodeMapping="enabled"
Note
This feature works only with gatekeepers running Cisco IOS 12.2(15)T10 or above (for example, 12.3M or 12.3T). Please refer to the description of the zone circuit-id command in the Cisco IOS documentation.
Configuring Clear Channel on the Cisco HSI
The Clear Channel capability (identified as G.Clear or gclear in this document) enables support for both voice and data calls on a network. However, the end applications are responsible for packet loss and error recovery. For more information, refer to the document G.Clear, GSMFR, and G.726 Codecs and Modem and Fax Passthrough for Cisco Universal Gateways at http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00800b3568.html.
The Cisco HSI interoperates with Cisco voice gateways (for example, the Cisco AS54xx series or VISM), which advertise G.Clear capability via MGCP signaling using the following methods: G.Clear, G.nX64, CCD. The Cisco HSI automatically selects the correct method depending on the gateway that originates or terminates the call.
Table 3-17 presents examples of configuration commands that may be required to implement a particular G.Clear configuration.
Table 3-17 Configuring Clear Channel
Clear Channel Parameters
|
Example Value
|
Example Configuration
|
H245, caps.table[i].audio.gclear
|
"ClearChid"
Note The string "ClearChid" is case-sensitive; it must be entered exactly as displayed in all command examples in this table.
|
prov-add:name=h245, caps.table[9].audio.gclear="ClearChid"
prov-add:name=h245, caps.table[10].audio.gclear="ClearChid"
|
H245, caps.table[i].audio.entryNo
|
1010, 1011, 1012...
Note This parameter should be set to a unique integer value.
|
prov-add:name=h245, caps.table[9].entryNo=1010
prov-add:name=h245, caps.table[10].entryNo=1011
|
H245, chan[i].audio.gclear
|
"ClearChid"
|
prov-add:name=h245, chan[9].audio.gclear=ClearChid"
prov-add:name=h245, chan[10].audio.gclear="ClearChid"
|
H245, chan[i].name
|
"ClearChid"
|
prov-add:name=h245, chan[9].name="ClearChid"
prov-add:name=h245, chan[10].name="ClearChid"
|
H245, modes[i].audio.gclear
|
"ClearChid"
|
prov-add:name=h245, modes[9].audio.gclear="ClearChid"
prov-add:name=h245, modes[10].audio.gclear="ClearChid"
|
H245, modes[i].name
|
"ClearChid"
|
prov-add:name=h245, modes[9].name="ClearChid"
prov-add:name=h245, modes[10].name="ClearChid"
|
Configuring G.726 on the Cisco HSI
The G.726 codec enables transcoding a PCM channel to or from an ADPCM data stream. The standard supports four data rates:16, 24, 32 and 40 kbit/sec.
G.726 capability is advertised by the Cisco HSI and other H.323 gateways/endpoints in H.225 fast-start elements, in H.245 (tunneled or a separate TCP/IP connection) terminal capability (TCS) messages, and open logical channel (OLC) messages.
Currently, H.323 devices use several different methods to advertise G.726. ITU G.726 Annex B defines one method, referred to in this document as g726-generic. Cisco H.323 gateways (for example, the Cisco AS5400) support an alternate method referred to as g726-cisco. There is another method used by the OpenH323 project; however, the Cisco HSI does not support that method.
MGCP gateways advertise G.726 capability using the method described in RFC 3551 (RTP Profile for Audio and Video Conferences with Minimal Control). The four data rates use dynamic payloads; however, the 32kbit/sec data rate, alternatively, can have a static payload value of 2 (this alternative value is being phased out).
You can configure the Cisco HSI for 32kbit/sec MGCP support using dynamic or static payload values. In addition, you can configure the Cisco HSI to support g726-generic and/or g726-cisco for the H.323 signaling. If possible, it is best to select g726-cisco for your network because it offers additional flexibility.
The g726-generic method cannot indicate the data rate in H.245 TCS messages. The ITU standard specifies that the data rate is only advertised in the OLC messages.
Note
The H.245 ASN.1 syntax supports advertising the bitrate in TCS messages; however, G.726 Annex B prohibits advertising the bitrate in TCS messages. The Cisco HSI advertises the bitrate in the TCS messages as a "hint"; however, H.323 gateways/endpoints might not extract the field and take advantage of the presence of the bitrate in the TCS message.
The fact that the g726-generic method cannot indicate the data rate in an H.245 TCS message is not a problem if the MGCP gateway and your network are designed to support all data rates for this codec. However, if all data rates are not supported, it is possible for the remote endpoint/gateway to select a non-preferred or non-supported data rate in the OLC message.

Note
For example, a data-rate preference list may establish the following order: G.726-16kbit/sec (highest preference), G.711-Alaw (second preference), G.726-24kbit/sec (lowest preference). In this case, a remote endpoint could select G.726-24kbit/sec in the OLC message; whereas, the Cisco HSI would prefer G.726-16kbit/sec. In this example, the next preferred codec ought to be G.711 A-law and not G.726-24kbit/sec. However, the g726-generic limitation enables the remote endpoint to select the least preferred codec.
If a data-rate preference list specifies only a single rate (for example, G.726-16kbit/sec), it is not possible to advertise this fact in the TCS message. Subsequently, the remote endpoint may attempt to open the media stream using an unsupported data rate (perhaps, G.726-24kbit/sec).
Whenever OLC messages are exchanged and a non-supported G.726 data rate is detected, to prevent unnecessary call clearing, the Cisco HSI always attempts to send the data rate selection to the MGCP gateway. If the MGCP gateway does not support the selected data rate, it sends a message to the Cisco PGW to clear the call.
If a non-preferred G.726 data rate is selected over a higher-preference codec, the HSI continues with the call using the non-preferred data rate. This is preferable to the alternative (aborting the media stream, invoking an empty capability exchange followed by a re-negotiation of codecs and new OLC messaging). The alternative causes call processing delay and overhead associated with switching media streams.
Note
The g726-cisco method avoids impaired or delayed processing because it advertises the data rate in the TCS messaging.
Refer to the Cisco H.323 Signaling Interface User Guide for information about Cisco HSI MML commands.
Table 3-18 presents examples of configuration commands that may be required to implement a particular G.726 configuration.
Table 3-18 Configuring G.726
G.726 Parameter
|
Example Value
|
Configuration Example
|
Configuring the Payload Type for the MGCP
|
sys_config_static, UseG726StaticPayload
|
"enabled",
"true",
""
Note If this parameter is set to any text value, the Cisco HSI uses static payload value '2' to represent G.726 32kbit/sec to the MGCP gateway. If the parameter is deleted or is set to an empty string (""), the HSI uses the default, dynamic- payload behavior.
|
prov-add:name=sys_config_static, UseG726StaticPayload="enabled"
prov-ed:name=sys_config_static, UseG726StaticPayload=""
|
Configuring Cisco HSI g726-cisco
|
H245, caps.table[i].audio.g726-cisco
|
"G726r16",
"G726r24",
"G726r32",
"G726r40"
Note These string values are case-sensitive, and must be entered exactly as displayed in the commands in this table.
|
prov-add:name=h245, caps.table[5].audio.g726-cisco="G726r16"
prov-add:name=h245, caps.table[6].audio.g726-cisco="G726r24"
|
H245, caps.table[i].entryNo
|
7261, 7262, ...
Note Set this parameter to a unique integer value
|
prov-add:name=h245, caps.table[5].entryNo=7261
prov-add:name=h245, caps.table[6].entryNo=7262
|
H245, chan[i].audio.g726-cisco
|
"G726r16"
"G726r24"
"G726r32"
"G726r40"
|
prov-add:name=h245, chan[5].audio.g726-cisco="G726r16"
prov-add:name=h245, chan[6].audio.g726-cisco="G726r24"
|
H245, chan[i].name
|
"G726r16"
"G726r24"
"G726r32"
"G726r40"
|
prov-add:name=h245, chan[5].name="G726r16"
prov-add:name=h245, chan[6].name="G726r24"
|
H245, chan[i].audio.g726-cisco
|
"G726r16"
"G726r24"
"G726r32"
"G726r40"
|
prov-add:name=h245, chan[5].audio.g726-cisco="G726r16"
prov-add:name=h245, chan[6].audio.g726-cisco="G726r24"
|
H245, modes[i].audio.g726-cisco
|
"G726r16"
"G726r24"
"G726r32"
"G726r40"
|
prov-add:name=h245, modes[5].audio.g726-cisco="G726r16"
prov-add:name=h245, modes[6].audio.g726-cisco="G726r24"
|
H245, modes[i].name
|
"G726r16"
"G726r24"
"G726r32"
"G726r40"
|
prov-add:name=h245, modes[5].name="G726r16"
prov-add:name=h245, modes[6].name="G726r24"
|
Configuring Cisco HSI g726-generic
|
H245, caps.table[i].audio.g726-generic
|
"generic"
|
prov-add:name=h245, caps.table[7].audio.g726-generic="generic"
prov-add:name=h245, caps.table[8].audio.g726-generic="generic"
|
H245, caps.table[i].audio.g726-generic.bitOrder
|
1,2 or 3
Note This field is a bitmask of 8 bits, and can take any value from 0...255. Refer to G.726 Annex B, section B4.2 for a more detailed description. The value in this field must match the value advertised by the H.323 endpoint/ gateways.
|
prov-add:name=h245, caps.table[7].audio.g726-generic.bitOrder=2
prov-add:name=h245, caps.table[8].audio.g726-generic.bitOrder=3
|
H245, caps.table[i].audio.g726-generic.maxSPP
|
30, 40
Note This field is an integer value from 0...65535.
|
prov-add:name=h245, caps.table[7].audio.g726-generic.maxSPP=30
prov-add:name=h245, caps.table[8].audio.g726-generic.maxSPP=40
|
H245, caps.table[i].entryNo
|
7263, 7264
Note Set this parameter to a unique integer value.
|
prov-add:name=h245, caps.table[7].entryNo=7263
prov-add:name=h245, caps.table[8].entryNo=7264
|
H245, chan[i].audio.g726-generic
|
"generic"
|
prov-add:name=h245, chan[7].audio.g726-generic="generic"
prov-add:name=h245, chan[8].audio.g726-generic="generic"
|
H245, chan[i].audio.g726-generic.bitOrder
|
1,2 or 3
|
prov-add:name=h245, caps.table[7].audio.g726-generic.bitOrder=2
prov-add:name=h245, caps.table[8].audio.g726-generic.bitOrder=3
|
H245, chan[i].audio.g726-generic.maxSPP
|
30, 40
|
prov-add:name=h245, chan[7].audio.g726-generic.maxSPP=30
prov-add:name=h245, chan[8].audio.g726-generic.maxSPP=40
|
H245, chan[i].name
|
"g726-generic-16"
"g726-generic-24"
"g726-generic-32"
"g726-generic-40"
|
prov-add:name=h245, chan[7].name="g726-generic-16"
prov-add:name=h245, chan[8].name="g726-generic-24"
|
H245, modes[i].audio.g726-generic
|
"generic"
|
prov-add:name=h245, modes[7].audio.g726-generic="generic"
prov-add:name=h245, modes[8].audio.g726-generic="generic"
|
H245, modes[i].audio.g726-generic.bitOrder
|
1, 2 or 3
|
prov-add:name=h245, modes.table[7].audio.g726-generic.bitOrder=2
prov-add:name=h245, modes.table[8].audio.g726-generic.bitOrder=3
|
H245, modes[i].audio.g726-generic.maxSPP
|
30, 40
|
prov-add:name=h245, modes[7].audio.g726-generic.maxSPP=30
prov-add:name=h245, modes[8].audio.g726-generic.maxSPP=40
|
H245, modes[i].name
|
"g726-generic-16"
"g726-generic-24"
"g726-generic-32"
"g726-generic-40"
|
prov-add:name=h245, modes[7].name="g726-generic-16"
prov-add:name=h245, modes[8].name="g726-generic-24"
|
Configuring G.729 Annex and G.729 Annex B
Table 3-18 presents examples of configuration commands that may be required to implement a particular configuration of G.729 Annex A or G.729 Annex B.
Table 3-19 Configuring G.729 Annex A and G.729 Annex B
G.729 Parameter
|
Example Value
|
Example Configuration
|
H245,caps.table[i].audio.g729AnnexA
|
2, 3
|
prov-add:name=h245, caps.table[4].audio.g729AnnexA=2
prov-add:name=h245, caps.table[5].audio.g729AnnexB=3
|
H245,caps.table[i].entryNo
|
7290, 7291, 7292
|
prov-add:name=h245, caps.table[4].entryno=7290
prov-add:name=h245, caps.table[5].entryno=7291
prov-add:name=h245, caps.table[6].entryno=7292
|
H245,chan[i].name
|
"g729AnnexA"
"g729AnnexB"
|
prov-add:name=h245, chan[4].name="g729AnnexA"
prov-add:name=h245, chan[5].name="g729AnnexB"
|
H245,chan[i].audio.g729AnnexA
|
2, 3
|
prov-add:name=h245, chan[4].audio.g729AnnexA=2
prov-add:name=h245, chan[5].audio.g729AnnexB=3
|
H245,modes[i].name
|
"g729AnnexA"
"g729AnnexB"
|
prov-add:name=h245,modes[4].name="g729AnnexA"
prov-add:name=h245,modes[5].name="g729AnnexB"
|
H245,modes[i].audio.g729AnnexA
|
""
|
prov-add:name=h245, modes[4].audio.g729AnnexA=""
prov-add:name=h245, modes[5].audio.g729AnnexB=""
|
Using the Cisco HSI without a Gatekeeper (Non-RAS Mode)
The Non-RAS mode feature (using the HSI without a gatekeeper) of the Cisco Media Gateway Controller (MGC) software running on the Cisco PSTN Gateway (PGW) 2200 and Cisco H.323 Signaling Interface (HSI) enables service providers to create a simplified network without a gatekeeper, for networks that do not require gatekeeper features such as security.
In Non-RAS mode, the Cisco PGW 2200 converts called numbers into one or more IP addresses in the dial plan to support load sharing over multiple HSIs. This mechanism supports H.323 endpoints that have multiple IP addresses. With such support, when an initial IP address does not work, subsequent attempts are made to the alternative IP addresses for the same endpoint.
If the Cisco PGW 2200 sends an IP address to the HSI over EISUP, the HSI sends a H.225 Setup message directly to the endpoint. In addition, the Cisco PGW 2200 stores the H.323 Destination IP address in the Cisco PGW 2200's Call Detail Record (CDR).
Non-RAS mode enables deployment of a Cisco PGW 2200 with a connected Cisco HSI without a gatekeeper in networks that do not require admission, location of the H.323 endpoint, or when selection of the endpoint does not benefit from H.323 mechanisms such as Resource Availability Indication (RAI).
To enable the Non-RAS mode of operation on the Cisco HSI, the feature must also be enabled on the Cisco PGW 2200. Non-RAS Mode is supported by the Cisco PGW 2200 Release 9.7.
Note
A single Cisco H.323 Signaling Interface (HSI) cannot operate in both RAS and Non-RAS modes. If a network requires both modes of operation, the network must have multiple HSIs.
Enabling the NON-RAS Mode of Operation on the Cisco HSI
To enable Non-RAS mode on the Cisco HSI, enter the following MML command:
prov-add:name=RAS, manualRAS
Disabling the Non-RAS Mode of Operation on the Cisco HSI
To disable Non-RAS mode, enter the following MML command:
prov-dlt:name=RAS, manualRAS
H.323 Annex M.1 Support for Enhanced Interworking
The H.323 Annex M.1 support allows for enhanced service interoperability with H.323 networks which support this protocol, PBX protocols, and PSTN protocols or SIP.
To process Annex M.1 message content, the HSI maps the Annex M.1 message into an equivalent tunneled message within EISUP, which it delivers to the PGW 2200. You must provision this capability in the HSI for each direction (inbound and outbound). Support for Annex M.1 is advertised in the RRQ (registration request) and ARQ (admission request) to the gatekeeper, if configured.
Enabling Outbound H.323 Annex M.1 Support
To enable outbound QSIG tunneling, issue the following MML command:
mml>prov-add:name=sys_config_dynamic, EnableOutboundAnnexM1 ="enabled"
Enabling Inbound H.323 Annex M.1 Support
To enable reception of inbound tunneled QSIG, issue the following MML command:
mml>prov-add:name=sys_config_dynamic, EnableInboundAnnexM1 ="enabled"
Advertising H.323 Annex M.1 Support
To advertise Annex M.1 support to a gatekeeper, issue the following MML command:
mml>prov-add: name=sys_config_dynamic, IncludeAnnexM1inRRQ="enabled"
Additional H.323 Annex M.1 Parameters
To advertise Annex M.1 functionality in H.225 registrationRequest messages in the supportedTunnelledProtocols field, issue the following command in a provisioning session:
mml>prov-add: name=sys_config_dynamic, IncludeAnnexM1inRRQ="enabled"
To advertise Annex M.1 functionality in H.225 admissionRequest messages in the desiredTunnelledProtocol field, issue the following command in a provisioning session:
mml>prov-add: name=sys_config_dynamic, IncludeAnnexM1inARQ="enabled"
To transport Annex M.1 content in H.225 facility messages during overlap call establishment, issue the following command in a provisioning session:
mml>prov-add: name=sys_config_dynamic, SendAnnexM1inOverlapFacility="enabled"
If this parameter is not configured, the default action is to transport the Annex M.1 content during overlap call establishment in H.225 Information messages.
Alternate Endpoints
The Alternate Endpoints feature enables the Cisco HSI, connected to a Cisco PGW 2200, to support call routing in response to alternateEndpoint fields in RAS admissionConfirm messages sent from an H.323 gatekeeper. The support of Alternate Endpoints enables the PGW 2200 to attempt to route a call to an alternative endpoint when connection to an initial endpoint fails. The PGW 2200 attempts to connect to alternate endpoints through a sequence of endpoints according to an established priority order. Support of alternate endpoints is important for Wholesale VoIP carriers, which have several choices for routing calls based on criteria such as voice quality or least cost.
Note
Support of the Alternate Endpoints feature requires Cisco PGW 2200 Release 9.7. In addition, the H.323 gatekeeper must be running Cisco IOS 12.2(11)T or a later release of Cisco IOS.
A gateway operating the H.323 protocol determines the need to use an H.323 alternate endpoint when one of the following circumstances occurs:
•
An attempted H.225 TCP Connection to the destination gateway fails or times out.
•
A response to an H.225 Setup message never arrives and the timer expires.
•
The gateway receives a ReleaseComplete message either as a response to an H.225 Setup or after receiving a CallProceeding message.
Note
If the Cisco HSI receives an H.225 releaseComplete message after it receives an H.225 alerting, progress, or connect message, it does not attempt to route the call via an alternate endpoint.
To support Alternate Endpoints the Cisco HSI operates according to the following requirements:
•
The HSI decodes the alternate endpoints field in RAS admissionConfirm messages received from a gatekeeper. There might be as many as 10 alternate endpoints defined in an alternate-endpoints list.
•
The HSI attempts to establish a TCP/IP connection (for H.225) to the primary destination and then to alternate destinations according to the defined sequence.
•
When a TCP/IP connection is established, the HSI sends an H.225 Setup message to the destination. If the HSI establishes the connection to an alternate endpoint, the Setup message contains a called party number based on the destination number in the alternateEndpoints field.
•
If the HSI does not receive a response to an H.225 Setup message, after a specified interval, it releases the call and attempts a connection using the destination IP address/port and called-party number defined by the next alternate endpoint.
•
If the HSI receives an H.225 releaseComplete message that includes the cause code "No route to destination," the HSI releases the call and attempts a connection using the destination IP address/port and called-party number defined by the next alternate endpoint.
Configuring the Alternate Endpoints Feature
To enable the Alternate Endpoints feature on the Cisco HSI, the following parameters are available:
•
SYS_CONFIG_STATIC AltEpSupported
•
SYS_CONFIG_STATIC AltEpUseAliasAddr
•
SYS_CONFIG_STATIC AltEpCauseAllowed
•
SYS_CONFIG_STATIC AltEpCauseDisallowed
•
SYS_CONFIG_DYNAMIC AltEpGkXlateCdpnToRadius
Configuring AltEpSupported
If the AltEpSupported parameter is set to any text value (for example, "enabled" or "true"), the HSI enables the Alternate Endpoints feature.
If this parameter is set to any text value (for example, "enabled" or "true"), the HSI enables the functionality.
If the parameter is deleted or set to blank (""), the feature is disabled.
Example:
prov-add:name=sys_config_static, AltEpSupported="enabled"
Configuring AltEpUseAliasAddr
If the AltEpUseAliasAddr parameter is set to any text value (for example, "enabled" or "true"), the HSI uses the aliasAddress value in the alternateEndpoints field (from the gatekeeper registrationConfirm message), and modifies the called-party number and destinationAddress in the outgoing setup message accordingly.
The parameter AltEpUseAliasAddr is a static system parameter that is configured in the HSI configuration file GWmain.conf.
If this parameter is set to any text value (for example, "enabled" or "true"), the HSI uses the aliasAddress value in the alternateEndpoints field, and modifies the called-party number and destinationAddress in the outgoing Setup message.
If the parameter is deleted or set to blank (""), the HSI does not modify the called party number and destinationAddress.
Example:
prov-add:name=sys_config_static, AltEpUseAliasAddr="enabled"
Configuring AltEpCauseAllowed or AltEpCauseDisallowed
The parameters AltEpCauseAllowed and AltEpCauseDisallowed are static system parameters that are configured in the HSI configuration file GWmain.conf.
These parameters enable defining the cause codes that invoke or do not invoke the alternate endpoints feature behavior. Only one of these two parameters should be configured.
These parameters are configured as a string of cause codes. By default, these parameters are absent or set to zero. You can set these parameter to any value in the Q.850 specification (range [1-127]).
If the HSI receives a releaseComplete message with no Q.850 cause code (the Q.850 cause code is optional in H.323 releaseComplete messages), the HSI does not attempt any alternate endpoint that was present in the admissionConfirm (ACF) message. The HSI releases the call.
The HSI never attempts alternate endpoints if it receives cause codes 16=Normal call clearing or 17=User busy.
Example 1:
The following example command determines that the HSI attempts alternate endpoints only in response to cause code 38=Network out of order or 42=Switching equipment congestion. The HSI releases the call for all other cause codes.
Prov-add:name=sys_config_static, AltEpCauseAllowed="38 42"
Example 2:
The following example command determines that the HSI attempts alternate endpoints for all cause codes except 1=Unallocated number (and cause codes 16, and 17, which are hard-coded internally within the HSI).
Prov-add:name=sys_config_static, AltEpCauseDisallowed="1"
Per Call Support for the G.723.1 Codec
For releases of the Cisco HSI prior to HSI 4.3 Patch 5, the silence suppression field of the G.723.1 codec was provisioned for all calls, which could cause problems for some IP-IP gateways because IP-IP gateways check the suppression parameter strictly for every call.
HSI 4.3 Patch 5 enabled the HSI to support dynamic G.723.1 codecs on a per-call basis. For the Session Description Protocol (SDP), the HSI supports the following G.723.1 dynamic payload values:
•
G.723.1-H/8000 (7)
•
G.723.1-L/8000 (8)
•
G.723.1a-H/8000 (9)
•
G.723.1a-L/8000 (10)
In the preceding list, the HSI processes the codecs G.723.1-H/8000 and G.723.1-L/8000 as G.723.1 without silence suppression. The HSI processes codecs G.723.1a-H/8000 and G.723.1a-L/8000 as G.723.1 with silence suppression enabled.
If your HSI configuration has 6 codecs configured before you attempt to enable this enhancement, start the enumeration of the payload types for the new codecs with the value 7, as shown in the following example:
* SYS_CONFIG_STATIC.G7231DynCodecSupported = enabled
* SYS_CONFIG_DYNAMIC.UsePayloadTypeMapping = true
* h245.caps.table[7].audio.g7231-dyn.maxAudioFrames = 1
* h245.caps.table[7].audio.g7231-dyn.silencesuppression = 0
* h245.caps.table[7].entryNo = 72311
* h245.caps.table[8].audio.g7231a-dyn.maxAudioFrames = 1
* h245.caps.table[8].audio.g7231a-dyn.silencesuppression = 1
* h245.caps.table[8].entryNo = 72312
* h245.chan[7].audio.g7231-dyn.maxAudioFrames = 1
* h245.chan[7].audio.g7231-dyn.silencesuppression = 0
* h245.chan[7].name = g7231-dyn
* h245.chan[8].audio.g7231a-dyn.maxAudioFrames = 1
* h245.chan[8].audio.g7231a-dyn.silencesuppression = 1
* h245.chan[8].name = g7231a-dyn
* h245.modes[7].audio.g7231-dyn = NULL
* h245.modes[7].name = g7231-dyn
* h245.modes[8].audio.g7231a-dyn = NULL
* h245.modes[8].name = g7231a-dyn
Note
Enabling this feature automatically disables the static payload type support of the G.723.1 codec (payload = 4). Cisco HSI customers can modify the value of maxAudioFrames to suit particular needs; however, the value of silencesuppression should not be modified for these two dynamic codecs.