One document matched: draft-rosenberg-simple-message-session-00.txt
Internet Engineering Task Force SIMPLE WG
Internet Draft J.Rosenberg
dynamicsoft
draft-rosenberg-simple-message-session-00.txt
May 2, 2002
Expires: November 2002
Using MESSAGE for IM Sessions
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
The SIMPLE working group has been debating the issue of the IM
session model for quite some time. The primary issue is what
transport to use for the IMs once the session is established with
SIP. Proposals have included the SIP MESSAGE request itself, IMSX,
and a SIP spin-off, called IMTP. The usage of SIP MESSAGE, the very
first proposal, had been rejected by the group because of several
technical issues. This document revists that decision, based on the
recent enhancements made to SIP itself. We believe that SIP MESSAGE
now represents the ideal transport choice for the IM session model.
J.Rosenberg [Page 1]
Internet Draft MESSAGE sessions May 2, 2002
Table of Contents
1 Introduction ........................................ 3
2 History ............................................. 3
3 Proposal ............................................ 5
4 Benefits ............................................ 7
5 Example ............................................. 8
6 The Bigger Picture .................................. 8
7 Author's Addresses .................................. 9
8 Normative References ................................ 9
9 Informative References .............................. 9
J.Rosenberg [Page 2]
Internet Draft MESSAGE sessions May 2, 2002
1 Introduction
Within the SIMPLE group, two models of IM operation are under
discussion. One is the "paging" model of operation [1]. In this mode,
each IM is sent as an independent message using the SIP MESSAGE
method. There is no setup or session establishment needed to send a
message. There is no notion of a session or persistent conversation.
The paging model mimicks the operation of SMS in wireless networks
today.
The second model of operation is the "session" model. In this model,
the IM traffic is viewed as a "media stream" which is part of a
session established with SIP. Before communication, a SIP INVITE
would be used to set up the session [2], and the IM stream would be
described using the SDP [3] carried in that INVITE. When the
communications are terminated, a BYE would be sent. The session model
offers many advantages, mainly in the ability to apply many other SIP
extensions, such as third party call control [4], multiparty
conferencing [5], and preconditions [6] to IM in the same way they
would be applied to voice or video calls.
The missing piece of the session model is this: what transport is to
be used to carry the IMs? Is it RTP [7]? Is it the SIP MESSAGE
method? This subject has been the source of much debate. In this
document, we review this history of this problem, focusing on the
initial proposal of the MESSAGE request, followed by the compromise
IMTP protocol. Then, we propose a MESSAGE solution that uses loose
routing, and show how it solves the problems with the prior two
proposals. We then give some call flow examples.
2 History
When the initial concept of the IM session model was proposed, the
MESSAGE method was the assumed transport for IMs within the session.
The SDP in the INVITE and in the 200 OK would contain a URI for
sending the IM. This URI would generally be a contact URI for each
endpoint, but could also be an address of record, or contain a series
of route headers as URI parameters, learned from record-route, for
example.
After some investigation, problems were found with this approach. The
problems were:
Forking: Since the MESSAGE was sent as a regular SIP request,
there was nothing that could prevent a proxy from forking
this request. Forking an IM in the session model didn't
make sense. The IM should clearly be delivered to the peer
in then session, and no one else.
J.Rosenberg [Page 3]
Internet Draft MESSAGE sessions May 2, 2002
Redirection: There was no clear way to prevent a session MESSAGE
from getting redirected. This could prevent it from being
delivered to the session peer.
Record-Routing: Could the MESSAGE requests themselves be
record-routed? Would such a route override the original
route that the request used?
Separate Paths: There was a strong desire to decouple the path
of proxies used for the signaling, from those possibly used
as intermediaries for the MESSAGE requests comprising the
session. It was not clear how to accomplish this goal with
the proposal.
Congestion Control: There was general agreement that IMs in the
session model should use congestion control. This implies
end-to-end TCP. However, a regular SIP request will
normally use UDP. There was no clear way to prevent a
MESSAGE request within a session from traversing a UDP hop.
However, despite these drawbacks, there were clear benefits to using
MESSAGE. Proxies could serve as useful intermediaries, providing a
solution for firewall and NAT traversal. It would allow a unified
treatment of the page and session modes, which was desirable. It
provided much of the features that were needed - MIME carriage,
sender and recipient identification, and subject and date headers,
for example.
The general observation was that SIP MESSAGE provided the necessary
features, but SIP itself was too feature rich. It had capabilities,
such as forking, redirection and record-routing, which appeared to
get in the way of proper operation in the session model.
This led to a compromise proposal - the IM Transport Protocol (IMTP)
[8]. This protocol was a proper subset of SIP, but with lots of
features removed. There was only TCP, for example. Forking,
redirection, and record-routing were removed. This meant that IMTP
had the benefits of MESSAGE for the session model (unified
page/session treatment, and the ability to use proxies for
intermediaries), but without the drawbacks above, since the unneeded
features were removed. Proxies could be used as IMTP intermediaries
if properly configured (record-routing turned off, TCP only, etc.).
However, IMTP had some problems of its own. First, since it was a
separate protocol, the protocol name in the requests was changed from
SIP/2.0 to IMTP/1.0. This meant that there would be interop problems
if a SIP proxy was to play the role of an IMTP intermediary. If the
name SIP/2.0 was retained, we might not be able to guarantee that the
J.Rosenberg [Page 4]
Internet Draft MESSAGE sessions May 2, 2002
appropriate configuration was being used. The most serious problem
was that it was undesirable to have a separate specification that was
"almost SIP". What would happen if these were inconsistent? How would
it evolve as SIP went to draft?
Additional proposals were sought. The BEEP community contributed the
IMSX protocol [9]. There was some concern at IETF 53 that IMSX
replicated many of the negotiation features of SIP itself.
3 Proposal
We have observed that a lot has changed in the SIP protocol since the
original MESSAGE proposal was made. The most important change is the
loose routing capabilities which have been added to SIP. It is our
belief that these capabilities, properly utilized, make the usage of
the MESSAGE request as an IM transport in the session model viable
once more.
The approach is straightforward. When a UAC wishes to initiate an IM
session, it sends a standard SIP INVITE. The SDP in the body
indicates a stream of type message, with a transport of SIP. The c
line and port fields of the SDP provide the address to where the IMs
should be sent on the UAC. There is also a new "user" SDP attribute,
which provides additional addressing. Effectively, the combination of
the c line, m line port, and the "user" attribute, are used to create
a SIP URI that identifies the UA where IM requests are to be sent. An
example INVITE would look like:
INVITE sip:callee@example.com SIP/2.0
Content-Type: application/sdp
Content-Length: ...
v=0
o=bob 2890844730 2890844732 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=message 54344 SIP/TCP
a=user:bob
The INVITE is processed normally by proxies. However, some proxy on
the path might decide that the messaging stream needs to pass through
an intermediary. To do that, it modifies the SDP, adding a "hop"
attribute, containing a SIP URI for the hop. This URI need not be the
URI of the proxy at all, but MUST always have a transport of TCP.
J.Rosenberg [Page 5]
Internet Draft MESSAGE sessions May 2, 2002
Furthermore, the proxy that inserts this URI need not record-route.
An example of a MESSAGE request modified in this fashion is:
INVITE sip:callee@example.com SIP/2.0
Content-Type: application/sdp
Content-Length: ...
v=0
o=bob 2890844730 2890844732 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=message 54344 SIP
a=user:bob
a=hop:sip:relay.example.com;transport=tcp;lr
In this case, the proxy has requested that the MESSAGE requests flow
through sip:relay.example.com. These hop attributes can be added by
each proxy that the request passes through. New hops are added on top
of the existing set. A proxy could even insert multiple hop
attributes.
When the request arrives at the UAS, the UAS sends a 200 OK as
normal. This 200 OK would have an SDP structured identically to the
SDP in the INVITE. Proxies along the path of the 200 OK could insert
hop attributes, as they did for the INVITE. The result is that both
the UAC and UAS will learn, through the SDP, the address of the
ultimate recipient (from the user, m, and c lines), along with URI of
hops along the way that must be traversed. Both UAC and UAS will then
construct a route set from the hop headers, and use that to populate
a Route set in MESSAGE requests sent within the session. The request
URI is constructed from the user attribute, m, and c lines of the
SDP, and thus points to the ultimate recipient.
As an example, if the INVITE fragment above were received by the UAS,
an IM sent to the caller might look like, in part:
MESSAGE sip:bob@host.example.com:54344;transport=tcp SIP/2.0
Route: sip:relay.example.com;transport=tcp;transport=tcp;lr
Content-Type: text/plain
Content-Length: ...
Hey!
J.Rosenberg [Page 6]
Internet Draft MESSAGE sessions May 2, 2002
Based on the loose routing techniques of bis, this request would
first visit sip:relay.example.com, which would strip that Route
header before sending it on to sip:bob@host.example.com.
4 Benefits
We believe our proposal resolves all of the identified problems with
the original MESSAGE approach:
Forking: In bis, it is clearly stated that the location service
cannot be executed if the proxy does not have control over
the domain in the request URI. In the MESSAGE requests
above, the domain in the request URI is that provided by
the UA in fields of the SDP. This will either be the IP
address of their host, or their FQDN. No proxy owns that
domain, only the UA does. Forking can only occur when the
location service is executed. Therefore, the request will
never fork through any bis compliant proxy.
Redirection: This will never occur either, for the same reason
that forking will never occur.
Record-Routing: Record-routes from the MESSAGE, if present, are
always ignored. The route for the MESSAGE requests is
learned from the SDP.
Separate Paths: The path of subsequent SIP requests in the
dialog is determined from the record-route headers. The
path of MESSAGE requests in the IM session is determined
from the hop headers in the SDP. These are unrelated. Thus,
the two paths are completely independent.
Congestion Control: Proxies are forced by the specification to
place URI in the "hop" attribute that indicates a
congestion controlled transport. Furthermore, a UA would
construct the route set using the transport=tcp parameter
if none was provided in the hop attribute. This means that,
in order for the MESSAGE path to use a non-congestion
controlled hop, BOTH a UA and a proxy would need to be
misimplemented or conspire to violate the spec.
Additionally, this proposal does not define a new protocol. It merely
defines some new SDP attributes that enable a particular usage of the
MESSAGE request for session model. Thus, there are no issues with
diversion of specifications, as there were with IMTP. There are also
no interoperability issues beyond bis, or the potential for problems
in the face of misconfiguration.
J.Rosenberg [Page 7]
Internet Draft MESSAGE sessions May 2, 2002
An even bigger benefit is the elimination of state. In the IMTP
proposal, the proxy needed to install forwarding state in the relay,
through a REGISTER request. Now, such state is no longer needed. The
forwarding state is encapsulated in the loose Route headers stored by
the UA. This avoids the fate sharing problem of the IMTP approach.
5 Example
Figure 1 provides a more detailed call flow example. In step 1, the
caller sends an INVITE to its proxy. The SDP indicates a message
session. The c line provides an IP address of 1.2.3.4, and the m line
provides a port of 54344. We ignore the user attribute for
simplicity's sake. The proxy doesn't record route, but adds a hop
header with the SIP URI of "sip:relay". The explicit transport=tcp
has also been omitted for clarity. This reques is forwarded to the
UAS, which answers. The 200 OK from the client indicates an IP
address of 4.3.2.1:44345 in the c and m lines. The proxy once again
inserts a hop header pointing to the same relay.
When the callee sends a MESSAGE, it uses a request URI of
"sip:1.2.3.4:54344;transport=tcp" and a Route header of
"sip:relay;transport=tcp". Based on bis routing rules, this gets sent
to the relay. The relay pops its route, and then forwards to the
ultimate recipient. The message flow in the reverse direction is
similar. When the caller hangs up, the BYE goes directly from the
caller to callee. This is because the proxy didn't record route. As
the example shows, there is no relationship between the MESSAGE path
and the SIP path.
6 The Bigger Picture
The usage of the "hop" attribute in the SDP has some problems. It
requires proxies to violate the SIP specification. Proxies are, for
good reason, forbidden from modifying the contents of bodies in SIP
messages. Adding the hop attribute requires proxies to perform a
modification of the body. The hop attribute is also specific to the
IM session concept. However, insertion of media intermediaries is a
problem for messages, voice, and video alike. Therefore, we have
developed an alternative model that attempts to solve the problem
more broadly [10]. Readers are referred to that document for more
detail.
We do not propose that this mechanism be used for the initial IM
session specification. This is principally for reasons of timing. The
above draft would need to first become a requirements RFC in sipping,
and then move on to a protocol extension in SIP, all assuming it is
accepted. This would delay the message session drafts by too much
J.Rosenberg [Page 8]
Internet Draft MESSAGE sessions May 2, 2002
time. We would rather specify the SDP approach here, and migrate to
the right thing if and when it becomes available.
7 Author's Addresses
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
8 Normative References
[1] J. Rosenberg et al. , "SIP extensions for instant messaging,"
Internet Draft, Internet Engineering Task Force, July 2001. Work in
progress.
[2] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress.
[3] M. Handley and V. Jacobson, "SDP: session description protocol,"
RFC 2327, Internet Engineering Task Force, Apr. 1998.
9 Informative References
[4] J. Rosenberg, J. Peterson, H. Schulzrinne, and G. Camarillo,
"Third party call control in SIP," Internet Draft, Internet
Engineering Task Force, Nov. 2001. Work in progress.
[5] J. Rosenberg and H. Schulzrinne, "Models for multi party
conferencing in SIP," Internet Draft, Internet Engineering Task
Force, Nov. 2001. Work in progress.
[6] W. Marshall, G. Camarillo, and J. Rosenberg, "Integration of
resource management and SIP," Internet Draft, Internet Engineering
Task Force, Apr. 2002. Work in progress.
[7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
transport protocol for real-time applications," RFC 1889, Internet
Engineering Task Force, Jan. 1996.
[8] J. Rosenberg et al. , "A proposal for IM transport," Internet
Draft, Internet Engineering Task Force, Nov. 2001. Work in progress.
J.Rosenberg [Page 9]
Internet Draft MESSAGE sessions May 2, 2002
Caller Proxy Relay Callee
|(1) INVITE | | |
|m=54344 | | |
|c=1.2.3.4 | | |
|------------------>|(2) INVITE | |
| |m=54344 | |
| |c=1.2.3.4 | |
| |hop=sip:relay | |
| |-------------------------------------->|
| |(3) 200 OK | |
| |m=44345 | |
| |c=4.3.2.1 | |
|(4) 200 OK |<--------------------------------------|
|m=44345 | | |
|c=4.3.2.1 | | |
|hop=sip:relay | | |
|<------------------| | |
|(5) ACK | | |
|---------------------------------------------------------->|
| | |(6) MESSAGE |
| | |ruri=1.2.3.4:54344 |
| | |Route=sip:relay |
| | |<------------------|
|(7) MESSAGE | | |
|ruri=1.2.3.4:54344 | | |
|<--------------------------------------| |
|(8) 200 OK | | |
|-------------------------------------->| |
| | |(9) 200 OK |
| | |------------------>|
|(10) MESSAGE | | |
|ruri=4.3.2.1:44345 | | |
|Route=sip:relay | | |
|-------------------------------------->| |
| | |(11) MESSAGE |
| | |ruri=4.3.2.1:44345 |
| | |------------------>|
| | |(12) 200 OK |
| | |<------------------|
|(13) 200 OK | | |
|<--------------------------------------| |
|(14) BYE | | |
|---------------------------------------------------------->|
|(15) 200 OK | | |
|<----------------------------------------------------------|
Figure 1: Call Flow Example
J.Rosenberg [Page 10]
Internet Draft MESSAGE sessions May 2, 2002
[9] M. Rose, "Im simple exchange (imsx)," Internet Draft, Internet
Engineering Task Force, Dec. 2001. Work in progress.
[10] J. Rosenberg, "Supporting intermediary session policies in sip,"
Internet Draft, Internet Engineering Task Force, May 2002. Work in
progress.
Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
J.Rosenberg [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 09:27:02 |