MS Lync FQDN Support

The SBC Core interoperates with Unified Communication Servers such as Microsoft Lync, and supports the following features:

• Associate a Fully Qualified Domain Name (FQDN) with each SBC signaling zone

• Track the availability of peers specified by FQDNs by sending OPTIONS ping requests

• FQDN received in Contact headers of mid-dialog SIP messages

• FQDN received in contact header of 3xx response to INVITE
• FQDN received in Refer-To header of REFER message
• FQDN received in contact header of 3xx response to SUBSCRIBE
• FQDN received in Route header of INVITE
• Sending FQDN in contact header of the messages sent by the SBC

Track Availability of Peers Specified by FQDN

The SBC is configurable to support the following functionality:

• Resolves FQDN of an IP Peer to the IP addresses of its SIP servers using A/AAAA queries to DNS.
• Periodically pings each server of the IP Peer and checks if the peer is available, and set the Request-URI of the outgoing Options ping requests to the FQDN of the IP Peer being pinged.
• Displays the current status of a FQDN IP peer. When queried from the CLI, the SBC classifies the FQDN IP peer as "up" if any of the peer’s servers are available. Alternatively, it classifies the FQDN IP peer as "down"  if all of the peer’s servers are unavailable.
• Raises an SNMP trap (and alarm), and adds it to the Address Reachability Service (ARS) blacklist if a peer specified by an FQDN becomes unavailable. Raises another 'clearing' trap (and alarm) when the peer becomes available again. The SBC also passes the FQDN, port and zone of the peer in these traps.
• Raises/clears the traps when individual IP endpoints that an FQDN resolves becomes unavailable/available. The SBC passes the IP/port of the endpoint, FQDN and zone of the corresponding peer in these traps.
• Picks up any change to the peer’s set of servers published through DNS as soon as the corresponding DNS record expires.
• While placing calls to the Peer, the SBC checks the Peer's status in ARS. The SBC does not place calls to a Peer-Servers which are down.
• Removes any Peer-Server that was earlier blacklisted by Pathcheck and is no longer a part of the peer’s set of servers in DNS.

Support Targets Specified by FQDN

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:

• If the FQDN in the Refer-To/Contact of 3xx header matches the Zone Level FQDN of SBC, the INVITE/SUBSCRIBE is sent out to the destination specified by the PSX.
• If the FQDN in the Refer-To/Contact of 3xx header does not match the Zone Level FQDN of the SBC and if the "Route using Received FQDN" flag is disabled, the INVITE/SUBSCRIBE is sent out to the destination specified by the PSX.
• If the FQDN in the Refer-To/Contact of 3xx header does not match the Zone Level FQDN of the SBC and if the "Route using Received FQDN" flag is enabled, the INVITE/SUBSCRIBE is sent out to the destination specified by the Refer-To/Contact header (that is, to the IP address that DNS resolves it to). The destination of the INVITE/SUBSCRIBE is not affected by the value of the ‘Preserve Ingress R-URI Domain Name’ flag.
• For a redirection response, the modified behavior is applied only if the ‘Force Re-query for Redirection’ flag is enabled in the IPSP.

FQDN Support in Route Header

The SBC supports the following FQDN behavior:

• If the FQDN in topmost route header matches zone level FQDN and the parameter useRouteset is set to "received", the SBC pulls the route from the route set and routes the INVITE to PSX returned destination gateway.
• If the FQDN in topmost route header does not match configured zone level FQDN, and if useRouteSet is set to “received”, the SBC resolves the received FQDN using DNS look-up, and routes the INVITE to the resolved destination.
• If useRouteSet’ is not set to "received", the SBC routes the INVITE to PSX returned destination gateway.

Respond to Incoming OPTIONS Pings

The SBC locally responds if either of the following holds true for an OPTIONS received outside of a dialog:

• Max-Forwards is zero.
• If 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.

Support Sending FQDN in Contact Header

If the flag useZoneLevelDomainNameInContact is enabled, the SBC sends the local domainName in contact header for all outgoing messages.

• Initial INVITE and its responses (18x,2xx,4xx-6xx)
• In Dialog messages (OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE, INVITE, PUBLISH, UPDATE) and their responses
• Out-of-dialog requests (NOTIFY, SUBSCRIBE, OPTIONS. MESSAGE, PUBLISH, REFER) and their responses

• All requests and responses relayed in registration context (SUBSCRIBE, REFER, NOTIFY and so on)

• Register request (not applicable for REGISTER response)

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.

Unique FQDN for Video

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.