As the co-author of the Session Initiation Protocol specification, I am frequently asked about the “hot new services” SIP enables. My answer invariably begins with an explanation of how SIP can enable many new services. Right now, Fixed Mobile Convergence (FMC) is one of the hottest SIP services. FMC is interesting in that it is a highly compelling application, and it also shows off some of the key tenets of SIP’s architectural philosophy.

What Is FMC?
Its definition varies somewhat depending on the context. Sometimes it refers to a unified service offering where a subscriber has a fixed-line phone and a mobile device from the same provider, both devices sharing a single phone number. More commonly it refers to a service that uses a dual-mode client that supports some kind of traditional 2G cellular voice access, such as CDMA or GSM, in addition to broadband IP, typically through Wi-Fi. The phone can seamlessly roam from the 2G cellular network onto Wi-Fi and back, handing off calls as the user travels. The benefits to subscribers include increased network coverage (especially in the home or office, where Wi-Fi is nearly ubiquitous but cellular coverage sometimes isn’t), the ability to roam internationally (anywhere there is Wi-Fi) and possibly lower service costs. There are many ways to realize FMC. One of them is with Unlicensed Mobile Access (UMA), which tries to make the Wi-Fi network look like the cellular network from a protocol perspective. The more interesting approach is to use SIP. Technically speaking, the SIP approach is fascinating because it’s a great example of SIP’s component architecture. The SIP component architecture says that, instead of standardizing specific services and features, you define a set of coarse-grained call control primitives, and then build up complex services by combining those primitives together. Despite the apparent complexity of the service, FMC doesn’t require any extensions to the SIP at all. Though it was not envisioned or considered at all during SIP’s design, the existing set of SIP call control primitives can be combined to realize FMC.

How It Works
The FMC service is typically realized through an application server, which I’ll call an FMC server for simplicity’s sake. When a user on the PSTN or in the SIP network calls the FMC subscriber, the call is routed to the FMC server where it is anchored. The call is routed to the FMC server using SIP’s loose routing capabilities. Once there, anchoring is achieved by having the FMC server act as a Back-to-Back User Agent (B2BUA), which re-initiates the call toward the FMC subscriber. The FMC server can route the call into the cellular network or to the SIP User Agent (UA) on the dual-mode device. To decide which, it can learn about availability of the SIP UA by checking registration status, either through receipt of third-party SIP registrations, or through the Registration Event Package (RFC 3680). To achieve handoff, when the FMC subscriber moves from cellular to Wi-Fi, the UA initiates an INVITE toward a service URI. This URI routes the call to the FMC server. The FMC server, acting as a B2BUA, uses third-party call control primitives to move the media stream to the Wi-Fi endpoint and terminate the call leg pointing into the cellular network. The operation works similarly for handoff from Wi-Fi to cellular.

Many of SIP’s component functionalities are used to realize FMC. These include:

Loose Routing — Used to route calls to the FMC server and back out.

Event Packages — The Registration Event Package can be used by the FMC server to learn registration status on the IP network.

Service URI — Introduced in RFC 3087, it defines the notion of a URI being used to represent a service, and constructing it in such a way that service parameters are part of the URI. The service URI here represents a handoff service, and the parameters are the context needed by the FMC server to identify the call(s) to be handed off.

Third-Party Call Control (3pcc) — Defined in RFC 3725, it introduces several primitive call flows for manipulating dialogs from a central server. These are used extensively by the FMC server.

It’s important to note that, although FMC doesn’t require extensions to SIP per se, it does require standards work in order to provide interoperability. Here, the standards work that is needed is the definition of the behavior of the FMC server when it receives requests with specific SIP URI, triggering either handoff or anchoring. Once defined, the FMC server becomes another component that can be used, in turn, to realize even more complex services where it is but a single component. In this way, the FMC becomes part of the “library of primitives” that makemakes up the SIP toolbox. Here, it’s not a SIP extension, but rather a server with well-defined behaviors. Indeed, many standardized servers have been defined over the years. Another example of such a standardized server component is the focus, defined as the signaling center point in SIP conferences (see draft-ietf-sipping-conference-framework), and transcoding servers, defined in RFC 4117.

As FMC services roll out this year and next, I’ll be one of the first to sign up. I’ll get it because I think the service itself is really cool, but also because I know it’ll be a great example of the philosophy that I and others have worked hard to promote as the SIP way of innovating telecommunications.