Internet Engineering Task Force N. Deason Internet Draft Ubiquity Software draft-deason-sipping-soap-sessions-00.txt Corporation Ltd. 23 April 2002 Expires: October 2002 SIP for SOAP Sessions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document describes how Session Initiation Protocol (SIP) can be used to create, modify and terminate sessions of Simple Object Access Protocol (SOAP) messages transported over IM Transport Protocol (IMTP). 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Introduction Session Initiation Protocol (SIP) [3] is an application-layer control protocol for creating, modifying and terminating sessions. Simple Object Access Protocol (SOAP) [4] is a lightweight XML protocol for the exchange of information in a decentralized, distributed environment. SOAP defines a XML vocabulary for encoding Deason 1 SIP-SOAP-Sessions April 23, 2002 messages. SOAP messaging most commonly uses HTTP as a transport protocol. However, the definition of the SOAP XML vocabulary is transport independent. IM Transport Protocol (IMTP) [5] is a subset of SIP which only runs over reliable, congestion controlled transports, such as TCP or SCTP. This document describes how applications can be supported that use SIP to create, modify and terminate sessions of SOAP messages transported over IMTP. 4. Motivation for using SIP for SOAP sessions SIP and SOAP are clearly compatible technologies. Both are geared towards the delivery of services through the use of Internet technology. The architecture for the delivery of these services is recognized as being one of a highly distributed and decentralized nature [6]. Within such a framework SOAP is ideal for customizable exchanges of information. SIP meanwhile can provide the capability of component discovery, session duration, and control. The basic challenge behind transporting SOAP messages is delivery to the correct destination. The application layer routing provided by SIP is directly applicable to achieving this. The primary purpose of SIP is a rendezvous function to deliver a message from the sender to a recipient regardless of where either party resides. Significantly when the desired destination of a SOAP message is primarily a SIP entity, using HTTP for transport would require a mapping of the SIP to HTTP namespaces. In the past, to overcome the lack of such a namespace mapping, SIP itself has been contemplated as the transport protocol for SOAP messages. However, there are potential deficiencies to this approach. If SOAP message sessions are run over SIP, which is then in turn layered on top of UDP, issues arise with network congestion control, packet fragmentation and NAT/firewall traversal. Interestingly these are the same problems that have been encountered for instant messaging sessions over SIP. It is the author’s belief that the same proposed solution to that problem may be reapplied here. Instead of using SIP to transport SOAP messages it should be used to control SOAP message sessions, while IMTP [7] is used as the transport protocol. 5. Example Usage The following example shows a SIP INVITE message that could be sent from a SIP services platform, which wants to broker a call to a conferencing service. In doing this the service platform creates a multi-modal session with the conference bridge. This session Deason 2 SIP-SOAP-Sessions April 23, 2002 consists of an audio session between the bridge and the caller, plus a SOAP over IMTP session for control and event reporting between the bridge and the services platform. INVITE sip:conf83245@bridge.ubiquity.net SIP/2.0 To: sip:sales_conference@ubiquity.net From: 8dsf4i13@asb.ubiquity.net Call-ID: fd835c@195.217.169.6 Via: SIP/2.0/TCP 195.217.169.6:5060 CSeq: 1 INVITE Content-Type: application/sdp Content-Length: ... v=0 o=servicebroker 2890844526 2890842807 IN IP4 asb.ubiquity.net s=Conference Service t=0 0 m=audio 5004 RTP/AVP 0 c=IN IP4 131.160.1.112 a=rtpmap:0 PCMU/8000 m=message 49172 IMTP/TCP application/soap+xml c=IN IP4 asb.ubiquity.net a=direction:both a=wsdl:http://schemas.ubiquity.net/conferencecontrol.wsdl 6. Security Considerations Using SIP for SOAP sessions does not require any new security capabilities to be added to SIP. It is expected that security mechanisms already described by SIP will be of value for reuse when controlling SOAP sessions. 7. Future Considerations This draft is intended as an informational piece of work for discussion in the SIP community. Any future path for it within the IETF is left undetermined. Opinions are solicited from the community to the author. 8. References 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 Deason 3 SIP-SOAP-Sessions April 23, 2002 3 M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol" Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, Mar. 1999 4 World Wide Web Consortium, "Simple Object Access Protocol (SOAP) 1.1", May 2000, . 5 J. Rosenberg, C. Huitema, R. Osborne, A. Houri, “A Proposal for IM Transport”, Internet Draft, Internet Engineering Task Force, November 2001, Work in progress. 6 J. Rosenberg, P. Mataga, H. Schulzrinne, “An Application Server Component Architecture for SIP”, Internet Draft, Internet Engineering Task Force, March 2001, Work in progress. 9. Author's Addresses Neil Deason Ubiquity Software Corporation Ubiquity House Langstone Park Newport United Kingdom NP18 2LH Phone: +44 1633 765 600 Email: ndeason@ubiquity.net Deason 4