Jump to: navigation, search

Geo-location for MSML-Based Services: Strict Matching

SIP Server supports strict geo-location matching for MSML-based services by ensuring that a call with a particular geo-location is served only by an MSML service within the same geo-location or by an MSML service within the alternate location (if configured). If a correctly geo-located MSML service is unavailable, SIP Server does not provide the required service.

SIP Headers

To prevent GVP from using a wrongly located MCP farm, SIP Server adds (in addition to the X-Genesys-geo-location header) the X-Genesys-strict-location header with a value of enforce to the INVITE that it sends to GVP.

Header Name Header Value Meaning
X-Genesys-geo-location
It contains the call geo-location label if an MSML service matching that label is available. It contains the overflow-location label if the intial MSML service is not available. Instructs the Resource Manager to choose the MCP that serves a particular location.
X-Genesys-strict-location enforce Informs the Resource Manager that it must reject INVITE if there is no MCP avaiable that serves a particular the geo-location.

Alternate Geo-location

The alternate geo-location defined by the overflow-location-map option allows you to pair an alternate MSML-based service with a geo-location label. The alternate (overflow) location will be tried if the primary geo-location is not available or fails. In addition, the overflow-location key can be provided in AttributeExtensions of the TRouteCall and TApplyTreatment client requests. The value of the overflow-location key in AttributeExtensions takes precedence over the overflow-location-map option value. If present in the request, the overflow-location key enables a strict MSML-based service location for the call even if it is disabled at at Application level. If the overflow-location key is empty, SIP Server removes the previously assigned overflow-location (if set at an Application level) and enables MSML strict geo-location matching.

If SIP Server finds the corresponding service and sends an INVITE to that service but does not receive a positive response, SIP Server might retry an INVITE attempt once more—but only within the service that has the same geo-location or geo-location equal to the value of the overflow-location key.

Failure Alarms

SIP Server can generate an MSML geo-location failure alarm whenever an attempt to provide an MSML service fails because of the geo-location strict matching. The option msml-location-alarm-timeout specifies how often SIP Server sends that alarm (52052 code). An alarm message contains a list of failed geo-locations along with a number of failures occurred within the timeout. There is no message to reset the alarm. It is supposed to be reset by the Management Layer timeout (should be greater than the timeout defined by the option above) when SIP Server stops detecting new MSML geo-location failures.

Feature Configuration

To enable geo-location with strict matching, complete these steps:

In the TServer section of the SIP Server Application, configure the following options:


For more information, see the Selection Based on Geo-Location section in the Framework 8.1 SIP Server Deployment Guide.

See the Configuring Genesys Media Server section in the Framework 8.1 SIP Server Deployment Guide.

  1. Create a DN of type Trunk.
  2. In the TServer section, configure the following option:
    • geo-location—Set to the same geo-location value as any of the MSML DNs.
For more information, see the Selection Based on Geo-Location section in the Framework 8.1 SIP Server Deployment Guide.

Include the geo-location extension key with the same value as any of the MSML DNs.

Note: This method takes precedence over geo-location configured at the DN level.


enable-strict-location-match

Setting: Application level
Section: [TServer]
Default Value: No default value (empty string)
Valid Values: msml or true, softswitch, trunk, all
Changes Take Effect: On the next call

This option controls the SIP Server behavior in cases where an MSML service that matches a call by geo-location or overflow-location is not available, or, if during an attempt to apply a treatment, the matching service responds to the INVITE message with a SIP error, as follows:

  • If this option is not present or not configured, SIP Server tries other available services for a call.
  • If this option is set to msml (or true), SIP Server tries other available services that match a call by geo-location or overflow-location. If there is no match, SIP Server does not apply a service to the call with a different geo-location. (A value of true is supported for compatibility with previous releases of this feature.)
  • If this option is set to trunk or softswitch, SIP Server tries other available trunks or softswitches that match a call by geo-location. This applies to calls directed to an external destination or DNs located behind the softswitch. If there is no match, SIP Server does not send a call to a device with a different geo-location.
  • If this option is set to all, SIP Server applies the msml setting for calls to GVP and the trunk/softswitch setting to other cases.

Note: If the enable-strict-location-match option is set to msml or true, it is possible to specify an alternative geo-location using the Application level option overflow-location-map, or using the overflow-location key in AttributeExtensions of TRouteCall and TApplyTreatment client requests.

overflow-location-map

Setting: Application level
Section: [TServer]
Default Value: No default value (empty string)
Valid Values: Any valid string with comma-separated elements
Changes Take Effect: On the next call

This option creates an association between geo-location labels and overflow-location labels, to support strict geo-location matching.
The format of the option is: geo-location label=overflow-location label.

For example, in labelA=labelB,labelC=labelD...
labelA and labelC are geo-location labels; labelB and labelD are overflow-location labels.
If services or resources that match the call by geo-location=labelA are not available, SIP Server will try services or resources that matches the call by overflow-location=labelB.

msml-location-alarm-timeout

Setting: Application level
Section: [TServer]
Default Value: 0
Valid Values: An integer 0-65535
Changes Take Effect: Immediately

This option enables a configurable alarm when a connection that involves an MSML DN and is restricted by geo-location, cannot be established. SIP Server maintains an alarm log of failed attempts and will display a 52052 message that lists those failures. The value of this option is the number of seconds between displays.
When the value is 0 or this option is not configured, no alarms are raised.

AttributeExtensions

Key: geo-location
Type: String
Values: A geo-location label
Requests: ApplyTreatment, TRouteCall

If TRouteCall or TApplyTreatment contains the geo-location extension, SIP Server makes this geo-location to be the most preferable on the current call. It means that each time when the switch resource is selected based on the geo-location parameter, resources with the preferred geo-location take precedence.


Key: overflow-location
Type: String
Values: An alternate geo-location label
Requests: ApplyTreatment, TRouteCall


Note: The overflow-location extension key applies only if the geo-location extension key is defined in the same request.

Feature Limitations

  • The feature works only for MSML-based devices (no NETANN support).
  • If an MSML service is selected for a device with contact=::msml on a corresponding DN (Trunk, Voice Treatment Port, Trunk Group, or Voicemail DN), the feature works properly only in the Active-Active RM deployment.
  • If an MSML service is selected for a device with contact=::msml on a corresponding DN (Trunk, Voice Treatment Port, Trunk Group, or Voicemail DN), SIP Server does not try the alternate (overflow) location if an initial INVITE to the primary geo-location fails. This limitation does not apply to the initial INVITE selection.
This page was last modified on July 12, 2016, at 10:27.

Feedback

Comment on this article:

blog comments powered by Disqus