Internet Engineering Task Force SIMPLE WG Internet Draft J.Rosenberg,C.Huitema,R.Osborne,A.Houri draft-rosenberg-simple-im-transport-00.txt dynamicsoft,Microsoft,IBM/Lotus November 14, 2001 Expires: May 2002 A Proposal for IM Transport 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 This document presents the set of requirements needed for an IM transport for use in the IM "session model" of operation under discussion within the SIMPLE group. After presenting the requirements, we propose a solution which we believe meets the requirements and presents a potential path forward. 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 J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 1]
Internet Draft IM Transport November 14, 2001 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 without modification. 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 draft, we describe the requirements for such a transport, based on list consensus, and then propose a transport solution which appears to meet these requirements and represents a reasonable compromise on the differing approaches that have been advocated. Our proposal is a strawman; it is not rigorously specified or complete. It is rather a proposal for a path forward that would need to be further refined if this direction is taken. The compromise is based on the definition of a new IM transport protocol, called IMTP. IMTP is a proper subset of SIP. Its a large enough subset of SIP so that existing proxy products can easily route them, but a small enough subset so as to enforce proper congestion control and remove the features that get in the way of IM transport. 2 Requirements The following are the requirements needed for the IM transport. This is a collection of requirements discussed on the list, in addition to a few more we believe are important. These requirements overlap in some cases with the requirements specified in RFC 2779 [8]. However, they are different because the focus here is on the use of an IM transport in a session model of operation, rather than the requirements on the overall IM system. REQ 1: Congestion control and flow control The IM transport MUST provide congestion control and flow control along the entire path of message delivery. REQ 2: Reliable, sequence delivery The IM transport MUST provide for reliable delivery end- J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 2]
Internet Draft IM Transport November 14, 2001 to-end, and also MUST provide for sequencing to handle IMs that are delivered out of order. REQ 3: Arbitrary sizes The IM transport MUST support the ability to deliver IMs of arbitrarily large size. This literally means one byte IMs to megabytes. REQ 4: Framing The IM transport MUST provide a framing function, so that messages can easily be delineated from each other. REQ 5: Per message content typing The IM transport MUST support the ability for each IM to contain a different MIME type. The IM transport MUST support the ability to declare the content type of each message. The IM transport MUST allow any MIME type, including multipart. REQ 6: End-to-end privacy, authentication and integrity The IM transport MUST support end-to-end privacy, authentication and integrity. REQ 7: Works through NAT The IM transport MUST have a deployable story on dealing with nats. This includes the case where a user is sending IMs through an IM provider on the public Internet, but is behind a NAT. It also includes the case where a user is within an enterprise, sending an IM to another user, and there is no public IM provider - it is an enterprise to enterprise communication. REQ 8: Rapid delivery The IM transport should operate rapidly, typically delivering messages in under a second. REQ 9: Lightweight The IM transport will be implemented in thin devices like wireless phones and pagers, and therefore needs to be relatively lightweight. J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 3]
Internet Draft IM Transport November 14, 2001 REQ 10: Support for sender identification The IM transport has to declare the originator of each IM. This is not needed for point-to-point IM, since SIP itself will convey the originator through the INVITE. However, in multipoint conferences, an IM mixer will need to tell each recipient from whom the particular message has come from. Thus, a sender identification function is needed. This is very similar the SSRC/CNAME function provided by RTCP for RTP [7]. REQ 11: Parser reuse The IM transport SHOULD make use of message syntax that resembles SIP, in order to avoid definition of additional parsers. This enables code reuse. REQ 12: Compressible The IM transport SHOULD allow for the application of signaling compression [9]. REQ 13: Support for relay intermediaries The IM transport MUST support the notion of some kind of intermediary that serves as a relay for IM. This is going to be needed to support nat operation, but is also important for several other requirements. REQ 14: Allow multiplexing The IM transport MUST support multiplexing of messages over a common connection. This would happen, for example, when exchanging messages between two relays for two different enterprises. The IM transport MUST allow for all IMs between the enterprises to go over the same connection. This facilitates bulk congestion control and also improves scalability. REQ 15: Logging The IM transport MUST facilitate the logging of messages through intermediate relays. REQ 16: Per message acknowledgements As per RFC2779, it MUST be possible for the IM transport to provide an end-to-end acknowledgement of the receipt of J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 4]
Internet Draft IM Transport November 14, 2001 each message. 3 Extracting a Protocol from the Requirements In this section, we analyze the requirement to distill the skeleton of a protocol. REQ 1 and 2 imply that the protocol runs over a reliable transport, such as TCP or SCTP. REQ 11 would imply that the structure of the protocol, syntactically, resembles SIP. REQ 2 implies that the protocol has a notion of independent messages. REQ 2 implies that each message have, at a minimum, some kind of sequence number (lets call it CSeq). REQ 5 would imply that each message additionally have mechanisms to label the type of the content present in the message, lets call this label Content-Type. REQ 10 would imply that each message contain an identification of the sender, call this From. REQ 16 implies that each message is associated with a response of some kind. Clearly, we can have responses that indicate success or failure. From these requirements thus far, the IM transport protocol is a message oriented protocol that runs over TCP or SCTP, its textually structured, and has, at a minimum, Content-Type, From, and CSeq header values. If TCP is used, the framing requirements will introduce the need for some kind of length indicators (say, a Content-Length header). SCTP provides its own framing. The requirements directly imply the existence of intermediaries (REQ 13). These intermediaries receive messages and forward them towards the destination. A key question is: how is this decision made? The intermediaries need to provide logging capability (REQ 15), so that means they are aware of individual messages. This means that the intermediaries are specific to the IM transport protocol. As a result, a reasonable approach is to have the intermediaries examine a particular field in the message, and determine where to send it based on a single next-hop address that is configured into the intermediary. 4 IMTP: The IM Transport Protocol Our proposal is to define a new transport, called IMTP, the IM Transport Protocol. IMTP is almost identical to SIP. So much so, in fact, that SIP proxy servers (with proper configuration) can trivially route IMTP messages, and therefore play the role of the IMTP intermediary. However, IMTP provides a much smaller set of functionality than SIP does. Since it is not meant as a rendezvous function, all of those functions from SIP (forking, record-routing, J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 5]
Internet Draft IM Transport November 14, 2001 loose routing, dialogs, etc.) are not present in IMTP. IMTP only runs over reliable, congestion controlled transports, such as TCP or SCTP. IMTP has requests and responses. These requests and responses have the same basic structure as SIP and HTTP; they have a start line, headers, and a body. IMTP defines only a single method, MESSAGE. It defines only seven headers: To, From, Call-ID, CSeq, Via, Content- Length and Content-Type. The syntax of these seven headers are identical to their SIP counterparts. All requests and responses have a To, From, Call-ID, CSeq, and Via header. The Call-ID header is the same for all messages within a session. IMTP requests are targeted to an IM session identifier, which is carried in the Request-URI of the request. This session identifier is conveyed through SIP when the IM session is established. It is similar to the role played by port numbers in RTP. Unlike SIP, the protocol in the request line is IMTP/1.0, and not SIP/2.0. We feel this is important in order to make it clear that IMTP is not SIP, even though a SIP proxy which ignores this protocol field will be able to process an IMTP message. An example IMTP request looks like: MESSAGE sip:989ujko98a79@1.2.2.3 IMTP/1.0p Via: SIP/2.0/TCP 1.2.2.3 From: Joe <sip:joe@domain1.com> To: Bob <sip:bob@domain2.com> Call-ID: 98ihas89@1.2.2.3 CSeq: 20938 MESSAGE Content-Type: text/plain Content-Length: 22 Hey Bob! IMTP uses a subset of the response codes from SIP. In particular, any 2xx,4xx,5xx or 6xx response may be used. Redirects are disallowed. Provisional responses are disallowed. Each request therefore has a single response. We may need to allow provisional responses, even if they are just ignored; its not clear that most proxies can be configured to not send a 100 provisional response J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 6]
Internet Draft IM Transport November 14, 2001 4.1 IMTP Relays An IMTP relay receives an IMTP message, and forwards it on to another relay or the final recipient. To do this, the IMTP relay examines the request. It takes the Request-URI, and figures out the URI of the next hop element based on its configuration. There is only one next hop. The Request URI is then rewritten with this next hop address. The IMTP relay adds a Via header containing its own address. This is done primarily for compatibility with SIP, although its also useful for logging purposes to know the trace path of the request. When an IMTP relay receives a response, it sends the response over the same connection the request was received on. It also strips off its topmost Via header. Unlike SIP proxies, IMTP relays do not perform loop detection. They do not record-route or honor Route headers. They do not fork. They only use reliable transports, and therefore there is no application layer retransmissions. 5 Usage with SDP In IMTP, the Request-URI of the request indicates the session to which the IM is targeted. As part of the call setup done through SIP, this session identifier is exchanged in the SDP. Specifically, the m line in the SDP would look something like this: m=message 987708777 IMTP/TCP text/plain The media type is "message". This is followed by a session identifier, which has to be a globally unique ID for the session in question. Next is the transport, IMTP over TCP, followed by a listing of allowed formats that IMTP can carry. Here, only text/plain is indicated. We could also place numbers here, and then map them to MIME types using rtpmap, for consistency with other media formats. Streams that use IMTP are always connection oriented, and therefore use the SDP connection oriented media attributes [10] to allow for a single connection to be used for messaging in both directions. When user A calls B, the SDP in the INVITE from A would contain this m line. When B sends A a message, it takes the session ID, and places that into the user part of the SIP URL in the Request-URI. The host J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 7]
Internet Draft IM Transport November 14, 2001 part of the SIP URL is obtained from the c line. Need to get the port from somewhere too... maybe just specify a default port for IMTP? May not work with muli- user machines. 6 Examples The operation of IMTP is best illustrated through some examples. 6.1 Client to client +--------+ +--------+ | Proxy | | Proxy | | | | | | P1 | | P2 | | | | | +--------+ +--------+ +--------+ +--------+ | User | | User | | | | | | A | | B | | | | | +--------+ +--------+ Figure 1: Client to client configuration In this configuration, two users initiate an IM session through two proxy servers. The IM messages are carried end-to-end between the two users. The basic topology is shown in Figure 1. First, A (sitting at J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 8]
Internet Draft IM Transport November 14, 2001 1.2.3.4) sends a SIP INVITE to its proxy, P1. That INVITE might look like: INVITE sip:userB@domain2.com SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4 From: User A <sip:userA@domain1.com>;tag=5567 To: User B <sip:userB@domain2.com> Call-ID: 283e0@1.2.3.4 CSeq: 98770 INVITE Content-Type: application/sdp Content-Length: ... v=0 o=a 2890844526 2890842807 IN IP4 1.2.3.4 c=IN IP4 1.2.3.4 t=0 0 m=message 987654321 IMTP/TCP text/plain a=direction:both This INVITE is routed from P1 to P2, and finally to B (who is at 5.6.7.8), using standard SIP techniques. B then accepts the invitation, and sends this response: SIP/2.0 200 OK Via: SIP/2.0/UDP proxy2.domain2.com Via: SIP/2.0/UDP proxy1.domain1.com Via: SIP/2.0/UDP 1.2.3.4 From: User A <sip:userA@domain1.com>;tag=5567 To: User B <sip:userB@domain2.com>;tag=998a87 Call-ID: 283e0@1.2.3.4 CSeq: 98770 INVITE Content-Type: application/sdp Content-Length: ... v=0 o=a 2890844526 2890842807 IN IP4 5.6.7.8 c=IN IP4 5.6.7.8 t=0 0 m=message abcdefgh IMTP/TCP text/plain a=direction:both If A wants to send a message to B, it looks for an open TCP J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 9]
Internet Draft IM Transport November 14, 2001 connection to 5.6.7.8. If one exists, that is used. If not, one is opened. It can then send a message: MESSAGE sip:abcdefgh@5.6.7.8 IMTP/1.0 From: sip:userA@domain1.com To: sip:userB@domain2.com Call-ID: kkjjhhggffddaa@1.1.1.1 CSeq: 777 MESSAGE Via: SIP/2.0/TCP 1.2.3.4 Content-Type: text/plain Content-Length: ... Did you see the new trailer for Attack of the Clones? B will receive this request. It generates a 200 OK for this request. It can then send an IM over the same TCP connection. Such an IM might look like: MESSAGE sip:123456789@1.2.3.4 IMTP/1.0 To: sip:userA@domain1.com From: sip:userB@domain2.com Call-ID: kkjjhhggffddaa@1.1.1.1 CSeq: 111 MESSAGE Via: SIP/2.0/TCP 5.6.7.8 Content-Type: text/plain Content-Length: ... Yeah, I saw it. I hope Jar-Jar is not in this one.... This also generates a 200 OK response at A. 6.2 Inter Enterprise through two relays In the next example, we consider the use of relays to assist in firewall and nat traversal. We consider two enterprises, domain1 and domain2, each of which has a firewall set up. The firewalls are configured to allow an IMTP relay in each domain, and a proxy in each domain, to communicate with each other, both over persistent TLS connections that are nailed up. The configuration is shown in 2. The proxies in this configuration are aware that IMs need to flow J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 10]
Internet Draft IM Transport November 14, 2001 .............................. ............................... . . . . . +------+ +-+ +-+ +------+ . . | IMTP | | | | | | IMTP | . . | Relay| ---| |---| |--| Relay| . . | R1 | | | | | | R2 | . . +------+ |F| |F| +------+ . . |W| |W| . . +------+ | | | | +------+ . . | Proxy| | | | | | Proxy| . . | | ---| |---| |--| | . . | P1 | | | | | | P2 | . . +------+ +-+ I +-+ +------+ . . . n . . . . t . . . . e . . . . r . . . . n . . . . e . . . +------+ . t . +------+ . . | User | . . | User | . . | | . . | | . . | A | . . | B | . . +------+ . . +------+ . . domain1 . . domain2 . .............................. ............................... Figure 2: Inter-enterprise scenario through the relays. As a result, they rewrite the SDP in the INVITE and 2xx as it passes through the proxies. The rewrites change the IM session IDs and connection addresses to point to the relays instead. The proxies then need to install forwarding logic in the IMTP relays. How that is done is outside the scope of IMTP. However, if an IMTP relay is implemented with a proxy, this is trivially implemented with a REGISTER request. The call flow for this case is shown in Figure 3. First, user A generates an INVITE, structured identically to the INVITE above in the client to client case. The client is not aware that a relay is needed. This INVITE arrives at P1. P1 is aware than the relay is needed. So, it rewrites the SDP in the INVITE. The outgoing INVITE to P2 (message 4) might look like: J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 11]
Internet Draft IM Transport November 14, 2001 INVITE sip:userB@domain2.com SIP/2.0 Via: SIP/2.0/TLS p1.domain1.com Via: SIP/2.0/UDP 1.2.3.4 Record-Route: sip:userA@1.2.3.4;maddr=p1.domain1.com From: User A <sip:userA@domain1.com>;tag=5567 To: User B <sip:userB@domain2.com> Contact: sip:userA@1.2.3.4 Call-ID: 283e0@1.2.3.4 CSeq: 98770 INVITE Content-Type: application/sdp Content-Length: ... v=0 o=a 2890844526 2890842807 IN IP4 1.2.3.4 c=IN IP4 r1.domain1.com t=0 0 m=message r1-987654321 IMTP/TLS text/plain a=direction:both The c line has been changed to r1.domain1.com, and the m line has a new session ID. The transport is also changed to TLS, so that all messaging is received from the outside over TLS. The result of this change is that when a message is received at r1, with a request URI of sip:r1-987654321@r1.domain1.com, they must be forwarded to sip:987654321@1.2.3.4. To do that, P1 sends a REGISTER request (message 2) to R1 to establish the binding. That REGISTER might look like: REGISTER sip:r1.domain1.com SIP/2.0 From: sip:p1.domain1.com To: sip:r1-987654321@r1.domain1.com Contact: sip:987654321@1.2.3.4;expires=3600 Call-ID: 1928039388@p1.domain1.com CSeq: 876554 REGISTER Via: SIP/2.0/UDP p1.domain1.com Now, when a message for sip:r1-987654321@r1.domain1.com is received at R1, its forwarded to sip:987654321@1.2.3.4. P2 receives the INVITE, and performs a similar operation. It rewrites the SDP in its INVITE so that IMs pass through R2. The outgoing INVITE (message 7) might look like: J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 12]
Internet Draft IM Transport November 14, 2001 User A Proxy IMTP Proxy IMTP User B P1 Relay P2 Relay R1 R2 | | | | | | | | | | | | |(1) INVITE | | | | |-------->| | | | | | |(2) REGISTER | | | | |-------->| | | | | |(3) 200 OK | | | | |<--------| | | | | |(4) INVITE | | | | |------------------>| | | | | | |(5) REGISTER | | | | |-------->| | | | | |(6) 200 OK | | | | |<--------| | | | | |(7) INVITE | | | | |------------------>| | | | |(8) 200 OK | | | | |<------------------| | | | |(9) REGISTER | | | | |-------->| | | | | |(10) 200 OK | | | | |<--------| | | |(11) 200 OK | | | | |<------------------| | | | |(12) REGISTER | | | | |-------->| | | | | |(13) 200 OK | | | | |<--------| | | | |(14) 200 OK | | | | |<--------| | | | | |(15) ACK | | | | | |-------->| | | | | | |(16) ACK | | | | | |------------------>| | | | | | |(17) ACK | | | | | |------------------>| |(18) MESSAGE | | | | |------------------>| | | | | | |(19) MESSAGE | | | | |------------------>| | | | | | |(20) MESSAGE | | | | |-------->| | | | | |(21) 200 OK | | | | |<--------| | | |(22) 200 OK | | | | |<------------------| | |(23) 200 OK | | | | |<------------------| | | | | | | | | | | | | | | | J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 13]
Internet Draft IM Transport November 14, 2001 Via: SIP/2.0/UDP proxy2.domain2.com Via: SIP/2.0/TLS proxy1.domain1.com Via: SIP/2.0/UDP 1.2.3.4 Record-Route: sip:userA@1.2.3.4;maddr=p2.domain2.com Record-Route: sip:userA@1.2.3.4;maddr=p1.domain1.com From: User A <sip:userA@domain1.com>;tag=5567 To: User B <sip:userB@domain2.com>;tag=998a87 Contact: sip:userB@5.6.7.8 Call-ID: 283e0@1.2.3.4 CSeq: 98770 INVITE Content-Type: application/sdp Content-Length: ... v=0 o=a 2890844526 2890842807 IN IP4 5.6.7.8 c=IN IP4 5.6.7.8 t=0 0 m=message abcdefgh IMTP/TCP text/plain a=direction:both This is sent to P2. P2 rewrites the SDP once more, so that messages to user B instead pass through the relay. The 200 OK it would forward to P1 (message 11) might look like: SIP/2.0 200 OK Via: SIP/2.0/TLS proxy1.domain1.com Via: SIP/2.0/UDP 1.2.3.4 Record-Route: sip:userB@5.6.7.8;maddr=p2.domain2.com Record-Route: sip:userA@1.2.3.4;maddr=p1.domain1.com From: User A <sip:userA@domain1.com>;tag=5567 To: User B <sip:userB@domain2.com>;tag=998a87 Contact: sip:userB@5.6.7.8 Call-ID: 283e0@1.2.3.4 CSeq: 98770 INVITE Content-Type: application/sdp Content-Length: ... v=0 o=a 2890844526 2890842807 IN IP4 5.6.7.8 c=IN IP4 r2.domain2.com t=0 0 m=message r2-abcdefgh IMTP/TLS text/plain a=direction:both J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 14]
Internet Draft IM Transport November 14, 2001 A binding from sip:r2-abcdefgh@r2.domain2.com to sip:abcdefgh@5.6.7.8 then needs to be established at R2. This is done with yet another REGISTER (message 9): REGISTER sip:r2.domain2.com SIP/2.0 From: sip:p2.domain2.com To: sip:r2-abcdefgh@r2.domain2.com Contact: sip:r2-abcdefgh@5.6.7.8;expires=3600 Call-ID: 99akksjas9@p2.domain2.com CSeq: 6541 REGISTER Via: SIP/2.0/UDP p2.domain2.com P1 receives the 200 OK, and also rewrites the SDP so that all messages pass through R1. The 200 OK it might send to A (message 14) looks like: SIP/2.0 200 OK Via: SIP/2.0/UDP 1.2.3.4 Record-Route: sip:userB@5.6.7.8;maddr=p2.domain2.com Record-Route: sip:userB@5.6.7.8;maddr=p1.domain1.com From: User A <sip:userA@domain1.com>;tag=5567 To: User B <sip:userB@domain2.com>;tag=998a87 Contact: sip:userB@5.6.7.8 Call-ID: 283e0@1.2.3.4 CSeq: 98770 INVITE Content-Type: application/sdp Content-Length: ... v=0 o=a 2890844526 2890842807 IN IP4 5.6.7.8 c=IN IP4 r1.domain1.com t=0 0 m=message r1-abcdefgh IMTP/TCP text/plain a=direction:both This, too, requires a binding in R1, to cause messages to sip:r1- abcdefgh@r1.domain1.com to get forwarded to sip:r2- abcdefgh@r2.domain2.com. Thats done with REGISTER (message 12): REGISTER sip:r1.domain1.com SIP/2.0 From: sip:p1.domain1.com J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 15]
Internet Draft IM Transport November 14, 2001 To: sip:r1-abcdefgh@r1.domain1.com Contact: sip:r2-abcdefgh@r2.domain2.com;expires=3600 Call-ID: 1928039388@p1.domain1.com CSeq: 876555 REGISTER Via: SIP/2.0/UDP p1.domain1.com The 200 OK is ACK'd using standard SIP techniques. Since both proxies record-routed, the ACK (messages 15,16,17) goes through both of them. Now, A decides to send an IM. To do that, it looks at the SDP in the 200 OK it received (message 14). This SDP indicates that it is to send the IM over TCP to r1.domain1.com, using a URL of sip:r1- abcdefgh@r1.domain1.com. Since no such TCP connection exists, user A initiates it to R1. It then sends the IM over this connection, which would look like (message 18): MESSAGE sip:r1-abcdefgh@r1.domain1.com IMTP/1.0 Via: SIP/2.0/TCP 1.2.3.4 To: sip:userB@domain2.com From: sip:userA@domain1.com Call-ID: aasdasd9asduad@1.2.3.4 CSeq: 5576 MESSAGE Content-Type: text/plain Content-Length: ... one ring to rule them all R1 receives this. It hangs on to the TCP connection, and knows that if it needs to send something to 1.2.3.4 (the source IP of the connection) it can use it. Need a little more rigor in port handling and connection reuse, to ensure that the comedia rules and SIP transport rules are in sync. R1 then looks up the request URI, and finds a binding. It rewrites the request URI, and sends the request to the new URL, sip:r2- abcdefgh@r2.domain2.com (message 19). Since there is an existing TLS connection to that address, this connection is reused: MESSAGE sip:r2-abcdefgh@r2.domain2.com IMTP/1.0 J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 16]
Internet Draft IM Transport November 14, 2001 Via: SIP/2.0/TLS p1.domain1.com Via: SIP/2.0/TCP 1.2.3.4 To: sip:userB@domain2.com From: sip:userA@domain1.com Call-ID: aasdasd9asduad@1.2.3.4 CSeq: 5576 MESSAGE Content-Type: text/plain Content-Length: ... one ring to rule them all R2 receives this message. It looks up the URL, and also finds a binding. It rewrites the request URI and sends it to B (message 20): MESSAGE sip:abcdefgh@5.6.7.8 IMTP/1.0 Via: SIP/2.0/TCP p2.domain2.com Via: SIP/2.0/TLS p1.domain1.com Via: SIP/2.0/TCP 1.2.3.4 To: sip:userB@domain2.com From: sip:userA@domain1.com Call-ID: aasdasd9asduad@1.2.3.4 CSeq: 5576 MESSAGE Content-Type: text/plain Content-Length: ... one ring to rule them all This is delivered to B. B responds with a 200 OK (message 21), which is forwarded back to A (message 22,23). Its important to realize that the IMTp relays need not be physically separated from the proxies. In fact, proxy P1, if properly configured, can act as R1. This would allow the same TLS connection to be used between P1/R1 and P2/R2 for both SIP signaling and IMTP. Such co-location would avoid the need for the explicit REGISTER messaging; these bindings would be done through internal mechanisms instead. Note, however, that even if UDP is used between the SIP proxies, a reliable transport would still be needed between the IMTP relays, even if the IMTP relay function is co-resident with the proxy. Effectively, this would mean that SIP is sent between the two boxes over UDP, and the MESSAGE IMTP requests over TCP between the same J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 17]
Internet Draft IM Transport November 14, 2001 boxes. 7 Author's Addresses Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: huitema@microsoft.com Robert Osborne Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: roberto@microsoft.com Avshalom Houri Lotus Sametime IBM/Lotus Building 18/D, Science Park Kiryat Weizman, P.O. Box 2523 Rehovot 76123 Israel email: avshalom@ubique.com 8 Bibliography [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, Oct. 2001. Work in progress. [3] M. Handley and V. Jacobson, "SDP: session description protocol," J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 18]
Internet Draft IM Transport November 14, 2001 Request for Comments 2327, Internet Engineering Task Force, Apr. 1998. [4] J. Rosenberg, J. Peterson, H. Schulzrinne, and G. Camarillo, "Third party call control in SIP," Internet Draft, Internet Engineering Task Force, Mar. 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 et al. , "Integration of resource management and SIP," Internet Draft, Internet Engineering Task Force, Aug. 2001. Work in progress. [7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a transport protocol for real-time applications," Request for Comments 1889, Internet Engineering Task Force, Jan. 1996. [8] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging / presence protocol requirements," Request for Comments 2779, Internet Engineering Task Force, Feb. 2000. [9] H. Hannu, Z. Liu, R. Price, J. Rosenberg, J. Christofferson, C. Clanton, S. Forsgren, K. Le, K. Leung, and K. Svanbro, "Signaling compression (sigcomp)," Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. [10] D. Yon, "Connection-oriented media transport in SDP," Internet Draft, Internet Engineering Task Force, Oct. 2001. Work in progress. Table of Contents 1 Introduction ........................................ 1 2 Requirements ........................................ 2 3 Extracting a Protocol from the Requirements ......... 5 4 IMTP: The IM Transport Protocol ..................... 5 4.1 IMTP Relays ......................................... 7 5 Usage with SDP ...................................... 7 6 Examples ............................................ 8 6.1 Client to client .................................... 8 6.2 Inter Enterprise through two relays ................. 10 J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 19]
Internet Draft IM Transport November 14, 2001 7 Author's Addresses .................................. 18 8 Bibliography ........................................ 18 J.Rosenberg,C.Huitema,R.Osborne,A.Houri [Page 20]