e provided our own mapping that uses existing SIP messages, such as SIP invites, to initiate data sessions. However, it is complex to work between API invocations and SIP messages. As a result, we create software components called SCS clients that facilitate communication between the IMS functions and SCS on its API. These clients reduce complexity by managing state and data needed to move between APIs and SIP messages. Also, the SCS clients distributed, manage lower network events, simulate network events and communi- cate with the SCS and IMS functions across the framework domains. 2.6.4 Results We successfully implemented an SDP using Parlay X, Parlay, and IMS. As shown in Table 2.1 the SDP framework and its GSOAs have overcome the limitations of the generalized SDP framework. Via an IPTV application we also evaluated Parlay X, Parlay, and IMS service enablers as well as there open interfaces for standardiz- ing the SDP. We illustrated gaps with these service enabler standards since we defined and modified specific service enablers and their APIs. The modifications are summarized in Table 2.2. The newly defined or modified service enabler APIs sug- gest that additional specification is required to ensure a complete standards-based SDP when using Parlay X, Parlay, and IMS to implement the GSOAs. We can evaluate other standards-based service enablers and their APIs, by map- ping them onto the SDP framework and implementing the various GSOAs. The mapping and implementation will aid in identifying gaps within these standards and their integration to form a SDP. This process will help telcos when defining and procuring a SDP solution that must integrate into their network and IT systems. Also, vendors can map their SDP architectures against the framework GSOAs to determine their offerings compliance to standards, unique properties and identify any gaps not exploited within their solutions. Therefore, the SDP framework provides an architectural foundation used in building standards-based SDP imple- mentations and ev