Static Routes

Next, a static route must be created for a particular matching SIP URI, and then pointed to the trusted application pool as a next hop. This URI is typically a separate SIP namespace, but there is nothing that prevents an organization from using the same SIP URI as used for Lync.

Figure 20.1 demonstrates the logical structure of this integration.

Figure 20.1. Trusted application.

Lync operates similarly to Exchange’s Internal Relay method for an accepted domain with respect to a shared SIP domain. It first attempts to resolve a URI internally, and only if no match is found does it route the call to the third-party system.

The end result is that Lync will send audio or video calls for a matching URI to the trusted application pool as a next hop, which is the third-party system.

The overall process can be simplified with this logical summary and is depicted in Figure 20.2.

1. Lync user [email protected] places a video call to [email protected].

2. Lync determines video.companyabc.com is not an internally supported SIP domain.

3. Lync locates the static route for video.companyabc.com, which points to a next hop defined as videogateway.companyabc.com.

4. Lync forwards the SIP Invite message to videogateway.companyabc.com.

5. The videogateway.companyabc.com device determines that it is authoritative for the video and rings endpoint registered as [email protected].

6. The third-party user [email protected] receives the incoming video call.

Figure 20.2. Static route to a third-party system.

The third-party endpoint can be registered to the signaling gateway via SIP or H.323, depending on the product. The signaling gateway might even accept a mixture of the two protocols among endpoints.