Cisco Unified Communications Manager administrators must define the following item:

• A geolocation for every device that participates in any feature that requires geolocations. The Request for Comments (RFC) 4119 standard provides the basis for geolocations. Geolocations use the civic location format that specifies the following fields: country, A1, A2, A3, A4, A5, A6, PRD, POD, STS, HNO, HNS, LMK, LOC, FLR, NAM, and PC. Geolocations get configured manually.

Cisco Unified Communications Manager administrators then assign geolocations to devices.

The following entities in a Cisco Unified Communications Manager system can have geolocation and geolocation filter values that are assigned:

• Device pools

• CTI route points

• Phones (optional)

• CTI ports

  Note	Phones do not specify a drop-down list box for associating a phone with a geolocation filter.

• SIP trunks

• Intercluster trunks (ICT)

• H.323 gateways

• MGCP ports of the following types: T1, E1, PRI, FXO

You do not need to associate media devices, such as media termination points (MTP), conference bridges (CFB), annunciators, and music on hold (MOH) servers, with geolocations.

Internally, the device layer of Cisco Unified Communications Manager associates with geolocation values that call processing uses. The following sequence takes place:

1. Devices read the GeolocationPkid and GeolocationFilterPkid for its configuration at device or device pool level.

2. The devices communicate this Pkid and deviceType information in CC (for example, CcRegisterPartyA) and PolicyAndRSVPRegisterReq messages during call signaling.

3. The intercluster trunk (ICT) or SIP trunk device layer that receives this information uses the information for location conveyance.

4. No communication of geolocation from Cisco Unified Communications Manager to a phone takes place.

Source of Geolocation Information

The following logic determines the geolocation value:

1. Read the value for geolocation from the device window. If it is not configured on device page, for phone device in roaming, read the device pool (DP) from the roaming configuration. For phone device that is not in roaming, read the DP from the device configuration.

2. For trunk, ICT, or MGCP port device, read the DP from the device configuration.

3. From the selected DP, read the value of geolocation from DP configuration window.

4. If DP is not configured with a value for Geolocation, use blank value.

5. If available geolocation value is blank, call processing uses the configured value that the Default Geolocation enterprise parameter specifies.

The standard record for a geolocation specifies Unspecified. Use this value when no geolocation needs to associate with a device. In such scenarios, any features that are based on geolocations do not execute. Also, devices for which no geolocation gets specified do not participate in geolocation information conveyance across clusters for intercluster calls.

Be aware that the Default Geolocation enterprise parameter can be configured from drop-down list boxes on the Enterprise Parameters Configuration window.

When the called party specifies a group device, a different geolocation can apply for each device in a group. For the early attended scenarios, you do not know the actual connected device until the device gets answered. Thus, the Geolocation information gets aggregated until the device answers.

• The Call Control and Feature layer receives temporary geolocation information ("MixedDevice") until the device answers.

• When a device answers, the actual geolocation information for the device becomes available and gets communicated to call control and to any features that are involved.

The following table specifies examples of geolocations.

Geolocation identifiers get constructed from a combination of geolocations, geolocation filters, and device types of Cisco Unified Communications Manager devices.

See the following sections for detailed descriptions of geolocations and geolocation filters:

• Geolocations Feature

• Geolocation Filters Feature

Geolocation filters allow selection of specific fields from the 17 geolocation fields. Use the System > Geolocation Filter menu option in Cisco Unified Communications Manager Administration to configure geolocation filters manually. Specific Cisco Unified Communications Manager features associate the geolocation filters by using drop-down list boxes in the configuration windows of the devices that get configured for a particular feature.

The Cisco Unified Communications Manager device type of a device specifies one of the following values:

• Border - Use this value to specify accessing PSTN trunks, intercluster trunks (ICTs), gateways, and MGCP ports.

• Interior - Use this value for VoIP phones or internal endpoints.

See Logical Partitioning Feature for a detailed listing of the Cisco Unified Communications Manager devices that associate with the Border and Interior device types.

The following object specifies an example geolocation identifier:

{geolocPkid=9dc76052-3a37-78c2-639a-1c02e8f5d3a2, filterPkid=d5bdda76-6a86-56c5-b5fd-6dff82b37493, geolocVal=, devType=8}

where:

The geolocVal field gets used in cases where the Cisco Unified Communications Manager database does not reference the geolocation record but data for a geolocation comes from another source (for example, location conveyance PIDF-LO XML from a remote cluster).

In such cases, Cisco Unified Communications Manager constructs the name value pair for the geolocation fields.

Example: "country=US:A1=Texas:A3=Richardson:LOC=Building 6" where the value gets communicated through the geolocVal field.

Note	In such a case, the geolocPkid is kept null and call control or features access the geolocVal field from a geolocation identifier.

The following string specifies the logical representation of a geolocation identifier:

"Border:country=US:A1=Texas:A3=Richardson:LOC=Building 6"

Note	This geolocation identifier gets constructed from the member fields of a geolocation identifier.

Incoming requests that carry geolocation information for location conveyance get checked for compliance as follows:

1. Geolocation headers indicate inclusion of PIDF-LO, but message body does not carry PIDF-LO.

2. Geolocation header has a CID header that refers to a URI for which no corresponding Content-ID header with the same URI exists.

3. Geolocation header has a URI other than CID header (for example, SIP or SIPS URI for LbyR).

The SIP trunk that receives a noncompliant SIP request responds with a "424 Bad Location Information" response.

The following cases result in ignoring the processing of geolocation info. For information purposes, the SIP trunk sends a Geolocation-Error header in the next outgoing SIP response (for example, 180 or 200).

• PIDF-LO lacks mandatory elements, such as "geopriv," "location-info," "civicAddress," or "usage-rules."

• If usage-rules show a retention-expiry time that already elapsed when it is compared to the current time in GMT, processing gets ignored.

Because the received geolocation information gets ignored, the SIP trunk continues to use the locally configured geolocation information on the SIP trunk.

If an error occurs while the received geolocation information on an intercluster trunk is being processed, locally configured geolocation information for the trunk gets used.

The cluster that receives the PIDF-LO XML parses the received geolocation information and passes the information as colon-separated name value pairs in the GeolocationInfo data structure of the CcNotifyInd signal.

Example: "Country=US:A1=NC:A3=RTP:LOC=BLD9"

The content of the received geolocation information of the PIDF-LO overrides any locally configured geolocation information on a trunk, which gets used for the device across the trunk.

Example: {geolocPkid=, filterPkid=d5bdda76-6a86-56c5-b5fd-6dff82b37493, geolocVal=”Country=US:A1=NC:A3=RTP:LOC=BLD9”, devType=4}

Outgoing Geolocation Change

The supplementary service (SS) feature interactions, such as Transfer, Conference, Park retrieval, and others, result in connected party change.

For such scenarios, if the SIP trunk or intercluster trunk device receives valid geolocation information from Call Control that differs from previously sent geolocation information, updated geolocation information gets communicated in an UPDATE (SIP trunk) or Notify (intercluster trunk) message.

Incoming Geolocation Change

For SS feature interactions in a remote cluster, the updated geolocation information gets received over an SIP trunk or intercluster trunk in an UPDATE or Notify message.

When such an update is received, the SIP trunk or intercluster trunk parses the PIDF-LO and passes the PIDF-LO to call control and to the LPSession process.

Example PIDF-LO

The following example shows a PIDF-LO that is sent across a SIP trunk. Be aware that the items that are shown in bold font are relevant for location conveyance.

UPDATE sip:4400@10.10.10.2:5060;transport=tcp SIP/2.0Date: Sat, 12 Jul 2008 13:28:42 GMT
Call-Info: <urn:x-cisco-remotecc:callinfo>; security= NotAuthenticated
Geolocation: <cid:4900@10.10.10.1>;inserted-by=”10.10.10.1”
Content-ID: 4900@10.10.10.1
From: <sip:4900@10.10.10.1>;tag=4d1edcb1-f546-4ee7-966c-2973fbc56475-31638661
P-Asserted-Identity: <sip:4900@10.10.10.1>
Content-Length: 1070
User-Agent: Cisco-CUCM7.1
To: <sip:4400@10.10.10.2>;tag=e1258ce2-8620-4005-9aa1-72d99cd54050-31642615
Contact: <sip:4900@10.10.10.1:5060;transport=tcp>
Content-Type: application/pidf+xml
Call-ID: bbb3f900-8781b563-b-47f54c0a@10.10.10.2
Via: SIP/2.0/TCP 10.10.10.1:5060;branch=z9hG4bK179f431e3
CSeq: 101 UPDATE
Max-Forwards: 70
<?xml version=”1.0” encoding=”UTF-8”?>
<presence xmlns=”urn:ietf:params:xml:ns:pidf”
xmlns:gp=”urn:ietf:params:xml:ns:pidf:geopriv10”
xmlns:cl=” urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc”
xmlns:dm=”urn:ietf:params:xml:ns:pidf:data-model”
xmlns:caps=”urn:ietf:params:xml:ns:pidf:caps”
xmlns:cisco=”http://www.cisco.com”
entity=”pres:geotarget@example.com”>
<dm:device id=”sg89ae”>
<caps:devcaps>
<cisco:gateway>false</cisco:gateway>
</caps:devcaps>
<gp:geopriv>
<gp:location-info>
<cl:civicAddress>
<cl:country>IN</cl:country>
<cl:A1>KA</cl:A1>
<cl:A2>a2</cl:A2>
<cl:A3>BLR</cl:A3>
<cl:A4>a4</cl:A4>
<cl:A5>a5</cl:A5>
<cl:A6>a6</cl:A6>
<cl:PRD>prd</cl:PRD>
<cl:POD>pod</cl:POD>
<cl:STS>sts</cl:STS>
<cl:HNO>123</cl:HNO>
<cl:HNS>hns</cl:HNS>
<cl:LMK>lmk</cl:LMK>
<cl:LOC>BLDG1</cl:LOC>
<cl:FLR>flr</cl:FLR>
<cl:NAM>nam</cl:NAM>
<cl:PC>pc</cl:PC>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2008-09-03T17:58:19Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
<timestamp>2008-09-02T17:58:19Z</timestamp>
</dm:device>
</presence>