Internet DRAFT - draft-deason-sipping-soap-sessions
draft-deason-sipping-soap-sessions
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, <http://www.w3.org/TR/SOAP/>.
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
