1. Configuration Guide
  2. SIP Signaling Services
  3. SIP SIP-I Interworking
  4. Interworking User-Configured IAM Parameters into SIP INVITE Headers

Interworking User-Configured IAM Parameters into SIP INVITE Headers

You can configure the SBC to extract a specific set of ISUP parameters from the IAM message during SIP-I to SIP call processing, and interwork them into SIP headers while generating the SIP INVITE message. This list of IAM parameters can be configured in extract-isup-params parameter of sip-isup-profile.

By default, the SBC does not interwork any IAM parameters. You configure a list of parameters you want to interwork.

The parameters you can extract and interwork include:

  • calling-party-number
  • generic-number
  • location-number
  • user-to-user

You refine the list of parameters by setting the extract-isup-params parameter to add additional parameters, and by setting the remove-isup-params parameter to remove a single parameter from the list.

Keep in mind that the SBC is receiving SIP-I or SIP-T messages that contain encapsulated ISUP information. The SBC is, therefore receiving an INVITE and identifying ISUP parameters within the encapsulated information in each message. The specific operations performed by the SBC for this extraction/interworking are presented below. All operations assume you have configured extraction for the applicable parameter.

Extraction detail is compliant with T-REC-Q.1912.5.

calling-party-number

If the SBC finds a calling-party-number parameter, it interworks that information into a P-Asserted-Id SIP header, as follows:

  • If no P-Asserted-Id header is present in received SIP INVITE, the SBC creates a new P-Asserted-Id with the user part extracted from the calling-party-number and domain name from the FROM URI. The SBC uses the same URI format (SIP, SIPS, TEL and so forth) as is used in the From URI in the SIP INVITE.
  • If there is P-Asserted-Id header, the SBC replaces it with the calling-party-number parameter. If there are multiple P-Asserted-Ids, the SBC removes all instances except the first.
  • If the "nature of address indicator" (NOA) in the calling-party-number indicates "international number" (0000100), the SBC adds a plus sign (+) as a prefix in the URI while generating/modifying the P-Asserted-Id.
  • Interworks any APRI by modifying the Privacy header as follows:
    • If APRI is "Presentation restricted", adds the priv-value "id" to the Privacy header, if not already present.
    • If APRI is "Presentation Allowed" and the priv-value in the Privacy header is already "id" or ''header", remove it. If the priv-value is "user', do not remove it.

generic-number

If the SBC finds the generic-number parameter with the number qualifier indicator set to "additional calling party number", (00000110), it interworks that information into the From URI by replacing the user part of the "From" header URI with the generic-number. The SBC also prefixes the From header with a plus sign (+) if the nature of address (NOA) is set to international.

If there are multiple generic-numbers, the SBC selects the first one with its "number qualifier indicator" set to "additional calling party number".

The SBC also interworks any APRI by modifying the Privacy header as follows:
  • If APRI is "Presentation restricted", adds the priv-value "user" to the Privacy header, if not already present.
  • If APRI is "Presentation Allowed" and the priv-value in the Privacy header is already "user", remove it.

location-number

If the SBC finds a location-number parameter, it interworks it into a P-Access-Network-Information header by removing any exising P-Access-Network-Information and inserting a new one, as follows:

  1. Set Access-type to "GSTN".
  2. Set Operator-specific-GI to the text string between quotes with the sequence of digits found in octet 3 to N (except the filler) starting with the first digit.
  3. Add "network-provided" if the screening indicator in location number is set to "network provided" (11).

user-to-user

If the IAM includes the user-to-user information parameter in the encapsulated IAM message, the SBC interworks this information into a User-to-User SIP header in SIP INVITE as follows:

  1. Extracts the User-To-User-Information parameter (code 32) into the User-To-User SIP header, starting from the protocol discriminator.
  2. Sets the encoding field to "hex" (encoding=hex)
  3. Sets the content field to "isdn-uui" (content=isdn-uui)
  4. Sets the purpose field to "isdn-uui" (purpose=isdn-uui)

Furthermore:

  • The letters used for the hex digits are always capital letter.
  • The SBC removes any existing user-to-user header from the SIP INVITE before adding a new one.

Interworking IAM Information into SIP INVITE History-info Headers

The SBC interworks the Redirecting Number, Called Party Number and Original Called Number from the ISUP IAM message into history-info headers. While interworking these parameters into a History-Info header, the SBC creates a SIP URI containing the "cause" URI parameter, an "hi-index" and an "mp" header field parameter.

Additional operational detail on this interworking includes the SBC:

  • Setting the value of “Unknown User Identity” to “sip:unknown@unknown.invalid”, as defined in 3GPP TS 23.003.
  • Limiting the redirection counter value from 1 to 5. The SBC does not perform interworking if this value is greater than 5, per specification.
  • Using the domain name of the “From” header while generating the URI of the history-info header. If the “From” does not have a domain, such as when there is no from header or the header is in TEL URI format, the SBC uses “unknown.invalid” as the domain.
  • Removing the identified Called Party Number prior to interworking if the last digit is an ‘F’, which indicates ST (Stop Sending), and if the identified number is not that actual Called Party Number.

Furthremore, the SBC follows these rules to populate cause URI parameter values:

  • For placeholder history-info entries, the SBC uses the value 404.
  • For history-info entries created from called party number (using the last HI entry), The SBC populates the cause parameter based on the redirecting reason, shown in the table below.
    Redirecting Reason in Redirection Information Cause
    unknown/not available (0000) 404
    unconditional (0011) 302
    User Busy (0001) 486
    No reply (0010) 408
    Deflection during alerting (0100) 487
    Deflection immediate response (0101) 480
    Mobile subscriber not reachable (0110) 503
  • For history-info entries created from the redirecting number (the penultimate History-info entry), The SBC populates the cause parameter based on the original redirection reason as mentioned in table below, referenced from ITU-T Q.1912.5.
    Original Redirection Reason in Redirection Information Cause
    unknown/not available (0000) 404
    unconditional (0011) 302
    User Busy (0001) 486
    No reply (0010) 408