In this section:
The Transparency Profile is the recommended method of configuring transparency on the SBC Core for new deployments as well as when applying additional transparency configurations to existing deployments. Do not use IP Signaling Profile flags in these scenarios because the flags will be retired in upcoming releases.
Refer to the SBC SIP Transparency Implementation Guide for additional information.
The SBC Core interoperates with Unified Communication Servers such as Microsoft Lync, and supports the following features:
Track the availability of peers specified by FQDNs by sending OPTIONS ping requests
FQDN received in Contact headers of mid-dialog SIP messages
The SBC is configurable to support the following functionality:
When the SBC receives a REFER request with a transfer-target specified by an FQDN (in the Refer-To header), it looks up for PSX to route to the target (including the destination Trunk Group). The SBC then places an INVITE to the destination specified by PSX. Similarly, when the SBC receives a 3xx with a contact specified by an FQDN in response to INVITE/SUBSCRIBE, it looks up for PSX to route to the target (including the destination Trunk Group). It then places an INVITE/SUBSCRIBE to the destination specified by PSX. The SBC supports the following scenarios:
The support for SUBSCRIBE does not depend on "forceRequeryForRedirection" flag. But, the support of processing FQDN in 3xx/REFER messages depends upon the "forceRequeryForRedirection" flag.
The SBC supports the following FQDN behavior:
useRouteset
is set to "received", the SBC pulls the route from the route set and routes the INVITE to PSX returned destination gateway.useRouteSet
is set to “received”, the SBC resolves the received FQDN using DNS look-up, and routes the INVITE to the resolved destination.useRouteSet’
is not set to "received", the SBC routes the INVITE to PSX returned destination gateway.The SBC locally responds if either of the following holds true for an OPTIONS received outside of a dialog:
userinfo
in Request-URI and Route Header is absent and the hostname in RURI matches either the domainName
of the local signaling zone or the IpAddress of any sipSigPort
in the Zone.If the flag useZoneLevelDomainNameInContact
is enabled, the SBC sends the local domainName
in contact header for all outgoing messages.
All requests and responses relayed in registration context (SUBSCRIBE, REFER, NOTIFY and so on)
If passCompleteContactHeader
transparency flag is enabled, contact header is passed transparently irrespective of setting of flag useZoneDomainInContact.
If transparency for contact header is enabled via IP Signaling Profile flags or by using the Header Transparency Profile, it takes precedence over the Use Zone Domain in Contact
flag.
The SBC sends some locally generated requests like BYE, PRACK, ACK, INFO, OPTIONS and its responses without Contact header. This behavior is retained irrespective of the Use Zone Domain in Contact
flag setting.
A Lync 2013 video call requires a unique FQDN to identify the SBC Core. This FQDN is different from the one used by the Mediation server for normal audio-only calls. Since the SBC requires two FQDNs to place both audio and video calls on Lync using a static route from Lync FE (Front End), the SBC local certificate must contain both FQDNs for CN and SAN for a successful TLS connection between Lync and the SBC.