1. API Guide
  2. ISR FACE
  3. Determining the UCID

Determining the UCID

The Unique Call Identifier (UCID) accurately identifies the specific session related to a request and is the recommended parameter when using any ISR API. It can be one of two values associated with the session: the isr_ucid or ingress_callid. For the isr_ucid, the RSS pulls the SIP Header matching the configured X-ISR-UCID header name from the SIP Headers, if it is present. For a SIPREC session, if the <*:ucid> field is present in the extension data, the parameter value is used as the isr_ucid. In the case where both extension data and X-ISR-UCID SIP Headers are present, X-ISR-UCID SIP Header is used as the isr_ucid. The call-id from the SIP Headers of the initial INVITE is used for the ingress_callid.

There has been a lot of interest (both internal and field-wide) focused on populating SIPREC metadata with an X-ISR-UCID header or a SIPREC extension data field, mainly for purpose of API recording access and control. Currently, there are 2 SPL implementations to address populating the X-ISR-UCID field, one that properly sets the field with a provided UCID/GUID, and another that adds the value as a field in the SIPREC extension data.

The current ISR release has been enhanced to now populate the primary recording X-ISR-UCID field regardless of SPL implementation. However, this has led to confusion with existing integrations.

When the SRC/SBC is configured for both the "AvayaCiscoUCID64" and the "SipHeaderExtensionMetadata.1.2.spl" SPL, the ISR's UCID is now populated in the following order of precedence:
  • X-ISR-UCID (or any other field name configured in the "<Sip><IsrUcidHeaderField>" tag of the RSS configuration file /cxc/vmgConfig.xml), for example: 
    <participant id="hq18GJs3TtJdhjPsfPNV8A=="session="BYiC7uSZQGN3VQdzWI1HWw==">
<nameID aor="sip:sipp@192.168.10.1">
…
<extensiondata xmlns:apkt="http://acmepacket.com/siprec/extensiondata">
…
<apkt:header label="X-ISR-UCID">
<value>X-ISR-UCID-1-150323161627-1979582260@0a0af9f9</value>
</apkt:header>
…
</extensiondata>
  • Third-party UCID, for example: 
    <session id="/Bo3JDljRnZluCz1VhPHeg==">
<associate-time>2016-03-15T01:33:46</associate-time>
<extensiondata xmlns:apkt="http:/acmepacket.com/siprec/extensiondata">
<apkt:ucid>00FA080200000F56E7667A;encoding=hex</apkt:ucid>
<apkt:callerOrig>true</apkt:callerOrig>
  • Note that Call-ID no longer populates X-ISR-UCID automatically, better reflecting behavior in versions prior to 5.1M6. If you prefer to populate the X-ISR-UCID with the Call-ID value, you can edit the /opt/isr/rss/vmgConfig.xml file in the following way: 
    <?xml version="1.0" encoding="UTF-8"?>
<configuration>
…
        <Sip>
…
<IsrUcidHeaderField>Call-ID</IsrUcidHeaderField>
…
        <Sip>
…
</configuration>
    The following is an example value of Call-ID: 
    <participant id="hq18GJs3TtJdhjPsfPNV8A=="session="BYiC7uSZQGN3VQdzWI1HWw==">
<nameID aor="sip:sipp@192.168.10.1">
…
<extensiondata xmlns:apkt="http://acmepacket.com/siprec/extensiondata">
…
<apkt:header label="Call-ID">
<value>1-150323161627-1979582260@0a0af9f9</value>
</apkt:header>
</extensiondata>