Downloads |
 Feedback
|
Table Of Contents
Precedence Rules for Location Label Use
Location Label Handling During Rerouting
Location Label Handling During Service Actions
Removing and Adding Location Labels
Enabling or Disabling Call Limiting
System Actions at the Start of Call Handling
System Actions with INAP Calls
Normal Basic INAP CS1 Call with Call Limiting Rejection
Call Processing with Location Labels
Call Limiting Check with Location Labels Present, Call Permitted
Call Limiting Check with no Location Label Data Present
Call Limiting Check with Location Labels Present, Call Rejected
Prerequisites for Using This Feature
XECfgParm.dat Configuration Tasks
Verifying the XECfgParm.dat Configuration
Enabling the Call Limiting Functions
Enabling the Call Limiting Control Parameter the First Time
Dynamically Enabling Call Limiting
Dynamically Disabling Call Limiting
Modifying Call Limiting Components
Deleting Call Limiting Components
Applying Call Limiting Over DPNSS
Applying Call Limiting to Incoming and Outgoing Trunk Groups
B-number Based Call Limiting Scenario
Applying Call Limiting to a SIP Trunk Group
Applying Call Limiting to an H.323 Trunk Group
Applying Call Limiting to the DPNSS Trunk Groups
Applying Call Limiting to an SS7 ISUP Trunk Group
Applying Call Limiting to Digit Strings in a Dial Plan
Applying Call Limiting to Multiple Trunk Groups
Applying Call Limiting to IP Addresses
Applying Call Limiting to an MGCP Gateway
Playing an Announcement when the Call Limiting Threshold is Exceeded
Provisioning Call Limiting for an A-number
Provisioning Call Limiting for a B-number
Provisioning the OVERRIDE_CALLIM Result Type for Number Analysis
Troubleshooting Provisioning Data
Alarm Troubleshooting Procedures
SET-CALLIM—Sets the Call Limiting Function
RTRV-CALLIM—Retrieves the Call Limiting Function Status
PROV-ADD:LOCLABEL—Adds the Location Label
PROV-DLT:loclabel—Deletes the Location Label
PROV-ED:loclabel—Edits the Location Label
PROV-RTRV:loclabel—Retrieves the Location Label
Rejecting Location Label (Tag: 4232)
Rejecting Location Label Direction (Tag: 4233)
Monitoring and Maintaining the Feature
Obtaining Documentation and Submitting a Service Request
Call Limiting
Document Release History
Feature History
This document describes the Call Limiting feature in the following sections:
•
Prerequisites for Using This Feature
•
•
•
•
Feature Overview
The Call Limiting feature on the Cisco Media Gateway Controller (MGC) allows a service provider to limit the number of simultaneous calls across telephony interfaces. The telephony interfaces include SS7, Session Initiation Protocol (SIP), H.323, ISDN User Part (ISUP), E-ISUP, DPNSS, QSIG, and PRI. Call Limiting allows the service provider to limit calls for quality purposes (for example, bandwidth limitations) or to limit the number of simultaneous calls to a total agreed upon by the service provider and its customers.
Through the use of as many as 3000 location labels, the Call Limiting feature enables the MGC to limit the number of simultaneous calls sent to or accepted from a specific destination or source. This includes calls made to a Public Switched Telephone Network (PSTN) E.164 number, or a specified SIP device, H.323 device, a route to DPNSS, QSIG, or PRI gateway, as well another MGC or an HSI using E-ISUP.
Emergency and priority calls can be permitted, even though a call limit might have been reached. The OVERRIDE_CALLIM result type makes that possible. It may also be necessary to allow calls from a certain origin to have priority and avoid call limiting actions. The presence of the OVERRIDE_CALLIM result type indicates that for such calls, any call limiting actions are ignored and the call is allowed to set up as soon as possible.
The Call Limiting feature uses a location label concept. A location is a label associated with one or more sources and destinations, so calls can be limited to or from one or more interfaces. As many as 4 location labels can be applied to a call, with two location labels on the inbound call leg and two location labels on the outbound call leg.
The location label has a call threshold limit that can be set. Once the call threshold for a location is exceeded, all other calls to or from that location are rejected.
Call limit counters are incremented on the incoming and outgoing call sides after successful outgoing circuit selection and are decremented at call release.
Note
The same label identifier can be assigned to single or multiple instances of:
•
•
Precedence Rules for Location Label Use
The incoming call leg can use two separate location labels, one label assigned to the incoming trunk group or sigPath and one label assigned during the A-number analysis phase in the dial plan.
If there are multiple instances of a result type, the analysis location label used is the last location label result type encountered in A-number analysis.
Similarly, the outgoing call leg can also use two separate location labels, one assigned to the outgoing trunk group or sigPath and one returned during B-number analysis. The B-number analysis location label is the last found label result type encountered during the B-number analysis process.
Location Label Handling During Rerouting
If a call undergoes rerouting, the incoming call leg limit counter is unaffected. However, both the B-number analysis delivered counter (if present) and the outgoing call leg limited counter are decremented. A new label check is performed (against both the B-number label and the new outgoing call leg label) at the end of the subsequent route analysis. If the call is permitted on this new attempt, both the B-number analysis delivered counter (if present) and the outgoing call leg limited counter are incremented.
Location Label Handling During Service Actions
When the call instance is handling a call with service layer actions involved could result in a new trunk group. For example, if route optimization or call back when free is enabled, then an existing terminating call control (TCC) or originating call control (OCC) call leg could be disconnected, making way for a half-leg call or reconnection to a new OCC or TCC side, resulting in a new trunk group. For call limiting to be permitted, the call limiting actions are performed at a level outside of any service layer controls. Thus the call limiting actions are driven by incoming call requests and outgoing call attempts, regardless of any higher level service actions that provoked them. If a call leg is deleted, the call limit counters are decremented and the label discarded. And if a new call leg is set up, the call limiting actions apply when the outgoing call is attempted on the new call leg.
When call legs are deleted, any location labels associated with that call leg side and any number analysis location labels (if present) have their active call counters decremented. Thus:
•
•
Location Label Provisioning
Provision a location label by using the MML command for every label defined on the system and its associated call limit.
Once provisioning is complete, the label data is assigned to a trunk group or sigPath, where it appears as new columns in trunkGroups.dat or sigPath.dat as appropriate.
If the location labels are required as a result of A-number or B-number analysis, the associated MML provisioning commands populate the dial plan with the LOC_LABEL result type. This result type provides the componentId that is used to identify the location label.
Removing and Adding Location Labels
Location labels can be added and removed at any time, but are subject to the following conditions:
•
•
•
Enabling or Disabling Call Limiting
The call limiting feature is started the first time when you set the XECfgParm.dat parameter CallLimitingControl to enable. Once the call limiting capability is enabled, you can enable or disable it by using the set-callim MML command without stopping and starting the MGC software.
Additionally, if the XECfgParm.dat parameter CallLimitingControl is set to disable, once the MGC is running, you can enable the call limiting functionality by using the set-callim:enable MML command. Thus the call limiting functionality can be enabled or disabled through the set-callim MML command regardless of the initial value of CallLimitingControl.
System Actions at Start Up
Once the system starts up, the locationLabel.dat file is read and a table is built in local memory containing the following fields for each label:
•
•
•
System Actions at the Start of Call Handling
At the start of every call instance, the MGC verifies the CallLimitingControl parameter value (which is the value of call limiting for the whole platform), or the set-callim MML command value.
System Actions at Switchover
In the event of switchover for active to standby MGCs, there is no preservation of call limiting data. As a result, when the standby MGC is started, the location label table is rebuilt with all counters starting from 0.
When the existing calls are restarted on the newly active (formerly the standby side), call limiting is set to off for these calls, so that any counter corruption during failover is avoided.
System Actions with INAP Calls
When the MGC is handling a call involving Intelligent Network Application Protocol (INAP) Capability Set 1 (CS1) interchanges with a Service Control Point (SCP), call limiting can still be used. Thus, when a call is ready to go forward on the terminating side of the MGC, a call limiting check is applied with all involved labels at this point in the call. At call answer, the successful call measurement counters are incremented; and at call release, the active call counters are decremented.
The call-counter action co-exists with any event reporting to the SCP, as required in normal INAP CS1-related call handling.
Normal Basic INAP CS1 Call with Call Limiting Rejection
At the point when the call to the MGC terminating side is to be forwarded, the call limiting check is applied. If the call is rejected, then the action taken depends on the monitoring mode for the route select failure event. The monitoring modes for a route select failure event are:
•
•
Monitor Mode Is Interrupted
An event report (route select failure) is made to the SCP and a response is awaited, because the SCP must supply further instructions. The SCP responds with one of the following:
•
•
Monitor Mode Is Notify and Continue
An event report (route select failure) is made to the SCP; but as is the case with Notify mode, there is no need to wait for an SCP response. As a result, the action taken depends on whether or not further routing options (routes and trunk groups) are available in analysis. Either of the following actions can apply:
•
•
Call Processing with Location Labels
The processing of location labels is integrated into normal call handling and is broken down into specific activities according to the point in the call.
At the point in a call where analysis has been carried out and before the call is sent to the terminating (TCC) side, a check is performed of the location label (if present) for the originating side, terminating side, any A-number analysis delivered label, and any B-number analysis delivered label. At this point, the call can be rejected, permitted, or released; and the call actions are summarized as follows:
•
•
•
•
Call Limiting Check with Location Labels Present, Call Permitted
Normal call handling takes place up to the point when a call is made to Generic analysis for A-number or B-number analysis and Routing analysis. On switched calls, a routing result from B-number analysis occurs, and the analysis continues with the Routing analysis stage. After that, if a call is successful, analysis returns a trunk group and optional data results back to the Universal Call Model (UCM) module. On signaling (that is, nailed) calls, an indication of analysis performed from Generic analysis is returned, along with any optional data results. In each case, the optional data results include any LOC_LABEL results that have been collected.
In both A-number and B-number analysis, the LOC_LABEL result type can be collected and stored.
Call Limiting Check with no Location Label Data Present
When the engine is making the post-analysis, call limiting request, where no location labels have been found in A-number or B-number analysis, there is no data input. For the engine to determine if any location labels are present for the originating or terminating sides, the trunkGroup.dat or sigPath.dat files (as appropriate) are read. If no labels are found against either side, then the call is permitted, and no originating or terminating label parameters are populated.
Also, if call limiting is disabled, no further call limiting actions are taken for this call. If there is no call limiting action required for this call, the call is processed normally. No further call limiting counter update requests by the engine are invoked because there is no location label data.
Call Limiting Check with Location Labels Present, Call Rejected
The call can be rejected for call limiting when the engine is checking against the labels found for the originating side, terminating side, or as a result of A-number or B-number analysis. This check is made when the UCM is preparing to start sending to the TCC side.
The originating and terminating sides are checked by the engine for location labels by reading the trunkGroup.dat or sigPath.dat data files, as appropriate. Any defined location labels are collected to determine the call viability with respect to the location labels. The order of location label checking performed by the engine is origSideLabel, A-number label, B-number label, and termSideLabel. The first label to reject is the label returned and saved for CDR purposes. If a label is present against both the sigPath and the trunk group, the trunk group label is the label used and checked against.
With one or more location labels present, the Engine validates the call according to the current active call counter level for each label present. This is done by a reading of the internal table. For each label found, the Engine checks that the new call request does not put the value in the active call counter field over its limit. For example, if the call limit is set to 100, call number 99 and call 100 are allowed. But call attempt 101 is rejected.
If a new call request would cause the value in the active call counter field to be exceeded a rejection result is returned, accompanied by both the location label componentId and the location label string (not the componentId) of the label that caused the rejection. When the Engine receives this information, the rejecting location label name is captured for later CDR use by saving the rejecting label name into call context.
A rejected call can be referred by the UCM for Cause analysis, which can return a result that provokes rerouting or a reattempt. The routing or reattempt is allowed, as long as the label rejection was against the terminating side trunk group or sigPath. If any other label caused the rejection, then the result is ignored and call clear down continues. If Cause analysis does deliver a routing result (or maybe a dial plan change leading to a routing result), then (providing this is an allowed action) the call is handled as normal. But once again when preparing to send to the TCC side, the B-number analysis location label and terminating side label are checked by the Engine.
Once a rejection has been detected, the rejecting label measurement counter for the rejecting label is incremented.
Note
Once clearing is completed for each side, the identity (name string) of the rejecting location label is saved for use in CDR collection.
Benefits
This feature provides the following main benefit areas.
Improved Network Planning
The service provider can better plan the IP network by limiting the number of calls.
Improved QoS for Permitted Calls
The service provider can ensure a better QoS for the calls that are allowed by not allowing bandwidth allocation to be exceeded.
Improved Contractual Control
The service provider can control the number of calls that are contractually allowed to/from a certain destination/origination. A service provider can then charge for each simultaneous call allowed on a certain IP link.
Improved Device Allocating
Certain devices support only a limited number of calls, for example an IP-based announcement device. Once the device limit is reached, the MGC can select a route to another IP-based announcement device.
Related Documents
This document contains information that is related strictly to this feature. The documents that contain additional information related to the Cisco MGC are listed below:
•
•
•
•
•
•
•
•
•
•
•
•
Supported Platforms
The hardware platforms supported for the Cisco MGC software Release 9.6(1) are described in the Cisco Media Gateway Controller Hardware Installation Guide.
No new standards, MIBs, or RFCs are supported by the Call Limiting feature.
Prerequisites for Using This Feature
You must have Cisco MGC software Release 9.6(1). Prerequisites for this release can be found in the Release Notes for Cisco Media Gateway Controller Software Release 9.6(1).
XECfgParm.dat Configuration Tasks
This section presents the steps necessary for configuration of the Cisco MGC software to support this feature. If you are installing and configuring the Cisco MGC software on your system for the first time, use the procedures in the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide, coming back to this section once you encounter the engine.CallLimitingControl parameter in the XECfgParm.dat file.
Caution
Caution
To enable Call Limiting control on the MGC, perform the following steps:
Step 1
Step 2
Step 3
Verifying the XECfgParm.dat Configuration
Use the procedure below if you believe the Call Limiting feature value you have entered in XECfgParm.dat is incorrect. For more information on troubleshooting the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.
To verify the XECfgParm.dat setting for the Call Limiting feature, perform the following steps.
Caution
Step 1
cd /opt/CiscoMGC/etcStep 2
Step 3
Step 4
Step 5
/etc/init.d/CiscoMGC stopStep 6
/etc/init.d/CiscoMGC startStep 7
mml> sw-over::confirmSite alarms are automatically set until the out-of-service (OOS) Cisco MGC host is returned to an in-service (IS) state.
Step 8
Provisioning Tasks
The Call Limiting feature can be provisioned on:
•
•
•
•
The following sections describe the MGC provisioning related to this feature:
•
•
If you are not familiar with provisioning the MGC, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide for more information on MGC provisioning. If you are already familiar with MGC provisioning, you may refer to the "Dynamically Enabling Call Limiting" section to begin provisioning the Call Limiting feature.
Enabling the Call Limiting Functions
This section contains the procedures that you must perform to enable the Call Limiting feature on your Cisco MGC. When provisioning the components that enable the Cisco MGC to support Call Limiting, perform the procedures in the following order:
•
•
•
Enabling the Call Limiting Control Parameter the First Time
When enabling the Call Limiting feature for the first time, you change the CallLimitingControl parameter setting in the XECfgParm.dat file. To do this, perform the following procedure.
If you have already enabled the Call Limiting feature, you can go to "Dynamically Enabling Call Limiting" section.
Caution
Step 1
cd /opt/CiscoMGC/etcStep 2
Step 3
Step 4
Step 5
Step 6
/etc/init.d/CiscoMGC stopThis action disables the automated startup script.
Step 7
/etc/init.d/CiscoMGC startStep 8
mml> sw-over::confirmSite alarms are automatically set until the out-of-service (OOS) Cisco MGC host is returned to an in-service (IS) state.
Caution
Step 9
Dynamically Enabling Call Limiting
Once the Call Limiting feature has been enabled in XECfgparm.dat, you can dynamically change the feature status.
After you have dynamically disabled call limiting, while the MGC is running, you can also reenable this feature. To enable the Call Limiting feature while the MGC is running, use the set-callim MML command to set its property value to enable. This action allows safe clear-down of existing calls, but it does not corrupt the label counter values.
Once the MML command to enable call limiting is executed, all new calls are processed according to the call limiting settings for each call (counters initially starting from 0).
For calls in progress before restarting call limiting, no counters are decremented. At the start of a call for which call limiting is active, the MGC saves a checksum value; and if the call limiting status changes during a call, then the checksum value is updated. When the call is to be cleared, first the call limiting functionality is checked. If the parameter is enabled, then the MGC compares the original checksum value with the current checksum value. If the values are different, the counters are not decremented.
Use the following step to enable call limiting:
Step 1
mml> set-callim:enable
Adding a Location Label
To add a location label, perform the following steps:
Step 1
mml> prov-sta::srcver="callim1",dstver="callim2"Step 2
mml> prov-add:loclabel:name="loclbl1",desc="local label 1",calllimit=25mml> prov-add:loclabel:name="loclbl2",desc="local label 2",calllimit=60Step 3
Step 4
Dynamically Disabling Call Limiting
Once the Call Limiting feature has been enabled in XECfgparm.dat, you can dynamically disable the feature status.
To dynamically disable call limiting while the MGC is still running, use the set-callim MML command to toggle the value to 0 (disable).
When this command is entered to disable call limiting, the MGC also resets the active call counters for all labels to 0.
From a call processing point of view, once the set-callim MML command is executed, all new calls that deal with a call limiting request are trapped, and an indication that call limiting is disabled is returned. For calls already in progress when call limiting is disabled, no counters are decremented (as they are all reset to 0 in readiness for the call limiting re-start). Not decrementing counters allows existing calls with labels to clear down normally.
Perform the following step to disable call limiting:
Step 1
mml> set-callim:disable
Modifying Call Limiting Components
The following section contains the procedures for modifying the call limiting location label in your Cisco MGC provisioning data:
Modifying a Label Call Limit
To add a label call limit, perform the following steps:
Step 1
Step 2
mml> prov-add:loclabel:name="locationlabel01",calllimit=10Where:
•
•
For example, to modify a label named locationlabel01 by setting its call limit to 100, which was previously set to 10, enter the following MML command:
mml> prov-ed:loclabel:name="locationlabel01",calllimit=100
Note
mml> prov-ed:loclabel:name="locationlabel01",call limit=99999999
A value of 99999999 for the call limit causes the associated location label to be ignored when the MGC performs validation during call processing.Step 3
mml> prov-rtrv:loclabel:name="locationlabel01"or verify all labels by using the following MML command:
mml> prov-rtrv:loclabel:allStep 4
Step 5
Retrieving Location Labels
To retrieve location labels, perform one or more of the following steps:
Step 1
prov-rtrv:loclabel:name="loclbl1"Step 2
or
Step 3
prov-rtrv:loclabel:allor
Step 4
prov-rtrv:loclabel:name="loc-1","comp"The result returned is:
MGC-01 - Media Gateway Controller 2005-06-01 13:11:39.353 EDTM RTRV"session=test:loclabel"/*Components----------ss7svc1tg-1000tg-2000*/
Deleting Call Limiting Components
The following section contains the procedure for deleting call limit location labels in your Cisco MGC provisioning data:
Note
A location label cannot be deleted when there are calls associated with it. The prov-dlt command is rejected with the message This Label is in use by calls in the system. Ensure there is no call using this label displayed if such action is attempted.
mml> prov-dlt:loclabel:name="loclbl2"MGC-01 - Media Gateway Controller 2005-04-02 17:02:47.393 PSTM DENYSROF"loclabel:loclbl2:Can not be removed. It is referenced by sigPath"/* Status, Requested Operation Failed on the component */;mml> prov-dlt:loclabel:name="loclbl3"MGC-01 - Media Gateway Controller 2005-04-02 15:26:32.274 PSTM DENYSROF"loclabel:loclbl3:Can not be removed. It is referenced by trunkGroup"/* Status, Requested Operation Failed on the component */;Provisioning Examples
This section provides a provisioning example for this feature. Additional provisioning examples for the Cisco MGC software can be found in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
The following MML commands were used to provision example location labels at sigPath and trunk group levels and is the first provisioning session started on the MGC:
Caution
prov-stpprov-sta::srcver="new",dstver="ver1"prov-add:loclabel:name="loclbl1",desc="local label 1",calllimit=2345prov-add:loclabel:name="loclbl2",desc="local label 2",calllimit=6000prov-rtrv:loclabel:name="loclbl1"prov-rtrv:loclabel:name="loclbl2"prov-rtrv:loclabel:"all"locationLabel.dat005f0001 2345005f0002 6000prov-add:OPC:NAME="opc",DESC="The PGW point code",NETADDR="1.1.1",NETIND=2,TYPE="TRUEOPC"prov-add:DPC:NAME="dpc1",DESC="Orig. point code",NETADDR="2.2.2",NETIND=2prov-add:DPC:NAME="dpc2",DESC="Dest. point code",NETADDR="3.3.3",NETIND=2prov-add:EXTNODE:NAME="dpnss-gw1",DESC="nas 2600 Backhaul",TYPE="C2600", ISDNSIGTYPE="IUA",GROUP=0prov-add:EXTNODE:NAME="eisup1",DESC="external node - eisup",TYPE="MGC", ISDNSIGTYPE="N/A",GROUP=0prov-add:EXTNODE:NAME="ipfas1",DESC="external node - ipfas",TYPE="C2600", ISDNSIGTYPE="N/A",GROUP=0prov-add:EXTNODE:NAME="ss7sg1",DESC="external node - ss7sg",TYPE="TALISS7", ISDNSIGTYPE="N/A",GROUP=0prov-add:SS7PATH:NAME="ss7svc1",DESC="SS7 service to DPC-2-2-2",MDO="ANSISS7_STANDARD", CUSTGRPID="1111",SIDE="network",DPC="dpc1",OPC="opc",M3UAKEY="",ORIGLABEL="loclbl1", TERMLABEL="loclbl2"prov-add:DPNSSPATH:NAME="dpnss1",DESC="backhaul to nas2600",EXTNODE="dpnss-gw1", MDO="DPNSS_BTNR188",CUSTGRPID="1111",SIGSLOT=2,SIGPORT=1,ORIGLABEL="loclbl1", TERMLABEL="loclbl2"prov-add:EISUPPATH:NAME="eisup-mgc01",DESC="signal service - mgc",EXTNODE="eisup1", CUSTGRPID="1111",ORIGLABEL="loclbl1",TERMLABEL="loclbl2"prov-add:ipfaspath:name="ipfas-sigpath",mdo="dummy",desc="IPFAS sigpath",EXTNODE="ipfas1", ORIGLABEL="loclbl1",TERMLABEL="loclbl2"prov-add:SGNode:NAME="sgnode1",TYPE="TALISS7"prov-add:SGNode:NAME="sgnode2",TYPE="TALISS7"prov-add:SGPair:NAME="sgpair1",SGNODE="sgnode1",MATEDSGNODE="sgnode2"prov-add:ss7sgpath:name="ss7sg-sigpath",mdo="ANSISS7_STANDARD",desc="SS7SGP sigpath", CUSTGRPID="1111",SIDE="network",DPC="dpc2",OPC="opc",SGPAIR="sgpair1", ORIGLABEL="loclbl1",TERMLABEL="loclbl2"prov-add:sippath:name="sip-sigpath",mdo="IETF_SIP",desc="SIP sigpath",ORIGLABEL="loclbl1", TERMLABEL="loclbl2"prov-rtrv:sippath:name="sip-path"MGC-2 - Media Gateway Controller 2005-07-06 16:22:32.107 EDTM RTRV"session=egw-2:sippath"/*NAME = sip-pathDESC = sip pathMDO = IETF_SIPORIGLABEL =TERMLABEL =*/;sigPath.dat00150001 SS7-ANSI ANSISS7_STANDARD 1111 0101 0 network n 2 00130002 00130001 00000000 00000000 0 005f0001 005f000200190001 EISUP EISUP 0000 0101 0 network n 2 00000000 00000000 00000000 00000000 0 005f0001 005f000200340001 dummy 0000 0101 0 network n 2 00000000 00000000 00000000 00000000 0 005f0001 005f0002003e0001 SIP IETF_SIP 0000 0101 0 network n 2 00000000 00000000 00000000 00000000 0 005f0001 005f000200420001 SS7-ANSI ANSISS7_STANDARD 1111 0101 0 network n 2 00130003 00130001 00410001 00000000 0 005f0001 005f000200550001 DPNSS DPNSS_BTNR188 1111 0101 26 network n 2 00000000 00000000 00000000 00000000 513 005f0001 005f0002prov-add:trnkgrp:name="3000",svc="sip-sigpath",type="SIP_IN",ORIGLABEL="loclbl1", TERMLABEL="loclbl2",selSeq="LIDL"prov-rtrv:trnkgrp:name="3000"MGC-01 - Media Gateway Controller 2005-07-06 16:25:36.691 EDTM RTRV"session=begon-base1:trnkgrp"/*NAME = 3000CLLI = stim-dpnss1SVC = sip-sigpathTYPE = SIP_INSELSEQ = LIDLORIGLABEL =TERMLABEL =*/;trunkGroup.dat00200001 3000 0000 0000 003e0001 SIP_IN LIDL 0 N 0/0/0/0 0/0/0/0 005f0001 005f0002components.dat00570001 00010001 "LI" "LI Radius Protocol Family"005f0001 00010001 "loclbl1" "local label 1"005f0002 00010001 "loclbl2" "local label 2"
Note
Applying Call Limiting Over DPNSS
The following provisioning example, see Figure 1, shows two gateways that are configured to be redundant with a total of 60 DS0s to PBX-2. The following sample provision shows that the service provider sets the call limiting of 10 toward PBX-2 over DPNSS from Cisco Call Managers (CCM) CCM-X and CCM-Y.
prov-add:loclabel:name="location2",calllimit=10prov-add:DPNSSPATH:NAME="dpnss-path1",DESC="dpnss va-3745-2",EXTNODE="va-3745-2", MDO="DPNSS_BTNR188",CUSTGRPID="1111",SIGSLOT=1,SIGPORT=0prov-add:trnkgrp:name="7000",type="TDM_DPNSS",svc="dpnss_path1",clli="7000',selseq="ASC", qable="N",origlabel="location2",termlabel="location2"Figure 1 DPNSS Call Limiting Scenario
Applying Call Limiting to Incoming and Outgoing Trunk Groups
The following provisioning scenario, see Figure 2, is useful when multiple enterprises are sending their traffic through the same trunking media gateway. Call limiting used in this example can enforce limits so a certain enterprise cannot use too many trunking ports to the exclusion of other enterprises connected to the PSTN by the MGC.
To provision this, create a label, for example LABELCCMY with a value of 12, then in the B-number analysis, set the LOC_LABEL to the label (LABELCCMY) you just created. In the A-number analysis, select a dial plan based on the LOC_LABEL to the XX LABEL.
If the CCM has a prefix of 300XXX, the incoming calling limit for 300XXXX is 100 and the outgoing calling limit for 300XXXX is 12.
This allows you to define the incoming and outgoing trunk group call limiting separately.
//For outgoing call limitprov-add:loclabel:name="location1",calllimit=12numan-add:resultset:custgrpid="1111",name="set300"numan-add:resulttable:resulttype="LOC_LABEL",dw1="location1",setname="set300", custgrpid="1111",name="resultloc300"numan-add:resulttable:custgrpid="1111",name="result300",resulttype="ROUTE",dw1="rtlist3", setname="set300"numan-add:bdigtree:custgrpid="1111",callside="originating",digitstring="300", setname="set300"//For incoming call limitnuman-add:Numan-add:resultset:custgrpid="1111"?name="set301"numan-add:resulttable:resulttype="LOC_LABEL",dw1="location1",setname="set301", custgrpid="1111",name="resultloc301"numan-add:adigtree:custgrpid="1111",callside="originating",digitstring="300", setname="set301"Figure 2 Incoming and Outgoing Trunk Group Call Limiting Scenario
B-number Based Call Limiting Scenario
The following provisioning scenario, see Figure 3, is useful when limiting the number of calls based on B-numbers. If the B-number is 300XXX and call limiting for 300XXXX is 100.
prov-add:loclabel:name="location1",calllimit=100numan-add:resultset:custgrpid="1111",name="set300"numan-add:resulttable:resulttype="LOC_LABEL",dw1="location1",setname="set300", custgrpid="1111",name="resultloc300"numan-add:resulttable:custgrpid="1111",name="result300",resulttype="ROUTE",dw1="rtlist3", setname="set300"numan-add:bdigtree:custgrpid="1111",callside="originating",digitstring="300", setname="set300"Figure 3 B-number Based Call Limiting Scenario
Applying Call Limiting to a SIP Trunk Group
The following provisioning example shows that call limiting of 10 is applied to the incoming and outgoing SIP trunk groups.
//location label for call limiting of 10prov-add:loclabel:name="location1",calllimit=10//provision SIP pathprov-add:SIPPATH:NAME="sip-path",DESC="SIP path",MDO="IETF_SIP",ORIGLABEL="",TERMLABEL=""//provision SIP linkprov-add:SIPLNK:NAME="sip-link",DESC="SIP link",SVC="sip-path",IPADDR="IP_Addr1", PORT=5060,PRI=1//provision SIP route trunk prov-add:siprttrnkgrp:name="7000",url="10.0.1.2",version="2.0",cutthrough=2,srvrr=2, extsupport=1 //provision outgoing call limit for SIP trunk groupprov-add:trnkgrp:name="7000",type="IP_SIP",svc="sip-path",clli="",selseq="LIDL", origlabel="location1",termlabel="location1"//provision incoming call limit for SIP trunk groupprov-add:trnkgrp:name="7000",type="SIP_IN",svc="sip-path",clli="",selseq="LIDL", origlabel="location1",termlabel="location1"Applying Call Limiting to an H.323 Trunk Group
The following provisioning example shows that call limiting is applied to an H.323 trunk group for both incoming and outgoing trunk groups (for example, call limit for the H.323 side is 20).
prov-add:loclabel:name="location2",calllimit=20//provision EISUP path to HSI, PGW are connected with H.323 network by HSIprov-add:EISUPPATH:NAME="eisup-hsi",DESC="to orchid",EXTNODE="sh-hsi",CUSTGRPID="1111" //provision call limit for H.323 trunk groupprov-add:trnkgrp:name="6000",CLLI="sh-daisy",svc="eisup-hsi",type="IP",selseq="ASC", qable="N",origlabel="location2",termlabel="location2"
Note
Applying Call Limiting to the DPNSS Trunk Groups
The following provisioning example shows that call limiting is applied to the DPNSS trunk groups (for example, call limit for dpnss trunk group is 30) on both terminating and originating trunk groups.
prov-add:loclabel:name="location3",calllimit=30//provision DPNSS pathprov-add:DPNSSPATH:NAME="dpnss-path2",DESC="dpnss va-3745-2",EXTNODE="va-3745-2", MDO="DPNSS_BTNR188",CUSTGRPID="1111",SIGSLOT=1,SIGPORT=1,ORIGLABEL="",TERMLABEL=""//provision call limit for DPNSS trunk groupprov-add:trnkgrp:name="5331",type="TDM_DPNSS",svc="dpnss-path1",clli="va-3745-2", selseq="ASC",qable="N",origlabel="location3",termlabel="location3"Applying Call Limiting to an SS7 ISUP Trunk Group
The following provisioning example shows that call limiting is applied to SS7 (for example, the call limit for the SS7 trunk group is 40) either incoming or outgoing, and make an announcement when the number of calls exceeds the call limit threshold.
//call limit is 10prov-add:loclabel:name="location1",calllimit=10//provision both incoming and outgoing call limit for SS7 trunk groupprov-add:trnkgrp:name="7000",type="TDM_ISUP",svc="ss7svc1",clli="7000',selseq="ASC", qable="N",origlabel="location1",termlabel="location1"//The following is to provision incoming call limiting//provision incoming call limit for SS7 trunk groupprov-add:trnkgrp:name="7000",type="TDM_ISUP",svc="ss7svc1",clli="7000',selseq="ASC", qable="N",origlabel="location1",termlabel=""//The following is to provision outgoing call limiting//provision outgoing call limit for SS7 trunk groupprov-add:trnkgrp:name="7000",type="TDM_ISUP",svc="ss7svc1",clli="7000',selseq="ASC", qable="N",origlabel="",termlabel="location1"//The following is to play an announcement when calls are rejected due to exceeding threshold set by limiting//announcement provisioningnuman-add:announcement:annid=123,gwtype="AS5400",duration="60",repeat="2",interval="3", locationstring="xyz.aud"//provision local announcementnuman-add:resulttable:custgrpId="1111",name="result60",resulttype="ANNOUNCEMENT", dw1="123",dw2="0",dw4="1",setname="set1"//call limit reject internal code is "171"numan-add:cause:custgrpid="1111",causevalue="171",setname="set1"Applying Call Limiting to Digit Strings in a Dial Plan
The following provisioning examples show that call limiting applied to A- and B-numbers by the dial plan and digits analysis.
1. This is the example that all incoming calls that B-numbers have prefix of 300XXX, calling limiting for 300XXXX is set to 100.
prov-add:loclabel:name="location2",calllimit=100// provision a resultsetnuman-add:resultset:custgrpid="1111",name="set200"//provision call limit location label in resultsetnuman-add:resulttable:resulttype="LOC_LABEL",dw1="location2",setname="set200", custgrpid="1111",name="resultloc200"//provision route resulttablenuman-add:resulttable:custgrpid="1111",name="result200",resulttype="ROUTE",dw1="rtlist2", setname="set200"//provision Bdigtree for B-number 300XXXnuman-add:bdigtree:custgrpid="1111",callside="originating",digitstring="300", setname="set200"2. For example, if all incoming calls that A-numbers have prefix of 300XXX, calling limiting for 300XXXX is set to 100.
numan-add:resultset:custgrpid="1111"ÅCname="set201"//provision call limit location label in resultsetnuman-add:resulttable:resulttype="LOC_LABEL",dw1="location2",setname="set201", custgrpid="1111",name="resultloc201"//provision Adigtree for A-number 300XXXnuman-add:adigtree:custgrpid="1111",callside="originating",digitstring="300", setname="set201"Applying Call Limiting to Multiple Trunk Groups
The following provisioning example shows that one calling label can be applied to multiple trunks and trunk groups, which are either incoming or outgoing.
prov-add:loclabel:name="location3",calllimit=100//location label 3 can be used as SIP incoming trunk group 7000prov-add:trnkgrp:name="7000",type="IP_SIP",svc="sip-path",clli="",selseq="LIDL", origlabel="location3"//location label 3 can be used as SIP outgoing trunk group 8000prov-add:trnkgrp:name="8000",type="IP_SIP",svc="sip-path",clli="",selseq="LIDL", termlabel="location3"//location label 3 can be used as DPNSS trunk group 9000prov-add:trnkgrp:name="9000",type="TDM_DPNSS",svc="dpnss-path1",clli="va-3745-2", selseq="ASC",qable="N",origlabel="location3",termlabel="location3"Applying Call Limiting to IP Addresses
The following provisioning example shows that the call limiting feature can be applied to source and destination IP addresses indirectly by the dial plans.
1. Call limiting to the other peer PGW IP addresses.
Assuming a peer MGC IP address is 10.0.1.1, call limiting for EISUP is 100, call limiting can be provisioned in EISUP for the sigPath or trunk group.
Option 1: Setting call limiting with an EISUP sigPath.
prov-add:loclabel:name="location5",calllimit=100//provision call limit in EISUP pathprov-add:EISUPPATH:NAME="eisup-orkid",DESC="to orchid",EXTNODE="sh-orchid",CUSTGRPID="1111",ORIGLABEL="location5",TERMLABEL="location5"//provision EISUP IP linkprov-add:IPLNK:NAME="elinkorchid1",DESC="Link to orchid",SVC="eisup-orchid", IPADDR="IP_Addr1",PORT=8001,PEERADDR="10.0.1.1",PEERPORT=8001,PRI=1,IPROUTE=""Option 2: Set call limiting with an EISUP trunk group, for example, the trunk group is 6000.
prov-add:loclabel:name="location5",calllimit=100prov-add:EISUPPATH:NAME="eisup-orkid",DESC="to orchid",EXTNODE="sh-orchid", CUSTGRPID="1111"//provision EISUP IP linkprov-add:IPLNK:NAME="elinkorchid1",DESC="Link to orchid",SVC="eisup-orchid", IPADDR="IP_Addr1",PORT=8001,PEERADDR="10.0.1.1",PEERPORT=8001,PRI=1,IPROUTE=""//provision call limit in EISUP trunk groupprov-add:trnkgrp:name="6000",type="IP",svc="eisup-daisy",clli="sh-daisy",selseq="ASC", origlabel="location5",termlabel="location5"2. Call limiting for other SIP servers.
Assuming a SIP proxy IP address is 10.0.1.2, call limiting is set to 100, call limiting can be provisioned in the trunk group, for example, trunk group 7000.
prov-add:loclabel:name="location6",calllimit=100//provision SIP pathprov-add:SIPPATH:NAME="sip-path",DESC="SIP path",MDO="IETF_SIP",ORIGLABEL="",TERMLABEL="" //provision SIP linkprov-add:SIPLNK:NAME="sip-link",DESC="SIP link",SVC="sip-path",IPADDR="IP_Addr1", PORT=5060,PRI=1//provision SIP route trunk prov-add:siprttrnkgrp:name="7000",url="10.0.1.2",version="2.0",cutthrough=2,srvrr=2, extsupport=1//provision call limit in SIP trunk groupprov-add:trnkgrp:name="7000",type="IP_SIP",svc="sip-path",clli="",selseq="LIDL", origlabel="location6",termlabel="location6"Applying Call Limiting to an MGCP Gateway
The following example shows that call limiting is applied to an MGCP gateway with IP address of 10.0.1.4, the gateway has 4 trunk groups, which are controlled by ss7svc1, and the call limiting is set to 20.
prov-add:loclabel:name="location8",calllimit=20//provision MGCP pathprov-add:MGCPPATH:NAME="mgcp530011",DESC="MGCP service to AS-5300-11",EXTNODE="va-5300-11"//provision IP linkprov-add:IPLNK:NAME="clink11-1",DESC="MGCPlink to sh-5300-11",SVC="mgcp530011", IPADDR="IP_Addr1",PORT=2427,PEERADDR="10.0.1.4",PEERPORT=2427,PRI=1,IPROUTE=""//provision call limit for SS7 sigPathprov-add:ss7path:name="ss7svc1",desc="ss7 path",dpc="dpc1",opc="opc",mdo="Q761_BASE", SIDE="network",origlabel="location8",termlabel="location8"Playing an Announcement when the Call Limiting Threshold is Exceeded
The following example shows that an announcements can be made when calls are rejected due to exceeding the threshold set by call limiting.
//announcement provisioningnuman-add:announcement:annid=123,gwtype="AS5400",duration="60",repeat="2",interval="3", locationstring="xyz.aud"//local announcementnuman-add:resulttable:custgrpId="1111",name="result60",resulttype="ANNOUNCEMENT", dw1="123",dw2="0",dw4="1",setname="set1"//call limit reject internal code is "171"numan-add:cause:custgrpid="1111",causevalue="171",setname="set1"Dial Plans
The following sections describe the tasks related to creating dial plan data for this feature:
Dial Plan Provisioning
If you are not familiar with creating dial plans for the Cisco MGC, refer to the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
Provisioning Call Limiting for an A-number
The following procedure lists the steps for provisioning call limiting for an A-number.
Step 1
numan-add:resultset:custgrpid="5555",name="setloc1"Step 2
numan-add:resulttable:custgrpid="5555",name="resultloc",resulttype="loc_label",dw1="location1",setname="setloc1"Step 3
numan-add:adigtree:custgrpid="5555",callside="originating",digitstring="301",setname="setloc1"
Provisioning Call Limiting for a B-number
The following procedure lists the steps for provisioning call limiting for a B-number.
Step 1
numan-add:resultset:custgrpid="5555",name="setloc2"Step 2
numan-add:resulttable:custgrpid="5555",name="resultloc2",resulttype="loc_label",dw1="location1",setname="setloc2"Step 3
numan-add:bdigtree:custgrpid="5555",callside="originating",digitstring="306",setname="setloc2"
Provisioning the OVERRIDE_CALLIM Result Type for Number Analysis
The following procedure lists the steps for provisioning the OVERRIDE_CALLIM result type for number analysis. This included Pre-analysis (CPC, ANOA, and BNOA) and formal analysis (A-number and B-number).
Step 1
numan-add:resultset:custgrpid="5555",name="setloc3"Step 2
numan-add:resulttable:custgrpid="5555",name="resultoverride",resulttype="override_callim",setname="setloc3"Step 3
CPC
numan-add:cpc:custgrpid="5555",cpcvalue=9,setname="setloc3"
A-number NOA
numan-add:anoa:custgrpid="5555",noavalue=4,setname="setloc3"
B-number NOA
numan-add:bnoa:custgrpid="5555",noavalue=4,setname="setloc3"
A Digit Tree
numan-add:adigtree:custgrpid="5555",callside="originating",digitstring="302",setname="setloc3"
B Digit Tree
numan-add:bdigtree:custgrpid="5555",callside="originating",digitstring="307",setname="setloc3"
Dial Plan Examples
This section provides the following MML command examples of dial plan provisioning for this feature. Additional examples of dial plan provisioning for the Cisco MGC software can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;; provision a location label;;;;;;;;;;;;;;;;;;;;;;;;;;;;mml> prov-add:loclabel:name="location1",calllimit=1mml> prov-add:loclabel:name="location2",calllimit=1;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; add resulttype="loc_label" and assign these labels to the A digit tree;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mml> numan-add:resultset:custgrpid="5555",name="setloc"mml> numan-add:resulttable:custgrpid="5555",name="resultloc", resulttype="loc_label",dw1="location1",setname="setloc"mml> numan-add:adigtree:custgrpid="5555",callside="originating", digitstring="301",setname="setloc";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; assign the location labels to dpnss sigPath;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mml> prov-ed:dpnsspath:name="dpnss-3745-2-0",origlabel="location1",termlabel="location2";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; assign the location labels to dpnss trunk group;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mml> prov-ed:trnkgrp:name="3702",origlabel="location1",termlabel="location2";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; add resulttype="override_callim" and associate it with a set;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mml> numan-add:resulttable:custgrpid="5555",name="resultloc",resulttype="override_callim", setname="setloc"Troubleshooting Provisioning Data
The following section contains troubleshooting procedures related to provisioning:
•
For more information on troubleshooting the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.
Alarm Troubleshooting Procedures
The alarms listed below are the new alarms for this feature that require user action to be cleared. For a complete list of Cisco MGC alarms, refer to the Cisco Media Gateway Controller Software Release 9 Messages Reference Guide.
locLabelNotFound
This alarm occurs at any point in the call when a location label cannot be found in the local table.
Corrective Action
Check provisioning for the presence of the label concerned.
locTable AccessFail
This alarm occurs at any point in the call when access to the location label table failed.
Corrective Action
To correct the problem identified by this alarm, capture traces and engine logs where possible and forward them to your Cisco support representative. If an urgent traffic handling situation occurs with constant call limiting rejections, the Call Limiting feature can be disabled to restore the call service.
Command Reference
This section documents new, modified, or deleted MML commands. All other MML commands are documented in the Cisco Media Gateway Controller Software Release 9 MML Command Reference.
New MML Commands
This section contains the MML commands that are new for this feature:
set-callim:: enable or disable—the Call Limiting feature and switches it off or on for the whole MGC.
rtrv-callim—displays the current setting for the Call Limiting feature.
prov-add/ed/dlt/rtrv:loclabel—add, edit, delete, or retrieve a location label.
SET-CALLIM—Sets the Call Limiting Function
RTRV-CALLIM—Retrieves the Call Limiting Function Status
PROV-ADD:LOCLABEL—Adds the Location Label
PROV-DLT:loclabel—Deletes the Location Label
PROV-ED:loclabel—Edits the Location Label
PROV-RTRV:loclabel—Retrieves the Location Label
Stopping a Call
The MML stp-call command terminates calls by sending a special signal that causes a proper release sequence to be initiated for each active call leg. Therefore, normal call records are written and the normal connection-deletion processing is conducted with the gateways. This is sometimes referred to a graceful release.
For a graceful release, call instances receive the internal signal that provokes call clearing. As each call side clears normally, the call counters associated with that side are released.
Killing a Call
The kill-call command is not commonly used, but is used to deal with serious or emergency situations (usually as directed by Cisco personnel). If this command is issued, then the MGC when handling the command checks its internal data for the presence of location labels. If any location labels are present, the active call counter for each label is decremented by 1 as the call is deleted.
Note
Reference Information
The following sections contain reference material related to this feature. Information is included on the following areas:
•
•
•
XECfgParm.dat Parameters
The XECfgParm.dat file configuration parameters added for this feature are in the table below. For information on the other XECfgParm.dat parameters, refer to the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide.
Alarms
This section lists the alarms that are added and modified to support this feature. For information on the other alarms for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Messages Reference Guide.
New Alarms
The alarms that are added for this feature are listed below.
locTableAcessFail
This alarm is raised at any point in the call if the engine cannot access the local location label table to make a call limiting request or to decrement counters. It is a sign of possible counter corruption, and the system user needs to be made aware of the situation. Logs are also raised to indicate the labels involved.
· Description The MGC failed to access the location label table.
Severity Informational
Cause This alarm is reported when the MGC is trying to access its internal location label table to make a call limiting check or to update active call counters. If it indicates a failure in executing the counter decrement for one or more labels, associated logs identify the labels involved. Failure to carry out this counter decrement could later lead to false rejection of calls and possible traffic handling problems.
Type 1 (Communication alarm)
Action This typically points to an internal processing error. Capture traces and engine logs where possible, and forward them to your Cisco support representative. If an urgent traffic handling situation occurs, with constant call limiting rejections, the Call Limiting feature can be disabled so service can be restored.
locLabelNotFound
This alarm is raised at any point in the call if the a collected location label is missing from the internal location label table. This could point to a label being removed while still being assigned in analysis or at the trunk group or SigPath level. Logs are also raised to indicate the labels involved.
·· Description The location label was not found in the internal table.
Severity Informational
Cause This alarm can occur when the MGC reads its internal label to check or update counters for a label. If the label is not found, this alarm is generated.
Type 1 (Communication alarm)
Action This typically points to a provisioning error where a label has been removed, but references to it are not removed from Analysis, the trunk group, or SigPath. Check provisioning for the presence of the label concerned.
Internal Cause Codes
An internal cause code, listed in Table 1, was added to support the Call Limiting feature.
Table 1 Internal Cause Code Values
IC_CALL_LIMIT_REJ
171
Logs
This section lists the logs that are added or deleted to support this feature. For information on the other logs, refer to the Cisco Media Gateway Controller Software Release 9 Messages Reference Guide.
New Logs
This section contains the logs that are added to support the Call Limiting feature.
locTableAccessFail:
Failed to access the location label table
locLabelNotFound:
A-number label xxxx (label component id) is not found
or
B-number label xxxx (label component id) is not found
or
origSide label xxxx (label component id) is not found
or
termSide label xxxx (label component id) is not found
Measurements
Table 2 contains the system measurements that are added in support of this feature. For information on the other system measurements, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.
The Measurement manager must collect at regular periods (15 minutes, 60 minutes, or 24 hours) the "Successful" and "Rejected" measurement counters for every location label (componentId) defined on the system. The engine updates and stores this data in the location common to other measurement data.
Note
For each location label defined on the Cisco MGC, two measurement counters must be created. One measurement counter is for successful calls per label, and the other measurement counter is for rejected calls per label.
For the label measurements to be accurate, the successful calls counter increments only when the call has reached the Answered state.
If a call is rejected due to call limiting, the rejected calls counter is incremented.
Should failover occur, when the standby side is brought up, the measurement counters are not replicated and hence start cleanly from 0.
Billing Interface
This section identifies the call detail record (CDR) data added for this feature. For billing interface information for the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Billing Interface Guide.
Rejecting Location Label (Tag: 4232)
Rejecting Location Label Direction (Tag: 4233)
Components
The sections below discuss the provisioning components that are added, modified, and deleted for this feature. For information on the rest of the components in the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
New Components
The following LABEL provisioning component is added for this feature.
LABEL
The LABEL component represents the number of calls allowed on a location. Its MML name is as follows:
•
The LABEL component structure is shown in Table 5.
Note
Modified Components
The following components are modified for this feature by adding the ORIG LABEL and TERM LABEL parameter to each component. The component tables list only the parameters changed to support the Call Limiting feature.
•
•
•
•
DPNSSPATH
The DPNSS signaling service component type represents a DPNSS signaling path that is backhauled over IP to or from a network access server (destination). Its MML name is as follows:
•
The DPNSS signaling service component structure is shown in Table 6.
EISUP Signaling Service (sigPath)
The EISUP Signaling Service (sigPath) component is a network element that represents an EISUP signaling service or signaling path to another NE (destination). Its MML name is as follows:
•
The signaling service path component structure is shown in Table 7.
IPFAS Transport Service (previously PRI Signaling Backhaul)
The IPFAS transport service component type represents the FAS over IP transport service or signaling path from a media gateway to an MGC. Its MML name is as follows:
•
The IPFAS transport service component structure is shown in Table 8.
Multiple IPFAS Services (sigPath)
The multiple IPFAS signaling service component type is used to create multiple IPFAS or IPNFAS signaling paths and D-channels to a particular destination using either ISDN-PRI or DPNSS. Its MML name is as follows:
•
The multiple IPFAS Signaling Service component structure is shown in Table 9.
SIP Signaling Service
This component type represents the SIP signaling service or signaling path to SIP proxy servers. Its MML name is as follows:
•
The SIP signaling service component structure is shown in Table 10.
SS7 SG Signaling Service
This is the MGC NE component type and represents an SS7 signaling gateway signaling service. Its MML name is as follows:
•
The SS7 SG signaling service component structure is shown in Table 11.
SS7 Signaling Service (sigPath)
The SS7 Signaling Service (sigPath) component type represents an SS7 signaling service or signaling path to a particular SS7 switch (destination). Its name is as follows:
•
The SS7 signaling service component structure is shown in Table 12.
Trunk Group Provisioning
The trunk group provisioning component type represents a trunk group. This component is supported by MML only. Its MML name is as follows:
•
The trunk group provisioning interface component structure is shown in Table 13.
Result Types
The result type definitions shown in Table 14 are added for this feature. For information on other result type definitions for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
Result Type Definitions
The following paragraphs contain definitions of the result types listed in Table 14.
LOC_LABEL
The LOC_LABEL result type is returned from A-number analysis (the calling number) or B-number analysis (the called number) and indicates the location label.
Dataword1 is the location label name, and may be as many as 20 alphanumeric characters.
OVERRIDE_CALLIM
The OVERRIDE_CALLIM result type indicates the location label call overrides the call limiting value. Presence of the OVERRIDE_CALLIM result type indicates that for this call, any call limiting actions are ignored allowing it to set up as soon as possible.
The OVERRIDE_CALLIM result type is available to Pre-analysis, A-number analysis, and B-number analysis. Since OVERRIDE_CALLIM is available to these analysis areas, the override indicator can be set for tho following:
•
•
•
•
•
The OVERRIDE_CALLIM result type is for use when an emergency call or other high-priority call, allowing that call type to switch with a minimum of processing and without any obstacles, such as call limiting. So, even if LOC_LABEL results are collected, the presence of the OVERRIDE_CALLIM result type means that no call limiting actions are applied for this call.
Provisioning Worksheets
This section contains worksheets for the provisioning components required for this feature. For worksheets covering the rest of the provisioning components in the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
Table 15 Label Worksheet
loclbl1
locationlabel01
10
loclbl1
locationlabel02
50
Table 16 DPNSSPATH Worksheet Example
Labeldpnssvc1
AS3660
DPNSS_BTNR188
AS3660
0002
a
10
45
loclbl1
loclbl2
Table 17 SS7PATH Worksheet Example
Labelsigsvc1
AS3660
Q761_BASE
network
0002
dpc
mgw1pgw1
m3ua
key1loclbl1
loclbl2
Table 18 SS7SGPATH Worksheet Example
Labelsigsvc1
SS7 svc to dpc1
Q761_BASE
network
0002
dpc
mgw1pgw1
m3ua
key1loclbl1
loclbl2
Monitoring and Maintaining the Feature
For information on operational tasks for the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation at
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.
Glossary
Table 20 contains definitions of acronyms and technical terms used in this feature module.
CCDE, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0812R)
