Initial release of this document. 9.6(1) This feature was introduced on the PGW 2200.

Transcription

1 Document Release History Publication Date July 12, 2005 Comments Initial release of this document. Feature History Release Modification 9.6(1) This feature was introduced on the PGW This document describes the feature in the following sections: Feature Overview, page 2 Supported Platforms, page 8 Prerequisites for Using This Feature, page 8 XECfgParm.dat Configuration Tasks, page 9 Provisioning Tasks, page 10 Dial Plans, page 24 Monitoring and Maintaining the Feature, page 45 Provisioning Examples, page 15 Provisioning for an A-number, page 24 Command Reference, page 26 Reference Information, page 31 Obtaining Documentation and Submitting a Service Request, page 45 Glossary, page 45 Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA USA 2007, 2009 Cisco Systems, Inc. All rights reserved.

2 Feature Overview Feature Overview The 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. 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 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 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 For a trunk group or sigpath, there can be a different location label in each direction, allowing call limiting on incoming or outgoing calls. The same label identifier can be assigned to single or multiple instances of: Trunk groups or sigpaths This allows users to limit the number of calls to E1, or a combination of E1s. It also allows the control of calls between MGCs and the number of calls to and from VoIP networks using H.323 and SIP. Formal number analysis (A-number or B-number) allows calls to certain destinations to be limited, based on leading digits, such as area code or full B-number analysis for services like Tele-voting. This also allows calls from specific IP addresses to be limited by combining the use of dial plan switching based on incoming source address with A-number analysis location label assignment. 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. 2

3 Feature Overview 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: If an originating side call leg is deleted, both the A-number analysis location label (if present) and the location label pertaining to the originating side trunk group or sigpath have their active call counters decremented. If a terminating side call leg is deleted, both the B-number analysis location label (if present) and the location label pertaining to the terminating side trunk group or sigpath have their active call counters decremented. 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: 3

4 Feature Overview You cannot remove a location label when there are calls associated with that label. Attempting to delete a label while there is a call associated with the label causes the provisioning to be rejected with the message, This Label is in use by calls in the system. Ensure there is no call using this label. You cannot remove a location label of the same name (string) and then added back onto the system without manually switching the call limiting functionality off and back on. This is to help prevent label counter corruption from occurring. You can add a location label at any time, because it is only used when the label is assigned against the trunk group or in analysis and starts cleanly with the call counters at 0. Enabling or Disabling 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: Location label (actually the componentid identifying that label) Call limit for the label Active call counter value for this label (initially 0) 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. 4

5 Feature Overview 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 Rejection Monitor Mode Is Interrupted 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: Interrupted Notify and continue Monitor Mode Is Notify and Continue 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: A ReleaseCall message prompting the MGC to clear the call. When the call is fully cleared, a CDR captures the rejecting label information. A new connect operation that provokes a new call attempt (new B-number and possibly new A-number). The MGC clears the TCC side, and both channel connections are reset to a condition ready to invoke number analysis again. New number analysis might provide new location labels (or none), leading to Route analysis. For a valid call, circuit selection is performed on the returned trunk group, and both originating and terminating call sides are seized and ready to process the call. At this point, a new call limiting check is performed, and all the location labels from Number analysis are submitted for validation. If everything is valid, the call progresses normally and at answer the successful measurement counters for all involved labels are incremented. At call clear down, the active call counters are decremented. 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: No further routing option In this case, the MGC clears the call by Cause analysis (having internally set the cause to IC_CALL_LIMIT_REJ). Upon full call clearing, a CDR captures the rejecting location label information. Further routing options exist In this case, the MGC can try again by clearing the terminating call side and then requesting new routing, which is effectively an advance trunk group operation. The MGC clears the TCC side and the terminating side channel connection and resets it to a condition ready to invoke new Route analysis. Successful routing analysis provides a new trunk group to try. Circuit selection is also performed on the new trunk group. Then both the originating and terminating sides are seized to be ready to go forward with the call. At this point, a new call limiting check is made. In this case, the existing labels from Number analysis are retained and any B-number 5

6 Feature Overview labels resubmitted in this second call limiting request. If everything is valid, the call progresses normally; and at answer, the successful measurement counters for all involved location labels are incremented. At call clear down, the active call counters are decremented. 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: For rejected calls, a result is generated, indicating the call is rejected and includes the name and componentid of the rejecting label. The call is then subjected to Cause analysis for possible re-routing. However, if the rejection is caused by the originating side label or the A-number or B-number analysis location label, no route is applied, and the call is cleared, even if Cause analysis delivers a routing result. When the call is cleared, the rejected calls measurement counter for the location label (componentid) that caused the call rejection is incremented. In addition, the rejecting label name is included in a call context variable ready for CDR collection. For permitted calls, when the MGC is receiving the answer indication from the terminating side, the successful calls measurement counters for all location labels present are incremented. For a released terminating side call, when the final internal release signal is received, a check is made for any B-number analysis delivered label, and then the active call counter decrements for the termsidelabel and the B-number label (if present). For a released originating side call, when the final internal signal is received, a check is made for any A-number analysis delivered label, and then the active call counter decrements for the origsidelabel and the A-number label (if present). 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. 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. 6

7 Feature Overview 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. 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 If a call is rejected, the active call counters are not incremented for any of the labels present. 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. 7

8 Supported Platforms 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: Release Notes for Cisco Media Gateway Controller Software Release 9.6(1) Cisco Media Gateway Controller Hardware Installation Guide Regulatory Compliance and Safety Information for the Cisco Media Gateway Controller Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide Cisco Media Gateway Controller Software Release 9 Provisioning Guide Cisco Media Gateway Controller Software Release 9 Dial Plan Guide Cisco Media Gateway Controller Software Release 9 MML Command Reference Cisco Media Gateway Controller Software Release 9 Messages Reference Guide Cisco Media Gateway Controller Software Release 9 Billing Interface Guide Cisco Media Gateway Controller Software Release 9 Management Information Base Guide Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide Cisco Media Gateway Controller Node Manager User s Guide 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 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). 8

9 XECfgParm.dat Configuration Tasks 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 Configuration of the Cisco MGC software requires that the system software be shut down. In a simplex system, calls cannot be processed during system shutdown. In a continuous service system, your system loses the ability to maintain calls during a critical event if the system software on one of the MGC hosts is shut down. Caution Do not modify the other XECfgParm.dat parameters. To enable control on the MGC, perform the following steps: Step 1 Step 2 Step 3 If you have not already done so, open the /opt/ciscomgc/etc/xecfgparm.dat file on the active and standby Cisco MGC hosts using a text editor, such as vi. Search for the engine.calllimitingcontrol parameter and enter 1 on the active and standby Cisco MGC hosts to enable the feature. If you are installing and configuring your Cisco MGC software for the first time, return to the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide and continue from where you left off. Verifying the XECfgParm.dat Configuration Use the procedure below if you believe the 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 feature, perform the following steps. Caution Do not modify the other XECfgParm.dat parameters. Stopping the MGC software causes a loss of all service. Step 1 Log in to the standby Cisco MGC as root and change directories to the etc subdirectory by entering the following UNIX command: cd /opt/ciscomgc/etc Step 2 Open the XECfgParm.dat file using a text editor, such as vi. Step 3 Search for the engine.calllimitingcontrol parameter and enter a 1 to enable call limiting; or enter a 0 to disable call limiting. 9

10 Provisioning Tasks Step 4 Step 5 Step 6 Step 7 Step 8 Save your changes and close the text editor. Manually stop the Cisco MGC software on the standby Cisco MGC by entering the following UNIX command: /etc/init.d/ciscomgc stop Once the software shutdown is complete, manually start the Cisco MGC software on the standby Cisco MGC by entering the following command: /etc/init.d/ciscomgc start Log in to the active Cisco MGC, start an MML session, and enter the following command: mml> sw-over::confirm Site alarms are automatically set until the out-of-service (OOS) Cisco MGC host is returned to an in-service (IS) state. Repeat Step 2 through Step 7 for the newly standby Cisco MGC host. Provisioning Tasks The feature can be provisioned on: A-numbers B-numbers sigpaths Trunk groups The following sections describe the MGC provisioning related to this feature: Enabling the Functions, page 10 Modifying Components, page 13 Provisioning Examples, page 15 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 section on page 11 to begin provisioning the feature. Enabling the Functions This section contains the procedures that you must perform to enable the feature on your Cisco MGC. When provisioning the components that enable the Cisco MGC to support, perform the procedures in the following order: Enabling the Control Parameter the First Time, page 11 Dynamically Enabling, page 11 Adding a Location Label, page 12 Dynamically Disabling, page 12 10

11 Provisioning Tasks Enabling the Control Parameter the First Time When enabling the 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 feature, you can go to Dynamically Enabling Call Limiting section on page 11. Caution Performing this procedure stops the functioning of the Cisco MGC software. Perform this step only while in contact with Cisco Technical Assistance Center (TAC) personnel. Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Log in to the standby Cisco MGC as root and change directories to the etc subdirectory by entering the following UNIX command: cd /opt/ciscomgc/etc Open the XECfgParm.dat file using a text editor, such as vi. Search for the engine.calllimitingcontrol parameter and ensure its value is set to 1 (enable call limiting). Set the engine.calllimitingcontrol parameter to 1 (enable call limiting). Save your changes and close the text editor. Manually stop the Cisco MGC software on your standby Cisco MGC by logging in to your active Cisco MGC as root and enter the following command: /etc/init.d/ciscomgc stop This action disables the automated startup script. Once the software shutdown is complete, manually start the Cisco MGC software on your standby Cisco MGC by logging in to your active Cisco MGC as root and enter the following command: /etc/init.d/ciscomgc start Perform a manual switchover from the active Cisco MGC, by logging in to the active Cisco MGC, starting an MML session, and entering the following command: mml> sw-over::confirm Site alarms are automatically set until the out-of-service (OOS) Cisco MGC host is returned to an in-service (IS) state. Caution Step 9 Switchover operations cause the loss of all SS7 messages transmitted to the Cisco MGC for approximately 3 seconds. This affects unstable in-progress calls as well as new calls. Stable in-progress calls are not affected. Repeat Step 1 through Step 8 for the newly standby Cisco MGC. Dynamically Enabling Once the feature has been enabled in XECfgparm.dat, you can dynamically change the feature status. 11

12 Provisioning Tasks After you have dynamically disabled call limiting, while the MGC is running, you can also reenable this feature. To enable the 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 Enable the OverrideCallLimiting parameter for the whole MGC by using the following MML command. mml> set-callim:enable Adding a Location Label To add a location label, perform the following steps: Step 1 Step 2 Step 3 Step 4 Open a provisioning session by using the syntax in the following MML command: mml> prov-sta::srcver= callim1,dstver= callim2 Name the location labels and set the call limits by using the following MML commands: mml> prov-add:loclabel:name="loclbl1",desc="local label 1",calllimit=25 mml> prov-add:loclabel:name="loclbl2",desc="local label 2",calllimit=60 Repeat Step 2 for the remaining location labels. Save and activate your changes, on the active and standby MGCs in a continuous-service system, using the prov-dply MML command. Use the prov-cpy MML command to save and activate your changes on a simplex MGC (single-host) system. Both of these MML commands automatically end the provisioning session. Dynamically Disabling Once the 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. 12

13 Provisioning Tasks 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 Disable the OverrideCallLimiting parameter for the whole MGC by using the following MML command. mml> set-callim:disable Modifying Components Modifying a Label Call Limit The following section contains the procedures for modifying the call limiting location label in your Cisco MGC provisioning data: Modifying a Label Call Limit, page 13 To add a label call limit, perform the following steps: Step 1 Step 2 Start a provisioning session. Enter the following command to add the location label to the location table: mml> prov-add:loclabel:name="locationlabel01",calllimit=10 Where: name MML name of the label to be added. description An assigned name. It can be as many as 128 alphanumeric characters in length. 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 To enable a provisioned switch to disable call limiting for a particular label, enter the following value for call limit, which effectively allows all calls just for the specified label: mml> prov-ed:loclabel:name="locationlabel01",call limit= A value of for the call limit causes the associated location label to be ignored when the MGC performs validation during call processing. Step 3 Verify the label. To do so, select either a single label by using the following MML command: mml> prov-rtrv:loclabel:name="locationlabel01" or verify all labels by using the following MML command: 13

14 Provisioning Tasks mml> prov-rtrv:loclabel:all Step 4 Step 5 Repeat Step 2 and Step 3 for each location label you want to modify in your provisioning data. If there are no other components that you need to provision, save and activate your changes, on the active and standby MGCs in a continuous-service system, using the prov-dply MML command. Use the prov-cpy MML command to save and activate your changes on a simplex MGC (single-host) system. Both of these MML commands automatically end the provisioning session. Retrieving Location Labels To retrieve location labels, perform one or more of the following steps: Step 1 Step 2 Step 3 Step 4 Retrieve a single location label by using the syntax in the following MML command: prov-rtrv:loclabel:name="loclbl1" Repeat Step 1 for the remaining location labels you wish to retrieve. The result returned from a single label is shown in the response shown in the Provisioning Examples, page 15. This command is performed on the sigpath or trunk group level. or Retrieve all location labels by using the syntax in the following MML command: prov-rtrv:loclabel:all or Retrieve all location labels (for both sigpath and trunk group) of a specified name by using the syntax in the following MML command: prov-rtrv:loclabel:name="loc-1","comp" The result returned is: MGC-01 - Media Gateway Controller :11: EDT M RTRV "session=test:loclabel" /* Components ss7svc1 tg-1000 tg-2000 */ Deleting Components The following section contains the procedure for deleting call limit location labels in your Cisco MGC provisioning data: 14

15 Provisioning Tasks Note When location labels and their associated measurements are deleted and new labels are added, the associated measurement locations are not deleted and could hold part of the data for the previous label and part relevant to the new label. After label changes, you can expect odd measurement results until a 24-hour settling period has passed. 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 :02: PST M DENY SROF "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 :26: PST M DENY SROF "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 Do not name the destination directory active or new. The names active and new have special meanings in the Cisco MGC software. Starting a provisioning session with a source version name of new, is to be done only the first time provisioning is performed. prov-stp prov-sta::srcver="new",dstver="ver1" prov-add:loclabel:name="loclbl1",desc="local label 1",calllimit=2345 prov-add:loclabel:name="loclbl2",desc="local label 2",calllimit=6000 prov-rtrv:loclabel:name="loclbl1" prov-rtrv:loclabel:name="loclbl2" prov-rtrv:loclabel:"all" locationlabel.dat 005f f

16 Provisioning Tasks prov-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=2 prov-add:dpc:name="dpc2",desc="dest. point code",netaddr="3.3.3",netind=2 prov-add:extnode:name="dpnss-gw1",desc="nas 2600 Backhaul",TYPE="C2600", ISDNSIGTYPE="IUA",GROUP=0 prov-add:extnode:name="eisup1",desc="external node - eisup",type="mgc", ISDNSIGTYPE="N/A",GROUP=0 prov-add:extnode:name="ipfas1",desc="external node - ipfas",type="c2600", ISDNSIGTYPE="N/A",GROUP=0 prov-add:extnode:name="ss7sg1",desc="external node - ss7sg",type="taliss7", ISDNSIGTYPE="N/A",GROUP=0 prov-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 :22: EDT M RTRV "session=egw-2:sippath" /* NAME = sip-path DESC = sip path MDO = IETF_SIP ORIGLABEL = TERMLABEL = */ ; sigpath.dat SS7-ANSI ANSISS7_STANDARD network n f f EISUP EISUP network n f f dummy network n f f e0001 SIP IETF_SIP network n f f SS7-ANSI ANSISS7_STANDARD network n f f DPNSS DPNSS_BTNR network n f f

17 Provisioning Tasks prov-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 :25: EDT M RTRV "session=begon-base1:trnkgrp" /* NAME = 3000 CLLI = stim-dpnss1 SVC = sip-sigpath TYPE = SIP_IN SELSEQ = LIDL ORIGLABEL = TERMLABEL = */ ; trunkgroup.dat e0001 SIP_IN LIDL 0 N 0/0/0/0 0/0/0/0 005f f0002 components.dat "LI" "LI Radius Protocol Family" 005f "loclbl1" "local label 1" 005f "loclbl2" "local label 2" Note The XECfgParm.dat parameter, engine.calllimitingcontrol controls call limiting for the MGC platform. The parameter default value is 0, where 0 is false (call limiting disabled) and 1 is true (call limiting enabled). The following provisioning examples require engine.calllimitingcontrol to be enabled (set to 1). Applying 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=10 prov-add:dpnsspath:name="dpnss-path1",desc="dpnss va ",extnode="va ", MDO="DPNSS_BTNR188",CUSTGRPID="1111",SIGSLOT=1,SIGPORT=0 prov-add:trnkgrp:name="7000",type="tdm_dpnss",svc="dpnss_path1",clli="7000',selseq="asc", qable="n",origlabel="location2",termlabel="location2" 17

18 Provisioning Tasks Figure 1 DPNSS Scenario PSTN Gateway PSTN AS5X00/UP V V PGW 2200 Packet Core H.323 Gatekeeper GK M CCM-X M CCM-Y IP IP Phone IP IP Phone MGX 8800 Voice GW MGCP SS7/IP between nodes SIP H.323 C7/SS7 PRI/Q.SIG/DPNSS signaling backhaul Data PRI/Q.SIG/DPNSS physical interface IMT V V PBX-2 Two Gateways used for redundancy, total DS0=60 Call limiting can limit calls, for example to 10 DS Applying 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 limit prov-add:loclabel:name="location1",calllimit=12 numan-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 limit numan-add:numan-add:resultset:custgrpid="1111"?name="set301" numan-add:resulttable:resulttype="loc_label",dw1="location1",setname="set301", custgrpid="1111",name="resultloc301" 18

19 Provisioning Tasks numan-add:adigtree:custgrpid="1111",callside="originating",digitstring="300", setname="set301" Figure 2 Incoming and Outgoing Trunk Group Scenario PSTN Gateway PSTN AS5X00/UP V V PGW 2200 Packet Core H.323 Gatekeeper GK M CCM-X M CCM-Y IP IP Phone IP IP Phone MGX 8800 Voice GW V MGCP SS7/IP between nodes SIP H.323 C7/SS7 PRI/Q.SIG/DPNSS signaling backhaul Data PRI/Q.SIG/DPNSS physical interface IMT V Per Business contract For example set the limit to 12 calls to this Call Manager B-number Based 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=100 numan-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" 19

20 Provisioning Tasks Figure 3 B-number Based Scenario PSTN Gateway PSTN AS5X00/UP V V PGW 2200 Packet Core H.323 Gatekeeper GK M CCM-X M CCM-Y IP IP Phone IP IP Phone MGX 8800 Voice GW MGCP SS7/IP between nodes SIP H.323 C7/SS7 PRI/Q.SIG/DPNSS signaling backhaul Data PRI/Q.SIG/DPNSS physical interface IMT V V PBX-2 Radio station contest results in many simultaneous calls to the same B-Number. This feature can be used to limit the calls to the B-number by setting XX Applying 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 10 prov-add:loclabel:name="location1",calllimit=10 //provision SIP path prov-add:sippath:name="sip-path",desc="sip path",mdo="ietf_sip",origlabel="",termlabel="" //provision SIP link prov-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=" ",version="2.0",cutthrough=2,srvrr=2, extsupport=1 //provision outgoing call limit for SIP trunk group prov-add:trnkgrp:name="7000",type="ip_sip",svc="sip-path",clli="",selseq="lidl", origlabel="location1",termlabel="location1" //provision incoming call limit for SIP trunk group prov-add:trnkgrp:name="7000",type="sip_in",svc="sip-path",clli="",selseq="lidl", origlabel="location1",termlabel="location1" Applying 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 HSI 20

21 Provisioning Tasks prov-add:eisuppath:name="eisup-hsi",desc="to orchid",extnode="sh-hsi",custgrpid="1111" //provision call limit for H.323 trunk group prov-add:trnkgrp:name="6000",clli="sh-daisy",svc="eisup-hsi",type="ip",selseq="asc", qable="n",origlabel="location2",termlabel="location2" Note Either the EISUP path or the HSI trunk group can be provisioned with location label. Applying 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 path prov-add:dpnsspath:name="dpnss-path2",desc="dpnss va ",extnode="va ", MDO="DPNSS_BTNR188",CUSTGRPID="1111",SIGSLOT=1,SIGPORT=1,ORIGLABEL="",TERMLABEL="" //provision call limit for DPNSS trunk group prov-add:trnkgrp:name="5331",type="tdm_dpnss",svc="dpnss-path1",clli="va ", selseq="asc",qable="n",origlabel="location3",termlabel="location3" Applying 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 10 prov-add:loclabel:name="location1",calllimit=10 //provision both incoming and outgoing call limit for SS7 trunk group prov-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 group prov-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 group prov-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 provisioning numan-add:announcement:annid=123,gwtype="as5400",duration="60",repeat="2",interval="3", locationstring="xyz.aud" //provision local announcement numan-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" 21

22 Provisioning Tasks Applying 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 resultset numan-add:resultset:custgrpid= 1111,name= set200 //provision call limit location label in resultset numan-add:resulttable:resulttype="loc_label",dw1="location2",setname="set200", custgrpid="1111",name="resultloc200 //provision route resulttable numan-add:resulttable:custgrpid="1111",name="result200",resulttype="route",dw1="rtlist2", setname="set200" //provision Bdigtree for B-number 300XXX numan-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 resultset numan-add:resulttable:resulttype="loc_label",dw1="location2",setname="set201", custgrpid="1111",name="resultloc201" //provision Adigtree for A-number 300XXX numan-add:adigtree:custgrpid="1111",callside="originating",digitstring= 300", setname="set201" Applying 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 7000 prov-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 8000 prov-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 9000 prov-add:trnkgrp:name="9000",type="tdm_dpnss",svc="dpnss-path1",clli="va ", selseq="asc",qable="n",origlabel="location3",termlabel="location3" Applying 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 , 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 path 22