1. Known Issues and Caveats
  2. Known Issues and Caveats
  3. Limitations

Limitations

The following information lists and describes the limitations for this release. Oracle updates this Release Notes document to distribute issue status changes. Check the latest revisions of this document to stay informed about these issues.

Transcoding Limitations on the Acme Packet 4900

The Acme Packet 4900 does not support 40 and 60 packetization times for the EVS codec.

Virtual Network Function (VNF) Limitations

SBC functions not available in VNF deployments of this release include:

  • FAX Detection
  • T.38 FAX IWF
  • LI-PCOM
  • H.323 signaling or H.323-SIP inter-working
  • ARIA Cipher

Packet Trace Limitations

  • Output from the packet-trace local command on hardware platforms running this software version may display invalid MAC addresses for signaling packets.
  • The packet-trace remote command does not work with IPv6.
  • If any conflicting applications are enabled, the packet-trace command displays a warning. Conflicting applications are comm-monitor, call-trace, and SIP Monitor and Trace.

Fragmented SIP Message Limitations

Fragmented SIP messages are intercepted but not forwarded to the X2 server if IKEv1/IPsec tunnels are configured as transport mode.

Workaround: Configure IKEv1/IPsec tunnels as "tunnel mode".

Header Mapping Limitations

This version of the includes the following limitations to the header mapping feature:

  • Indexing is not supported for HTTP headers.

    Per the Section 4.2 of RFC 2616, Multiple message-header fields with the same field-name may be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list. But, because indexing is not supported, the following configuration is not supported:

    • When the direction is outbound, the target-header field (HTTP header) does not support indexing and subscript.
    • When the direction is inbound, source-header (HTTP header) field does not support indexing and subscript.

    If you configure either of the above, the SBC displays an error at the ACLI when you run the done command on the applicable mapping-rules instance.

  • If you are using 3GPP mode and the SBC receives two responses, SHAKEN and DIV signing responses, on which it performs header mapping, the SBC saves the first response. When it receives the second, the SBC processes this second response but does not save it. This is also true for any ensuing responses. Finally, the SBC processes the saved response, which can result in the system replacing the last mapping with the saved mapping.

    Consider the following mapping ruleset and the steps below to understand what to expect in an INVITE after the mapping processing is completed:

    sti-header-mapping-ruleset
          name                                    ruleset1
          mapping-rules
            id                                    HttpToSip
            source-header                         X-Test-Id
            target-header                         Test-Id
            direction                             inbound
            role                                  STI-AS

    This processing causes the SBC to behave and generate the final message, in this case an INVITE. as follows:

    1. The SBC receives a SHAKEN Signing Response received with an X-Test-Id header and a value of 123.
    2. The system saves this response and waits.
    3. The SBC receives a DIV Signing Response with an X-Test-Id and a value of 345.
    4. The system processes the DIV response first, because it was received last, and applies the mapping. The system adds a new header to the egress INVITE called Test-Id: 345.
    5. The system processes the SHAKEN response next, and applies the mapping. This time, the system replaces the existing header with a header called Test-Id: 123 in the INVITE.
    6. The system forwards the completed INVITE.
  • For authentication scenarios, after receiving a response from the STI-AS, the SBC removes any previous signaling before sending the INVITE out. It does so by removing the following four headers, if present in the ingress INVITE:
    • Attestation-Info
    • P-Attestation-Info
    • Origination-Id
    • P-Origination-Id

    But the SBC only deletes the first occurrence of these headers. This results in an issue during AS inbound (HTTP to SIP) mapping. Specifically, when you configure digits greater than 0 in the subscript operator, the system may process the wrong header if one of these headers is removed before applying the mapping rules.

DTLS-SRTP Limitations

This version of the SBC has some feature limitations within its DTLS-SRTP implementation. For DTLS-SRTP, the SBC does not support:

  • The SBC operating as a DTLS client.

    Note:

    You can only configure the system for passive setup
  • Complete security of media streams using integrity protection, as defined in section 3 of RFC 5764.
  • Conference specific functions, such as RTP mixing
  • Re-keying
  • DTLS-SRTP in SBC ICE Lite mode
  • Hairpin call scenarios
  • The “use_srtp” extension with non-zero MKI value
  • Multiple media lines of the same media type, with one of them being DTLS

    Note:

    Calls that establish multiple media sessions for different media types, audio and video for example, are supported.
  • Detection of the “two-time pad” SRTP error (per section 3 of RFC 5764)
  • Attended transfer
  • The SBC does not support the AEAD_AES_256_GCM cipher on hardware datapath platforms.
  • DTLS-SRTP calls with RTP/RTCP flows that are not multiplexed. This limitation generates a requirement and several behaviors:
    • Requirement - You must enable the rtcp-mux parameter on each realm that has a valid dtls-srtp-profile.
    • Behavior - The SBC replies with a "488 Not Acceptable Here" response if it receives an initial INVITE that includes DTLS-SRTP attributes, but does not include the rtcp-mux attribute.
    • Behavior - If the SBC receives a 200 OK, a 180 ringing, or a 183 session progress from a callee that includes DTLS-SRTP attributes, but does not include the rtcp-mux attribute., the system sends a BYE to the callee and a “503 service unavailable” message to the caller.
    • Behavior - If the SBC receives an ACK from a caller that is in response to a delayed offer SDP from a callee, and that ACK does not include the rtcp-mux attribute., the system:
      1. Sends an ACK to the callee to acknowledge the 200 OK with the delayed offer.
      2. Sends a BYE to both the caller and callee to terminate the call.

DTLS-SRTP Platform Support

The SBC supports DTLS-SRTP on the following platforms:

  • AP1100
  • AP3900
  • AP3950
  • AP4900
  • AP6350—Platform support as of S-Cz9.2.0p1
  • vSBC deployment over:
    • KVM
    • VMware
    • OCI
    • AWS
    • Azure

Parallel Forking Limitations

This version of the SBC includes the following limitations to its parallel forking support:

  • If you configure two MS Teams destinations for parallel-forking, and one of them supports MS Teams LMO feature while other destination doesn’t supports MS Teams LMO feature, then parallel forking call flows will not be supported.
  • SRVCC handover calls are not supported within parallel forking call flows
  • SIP to SIP-I interworking is not supported within parallel forking call flows
  • SIPREC calls are not supported within parallel forking call flows
  • All merge-early-dialogs limitations apply to parallel forking call flows, including:
    • Offerless call
    • Preconditions interworking
    • SRVCC
    • multiple audio or video m-line
    • p-early-media-header with 'add' and 'modify' options
  • If the SBC receives an INVITE with its req-uri in the format "username@FQDN:port" and the applicable routes include:
    • Route1 (IP1) – cost 5 – parallel-forking enabled
    • Route2 (IP2) – cost 5 – parallel-forking enabled

    SBC behavior when Route1 or Route2 return 302 messages with multiple contacts:

    • If Route1 /Route2 replies with a 302 with 2 contacts, then the SBC attempts to reach those contacts serially.
    • If both contacts timeout, the SBC does NOT try the next policy-attributes.
  • Note the SBC behavior when the routes are configured as below:
    • Route1 (IP1) – cost 5 – parallel-forking enabled
    • Route2 (FQDN) – cost 5 – parallel-forking enabled
    • Route3 (IP3) – cost 5 – parallel-forking enabled
    • DNS resolution of FQDN for Route2 returns 3 IPs (IPx, IPy, IPz)

    SBC behavior includes:

    • If the UAC sends an INVITE with req-uri as username@IP:port, the SBC forks the INVITE to Route1 and Route2 in parallel. If Route 2 replies to the INVITE with a 302 that includes 2 contacts, the SBC tries to reach those 2 contacts serially.

      If these 2 contacts timeout/18x timeout/error response, the SBC tries the next policy-attributes.

    • If the UAC sends an INVITE with number@FQDN, and IPx replies to the subsequent INVITE from the SBC with a 302 with 2 contacts, the SBC tries to reach those 2 contacts serially.

      If these 2 contacts timeout, the SBC does not attempt to reach any further DNS resolutions or next policy-attributes.

    • If the UAC sends an INVITE with number@IP:port, and IPx responds to the INVITE with a 302 with 2 contacts, the SBC tries to reach those 2 contacts serially.

      If these 2 contacts timeout, the SBC does not try to reach any further DNS resolutions, but does try to reach next policy-attributes.

Playback Headers and Hairpin Calls

Playback headers are not supported for hairpin calls.