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

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

  • FAX Detection
  • T.38 FAX IWF
  • RTCP detection
  • 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 ESBC 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 ESBC receives two responses, SHAKEN and DIV signing responses, on which it performs header mapping, the ESBC saves the first response. When it receives the second, the ESBC processes this second response but does not save it. This is also true for any ensuing responses. Finally, the ESBC 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 ESBC to behave and generate the final message, in this case an INVITE. as follows:

    1. The ESBC 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 ESBC 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 ESBC 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 ESBC 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 ESBC has some feature limitations within its DTLS-SRTP implementation. For DTLS-SRTP, the ESBC does not support:

  • The ESBC 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 ESBC 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
  • 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 ESBC 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 ESBC 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 ESBC 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 ESBC 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 ESBC 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 ESBC 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

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

    • If Route1 /Route2 replies with a 302 with 2 contacts, then the ESBC attempts to reach those contacts serially.
    • If both contacts timeout, the ESBC does NOT try the next policy-attributes.
  • Note the ESBC 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)

    ESBC behavior includes:

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

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

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

      If these 2 contacts timeout, the ESBC 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 ESBC tries to reach those 2 contacts serially.

      If these 2 contacts timeout, the ESBC 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.