The SBC supports passing the "jcard" and the "call-reason" parameters received in the "Call-Info" header of the SIP INVITE to the PSX when STIR/SHAKEN is enabled. To support this functionality, the flexVariable type is added to the SIP Adaptor Profile configuration to store up to 16 flex variables received from the PSX as input to the SBC SMM to modify SIP messages on the Egress leg.

Note
  • The SBC supports Call-Info header syntax according to draft-ietf-stir-passport-rcd-14 (Supported specification is ATIS-1000094)
  • If the "jcard" is of the URI scheme, the SBC sends the URI to the PSX. If the "jcard" is of the CID scheme, the SBC parses the MIME body and sends the "vcard" to the PSX.
  • The SBC sends the "jcard" and "call-reason" information to the PSX, only when the "purpose" parameter of the "Call-Info" header is set to "jcard". It is possible to contain several "Call-Info" headers in the SIP message with different "purpose" values such as "logo", "card", "info", and "icon" which the SBC needs to ignore.
  • If multiple "Call-Info" headers with "purpose=jcard" are received, then the SBC chooses the first such "Call-Info" header.
  • The SBC creates call-info and adds it onto the Egress INVITE upon receiving responses from the PSX.
  • The RCD STIR/SHAKEN procedures is applicable on all SBC platforms.
SBC BehaviorPSX Behavior

The SBC sends the "jcard" information only if the size is less than 1024 bytes to the PSX.

  • The SBC drops the "jcard" with a size greater than 1024 bytes.
  • If the "jcard" is not sent, then the call reason information is not sent (1024 bytes includes the inline images as well as other content)

The PSX includes an option to support "rcd" PASSporT extension in the lines of other "ppt" types that are supported by the PSX. By default, this flag is disabled.

  • If the flag is enabled, the PSX supports sending an Identity header with the type "ppt=rcd" in the verification request when present. The same flag is used to sign RCD claims in the future.
  • This flag is not applicable until the draft API is finalized.

The SBC processes the Identity header of type "rcd" and sends it to the PSX (It is assumed that only one Identity header of type "rcd" exists. If multiple such Identity headers exist, then the SBC chooses the first Identity header among them) 

The SBC processes the "ppt" extensions when multiple Identity headers are present according to the following priority:

  1. RPH
  2. SHAKEN
  3. DIV
  4. RCD
  5. Base/Generic "ppt" extensions.

The PSX processes the RCD claims only when the "ppt" with the type "shaken" or "rcd". If the RCD claims are present in other "ppt" types such as "div" and "rph", the PSX ignores such RCD claims. 

  • The PSX extracts the contents of the “icn” key (if present). If not, the "logo" parameter from the "vcard" (for "jcd" claims alone) and send it to the SBC using D+ AVP. 
  • The SBC constructs a Call-Info header with purpose=icon and adds it onto the Egress signaling when receiving the D+ AVP containing the "logo" information.
  • The "call-reason" value is obtained from the information sent by the PSX.
  • The SBC adds the header.

Upon receiving RCD claims (jcl/jcd, logo), the SBC:

  1. Sends/does not send Ingress received "Call-Info" headers.
  2. SBC will also add a new call-info with purpose="icon" if its receive "icn" along with jcl/rcd.
    1. The URI received from the PSX if the claim is "jcl", "purpose=jcard", and the "call-reason" parameter.
    2. The CID received from the PSX if the claim is "jcd", "purpose=jcard", and the "call-reason" parameter, adds the SIP MIME body with the "vcard" information sent by the PSX.
  3. If the logo is also received along with jcl/rcd, the SBC adds new "Call-Info" header with purpose=icon and and the "call-reason" parameter.

The PSX indicates to the SBC upon RCD verification failure. 

  • The RCD verification failure indicates either the "verstat=Validation-Failed" (draft proposal) on the "rcd" PASSporT, or the "verstat=TN-Validation-Failed/No-TN-Validation" on the "shaken" PASSporT(with or without RCD claims).
  • No handling is required at the PSX. The existing behavior at the SBC is applied.


The SBC sends/adds the Call-Info" header with "purpose=jcard,icon" based on the indication received, under the following conditions:

  1. If the PSX sends RCD claims to the SBC, then the SBC gives precedence to these claims and constructs the Call-Info" header with "purpose=jcard/icon" and Egress out. The SBC does not send any Ingress received Call-Info" header with "purpose=jcard/icon".

    Based on the flags "Call-Info transparency" and "send purpose with jcard,icon", the SBC sends Call-Info in the Egress INVITE under the following conditions:

    • When both flags are enabled and the RCD claim is received from the PSX, the SBC sends all Ingress received Call-Info headers except the purpose=jcard/icon in the Egress INVITE, and populates send Call-Info with purpose=jcard/icon based on the RCD claim received from the PSX.
    • When both flags are enabled and no RCD claim is received from the PSX, the SBC sends all Ingress received Call-Info headers in the Egress INVITE.
    • When the "Call-Info transparency" flag is enabled and the "send purpose with jcard,icon" flag is disabled, the SBC sends all Ingress received Call-Info headers except the purpose=jcard/icon in the Egress INVITE.
  2. Either does not send or pass the Ingress RCD Identity header upon receiving the indication.
  3. Runs the privacy procedures upon receiving the Privacy Profile ID from the PSX.
  4. Removes the Call-Info header(s) on the Egress signaling when the "privacy=user" procedures are applied.
  5. Uses the flex variables as input to the SMM to modify the SIP messages on the Egress.

  6. The SBC logs the RCD verification status result if sent by the PSX into the CDRs.

    If any specific RCD claim needs to be logged into the CDRs, the PSX Billing-Info can log the information into the CDRs dynamically.

The PSX provides the following options on RCD Verification Success, RCD Verification Failure, and No RCD Verification and indicates the same to the SBC.

  1. Send Ingress received Identity header of type "ppt=rcd"
  2. Do Not Send Ingress received Identity header of type "ppt=rcd" ( Default: enabled) 

The SBC takes the following actions to support this RCD functionality:

  1. On the ingress side, send the 'Call-Info' header parameters like the 'jcard', 'call-reason', 'icon' to the PSX when present. 

  2. On the egress side, (based on flags sent by the PSX):

    1. Update the "display name" part of the P-Asserted-Identity header and From header based on the "nam" field.
    2. Create Call-Info header with purpose=icon based on "icn" and "crn" field. 
    3. Create Call-Info header with purpose=jcard based on "jcl" field and "crn" fields. 

Sending RCD Information in D+ Request to the PSX:

  • If the Call-Info header with purpose=jcard/icon is received in ingress INVITE, the SBC sends call-reason and jcard/icon information in D+ request.

  • If multiple Call-Info headers with purpose=jcard/icon is received, the SBC considers first Call-Info header with purpose=jcard/icon for sending in D+ request.

  • "Jcard" takes precedence over "Icon" call-info header incase both are having the call-reason parameters.

  • If parsed message body greater than 1024, the SBC does not send call-reason and jcard information in policy request. 

    Modified: for 11.1.1


Based on the control bits and status received, the SBC sends a Display Name, Call-Info, and RCD Identity headers in egress INVITE.

  • Update the "display name" part of the P-Asserted-Identity header and From header based on the "nam" field.
  • Create Call-Info header with purpose=icon based on "icn" and "crn" field. 
  • Create Call-Info header with purpose=jcard based on "jcl" /"jcd" field and "crn" fields. 
  • Identity Header - Phase 2 (As for now, only ingress received identity header is handled based on the bits "Send Ingress received RCD Identity header" and "Do Not Send Ingress received RCD Identity header)".

The PSX sends the following when Handling D+ response: 

  • Call-reason, jcard and logo information in global AVPs.
  • RCD Status and flag information in the DIAMETER_STI_RCD_RSP_STR AVP for each route.
  • In a case of signing, DIAMETER_STI_RCD_SIGNING_RSP_STR (newly added) contains the status and control bits.
  • Since, it is the case of combined Shaken and RCD signing, STI service-Info type is Signing and STI RCD (standalone RCD) service-Info type is None. 

    Modified: for 11.1.1