1. Configuration Guide
  2. External Policy Servers
  3. 2127 - Configurable Subscription ID Types
  4. Subscriber Information AVP
  5. Subscription-ID AVP
  6. Subscription-Id-Data

Subscription-Id-Data

When applicable, the SBC can send a Subscription-Id-Data AVP (444) to an external policy server. This AVP is contained within the grouped Subscription-Id AVP (443) and carries the user's identifier. You can configure the SBC to refine this data so it gets this information from the SBC and uses your configured value for the subscription-id-type parameter to determine which user identifier it sends.

You must enable the include-sub-info option in an applicable ext-policy-server to send the grouped Subscription-Id AVP, which includes the Subscription-Id-Data AVP, in an AAR towards the PCRF.

In addition to the include-sub-info option and the subscription-id-type parameter, you may need to enable the preferred-sub-id-type option in an ext-policy-server to establish all of the behavior you need for your deployment. Use of the preferred-sub-id-type option is only relevant to registered users.

When enabled, the preferred-sub-id-type option further refines the value of the Subscription-id-Data AVPs for registered users before the SBC sends the Subscription-id AVP towards the PCRF in the AAR. Specifically, when you enable this option, the SBC fetches the user identity from the its cache and determines which ID type it sends in the Subscription-id-Data AVP to be the same type presented in the Subscription-Id-Type (450) and specified by your subscription-id-type configuration in the AAR message.

For example, if you set subscription-id-type to END_USER_IMSI and enable preferred-sub-id-type, the SBC retrieves the IMSI value from the subscriber registration cache, formats it based on the and sends it as the Subscription-Id-data in the grouped AVP within the AAR.

The cumulative effects of these configurations are:

  • Enabling the include-sub-info option causes the SBC to send the Subscription-ID-Types AVP in an AARs.
  • Configuring the subscription-id-type parameter causes the SBC to include your value as the value of the Subscription-ID-Types AVP in AARs.
  • Enabling the preferred-sub-id-type option causes the SBC to retrieve the user identify from its cache that is the same type you configured in the applicable subscription-id-type, thereby specifying and sending the correct value in the Subscription-Id-Data AVP.

Finally, if the SBC does not have the subscriber registration in its cache, it sets the Subscription-Id-Type and Subscription-Id-Data AVP values using the contact header or the Request URI in the request line of the received message.

Important caveats on the use of this feature include:

  • The SBC only caches an IMSI when it is a 14 or 15 digit number.
  • If the incoming data does not correspond to your subscription-id-type value, the SBC sets the Subscription-Id-Type/Data based on the incoming Contact URI/R-URI as a Sip-Uri or Tel-Uri.
  • If you configure the subscription-id-type value to END_USER_NONE, the SBC sets the Subscription-Id-Type/Data based on the incoming Contact URI/R-URI as a Sip-Uri or Tel-Uri.
  • The SBC uses this behavior when you enable the preferred-sub-id-type option in the ext-policy-server applied to either the ingress or the egress realm.
  • The SBC sends subscriber data towards the PCRF based on the realm to which you have applied the ext-policy-server.
    • If applied to the access realm, the SBC sends the calling (west) side subscriber data to the PCRF.
    • If applied to the core realm, the SBC sends the called (east) side subscriber data to the PCRF.