ll control features of sessions established between two endpoints. Multimedia conferencing to provide a Web application with the possibility to schedule and create multimedia multiparticipant calls and manage them. Rich CS calls, to provide features related with media sharing combined with circuit switched calls. SIP Push, to provide Web applications the ability to push events and contents to IMS terminals. Customized Alerting Tone enables a Web application the control over ringback tones and personalized alerting tones (ringforward tones). Multimedia inbox control. Moving the SDP to the Cloud To expose capabilities, the APIs of the IMS Exposure Layer will implement a resource-oriented model as a basis. That is, the REST philosophy will be utilized to model the APIs for IMS capabilities. Since most IMS services inherit a session ori- entation, some RPC techniques might be added to the basic REST representation in order to obtain a similar result as when modeling telecom services as WebServices. However, REST provides a simpler approach which reduces the entry barrier for Web developers to integrate and utilize telecom service features in Web applica- tions. Most Internet players in the Web 2.0 ecosystem provide APIs utilizing this resource-orientation philosophy. Besides, since REST is naturally stateless, scalability increases in comparison with pure RPC alternatives like SOAP and WebServices. Beyond that, the process- ing for a lightweight option like REST is not comparable to the SOAP computa- tional cost. For the technical realization of the REST APIs of the IMS Exposure Layer, there are several protocol alternatives. Among all of them, the Atom Publishing Protocol or AtomPub is one of the most suitable ones, besides it is a standardized mechanism by the IETF. Figure 3.4 presents an example of the IMS Exposure Layer exposing Presence by means of REST API. In this example, the Presence APIs rely on some of the API Client IMS Exposure Layer Presence GW HTTP-SIP Server HTTP GET (Resource URI) SIP Subscribe 200 O