ement the IPTV application and required service enablers is shown in Figure 2.6. To ease the development of the IPTV application we reused, rather than rebuild, a collection of standard-based service enablers that provide functions to make voice calls, send messages, and manage presence. These enablers include the Parlay X Web services and Parlay SCFs. The Web services included the third- party call [22], presence [23], and messaging [24] Web services. These Web ser- vices abstract the Parlay call control [25], presence and availability [26], and user interaction [27] SCFs, respectively. By using Parlay X Web services, the SDP offers a set of service enablers to external IT-using enterprises. For the IPTV application these enterprises included IPTV application providers and television media providers. We could not identify a standardized Parlay X Web service to manage the deliv- ery of television content to end-users. However, Parlay provides a data session con- trol SCF [28] that can be reused to deliver content within a data session. Currently, the SCF API is limited and provides basic functions to manage network data ses- sions that have already been set up by network functions. Hence, we modify the data session SCF API to initiate, control, and manipulate data sessions within the network for content delivery purposes. Using Parlay X principles we abstract the modified SCF to define our own content delivery Web service. Table 2.2 provides details on service enablers, their APIs, and our modifications to implement the IPTV application across the SDP framework. Figure 2.6 also shows gaps where no service enablers are defined. These gaps are evident in layer and domain intersections such as where the intermediate service layer and complex service layer meet the end-user domain, service subscription domain and enterprise domain. This represents areas of concern since customized service enablers and interfaces were created to support the IPTV application, and also to consistently support the abstraction hierarchy b