headers to transparently pass. The flexible header transparency profile supported in earlier release, where transparency for a random header is achieved by adding its name to the profile. The functionality was limited to initial INVITE request, REGISTER request, and mid-dialog requests in an INVITE initiated dialog (excluding a mid-dialog SUBSCRIBE as it is not supported). Selective unknown headers can be passed transparently in REGISTER, initial INVITE, and in mid-dialog requests in an INVITE initiated dialog. Header transparency was not supported for out-of-dialog messages in earlier SBC release. The SBC supports the following out-of-dialog functionality: - To enable transparency for "all" the headers.
- To selectively ignore transparency of headers (useful with "all" transparency).
- To exclude the methods for which transparency of headers is not needed.
| Note |
|---|
| The transparency profile is associated with the egress trunk group. The header transparency is based on the headers that are present in the transparency profile of the egress trunk group for requests and headers that are present in the ingress trunk group for responses. |
| Note |
|---|
| ACK messages are not normally sent end-to-end through SBC. Transparency of ACK messages is not supported even if the |
endToEndAck flag End To End Ack flag is enabled in the "IP Signaling Profile". In late media scenarios, the SBC does not support transparency of headers and bodies. |
Headers be configured configure headers in compact form and transparently passed using a Transparency Profile. It is advisable to configure both compact and long formats to ensure both types of received headers in the PDU are transparently passed. |
|