From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4538.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc4538.txt (limited to 'doc/rfc/rfc4538.txt') diff --git a/doc/rfc/rfc4538.txt b/doc/rfc/rfc4538.txt new file mode 100644 index 0000000..c64f919 --- /dev/null +++ b/doc/rfc/rfc4538.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group J. Rosenberg +Request for Comments: 4538 Cisco Systems +Category: Standards Track June 2006 + + + Request Authorization through Dialog Identification + in the Session Initiation Protocol (SIP) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This specification defines the Target-Dialog header field for the + Session Initiation Protocol (SIP), and the corresponding option tag, + tdialog. This header field is used in requests that create SIP + dialogs. It indicates to the recipient that the sender is aware of + an existing dialog with the recipient, either because the sender is + on the other side of that dialog, or because it has access to the + dialog identifiers. The recipient can then authorize the request + based on this awareness. + + + + + + + + + + + + + + + + + + + + + +Rosenberg Standards Track [Page 1] + +RFC 4538 Target Dialog June 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Terminology ................................................4 + 2. Overview of Operation ...........................................4 + 3. User Agent Client (UAC) Behavior ................................5 + 4. User Agent Server Behavior ......................................7 + 5. Proxy Behavior ..................................................8 + 6. Extensibility Considerations ....................................8 + 7. Header Field Definition .........................................9 + 8. Security Considerations .........................................9 + 9. Relationship with In-Reply-To ..................................10 + 10. Example Call Flow .............................................10 + 11. IANA Considerations ...........................................13 + 11.1. Header Field .............................................13 + 11.2. Header Field Parameters ..................................13 + 11.2.1. local-tag .........................................13 + 11.2.2. remote-tag ........................................13 + 11.3. SIP Option Tag ...........................................14 + 12. Acknowledgements ..............................................14 + 13. References ....................................................14 + 13.1. Normative References .....................................14 + 13.2. Informative References ...................................15 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg Standards Track [Page 2] + +RFC 4538 Target Dialog June 2006 + + +1. Introduction + + The Session Initiation Protocol (SIP) [2] defines the concept of a + dialog as a persistent relationship between a pair of user agents. + Dialogs provide context, including sequence numbers, proxy routes, + and dialog identifiers. Dialogs are established through the + transmission of SIP requests with particular methods. Specifically, + the INVITE, REFER [8], and SUBSCRIBE [3] requests all create dialogs. + + When a user agent receives a request that creates a dialog, it needs + to decide whether to authorize that request. For some requests, + authorization is a function of the identity of the sender, the + request method, and so on. However, many situations have been + identified in which a user agent's authorization decision depends on + whether the sender of the request is currently in a dialog with that + user agent, or whether the sender of the request is aware of a dialog + the user agent has with another entity. + + One such example is call transfer, accomplished through REFER. If + user agents A and B are in an INVITE dialog, and user agent A wishes + to transfer user agent B to user agent C, user agent A needs to send + a REFER request to user agent B, asking user agent B to send an + INVITE request to user agent C. User agent B needs to authorize this + REFER. The proper authorization decision is that user agent B should + accept the request if it came from a user with whom B currently has + an INVITE dialog relationship. Current implementations deal with + this by sending the REFER on the same dialog as the one in place + between user agents A and B. However, this approach has numerous + problems [12]. These problems include difficulties in determining + the lifecycle of the dialog and its usages and in determining which + messages are associated with each application usage. Instead, a + better approach is for user agent A to send the REFER request to user + agent B outside of the dialog. In that case, a means is needed for + user agent B to authorize the REFER. + + Another example is the application interaction framework [14]. In + that framework, proxy servers on the path of a SIP INVITE request can + place user interface components on the user agent that generated or + received the request. To do this, the proxy server needs to send a + REFER request to the user agent, targeted to its Globally Routable + User Agent URI (GRUU) [13], asking the user agent to fetch an HTTP + resource containing the user interface component. In such a case, a + means is needed for the user agent to authorize the REFER. The + application interaction framework recommends that the request be + authorized if it was sent from an entity on the path of the original + dialog. This can be done by including the dialog identifiers in the + + + + + +Rosenberg Standards Track [Page 3] + +RFC 4538 Target Dialog June 2006 + + + REFER, which prove that the user agent that sent the REFER is aware + of those dialog identifiers (this needs to be secured against + eavesdroppers through the sips mechanism, of course). + + Another example is if two user agents share an INVITE dialog, and an + element on the path of the INVITE request wishes to track the state + of the INVITE. In such a case, it sends a SUBSCRIBE request to the + GRUU of the user agent, asking for a subscription to the dialog event + package. If the SUBSCRIBE request came from an element on the INVITE + request path, it should be authorized. + +1.1. Terminology + + 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 [1]. + +2. Overview of Operation + + +--------+ +--------+ + | | INVITE | | + | Server |----------->| Server | + | A | | B | + | |...........>| | + +--------+ +--------+ + ^ REFER . \ + / . \ + / . \ + / . \ + / . \ + / V V + +--------+ +--------+ + | | | | + | User | | User | + | Agent | | Agent | + | A | | B | + +--------+ +--------+ + + Figure 1 + + Figure 1 shows the basic model of operation. User agent A sends an + INVITE to user agent B, traversing two servers, server A and server + B. Both servers act as proxies for this transaction. User B sends a + 200 OK response to the INVITE. This 200 OK includes a Supported + header field indicating support for this specification (through the + presence of the tdialog option tag). The 200 OK response establishes + a dialog between the two user agents. + + + + +Rosenberg Standards Track [Page 4] + +RFC 4538 Target Dialog June 2006 + + + Next, an entity that was present along the request path (server A, + for example) wishes to send a dialog-forming request (such as REFER) + to user agent A or B (user B for example). So, the entity acts as a + user agent and sends the request to user agent B. This request is + addressed to the URI of user agent B, which server A learned from + inspecting the Contact header field in the 200 OK of the INVITE + request. If this URI has the GRUU [11] property (it can be used by + any element on the Internet, such as server A, to reach the specific + user agent instance that generated that 200 OK to the INVITE), then + the mechanism will work across NAT boundaries. + + The request generated by server A will contain a Target-Dialog header + field. This header field contains the dialog identifiers for the + INVITE dialog between user agents A and B, composed of the Call-ID, + local tag, and remote tag. Server A knew to include the Target- + Dialog header field in the REFER request because it knows that user + agent B supports it. + + When the request arrives at user agent B, it needs to make an + authorization decision. Because the INVITE dialog was established + using a sips URI, and because the dialog identifiers are + cryptographically random [2], no entity except for user agent A or + the proxies on the path of the initial INVITE request can know the + dialog identifiers. Thus, because the request contains those dialog + identifiers, user agent B can be certain that the request came from + user agent A, the two proxies, or an entity to whom the user agent or + proxies gave the dialog identifiers. As such, it authorizes the + request and performs the requested actions. + +3. User Agent Client (UAC) Behavior + + A UAC SHOULD include a Target-Dialog header field in a request if the + following conditions are all true: + + 1. The request is to be sent outside of any existing dialog. + + 2. The user agent client believes that the request may not be + authorized by the user agent server unless the user agent client + can prove that it is aware of the dialog identifiers for some + other dialog. Call this dialog the target dialog. + + 3. The request does not otherwise contain information that indicates + that the UAC is aware of those dialog identifiers. + + + + + + + + +Rosenberg Standards Track [Page 5] + +RFC 4538 Target Dialog June 2006 + + + 4. The user agent client knows that the user agent server supports + the Target-Dialog header field. It can know this if it has seen + a request or response from the user agent server within the + target dialog that contained a Supported header field that + included the tdialog option tag. + + If the fourth condition is not met, the UAC SHOULD NOT use this + specification. Instead, if it is currently within a dialog with the + User Agent Server (UAS), it SHOULD attempt to send the request within + the existing target dialog. + + The following are examples of use cases in which these conditions are + met: + + o A REFER request is sent according to the principles of [14]. + These REFER are sent outside of a dialog and do not contain any + other information that indicates awareness of the target dialog. + [14] also mandates that the REFER be sent only if the UA indicates + support for the target dialog specification. + + o User A is in separate calls with users B and C. User A decides to + start a three way call, and so morphs into a focus [17]. User B + would like to learn the other participants in the conference. So, + it sends a SUBSCRIBE request to user A (who is now acting as the + focus) for the conference event package [16]. It is sent outside + of the existing dialog between user B and the focus, and it would + be authorized by A if user B could prove that it knows the dialog + identifiers for its existing dialog with the focus. Thus, the + Target-Dialog header field would be included in the SUBSCRIBE. + + The following are examples of use cases in which these conditions are + not met: + + o A server acting as a proxy is a participant in an INVITE dialog + that establishes a session. The server would like to use the + Keypad Markup Language (KPML) event package [18] to find out about + keypresses from the originating user agent. To do this, it sends + a SUBSCRIBE request. However, the Event header field of this + SUBSCRIBE contains event parameters that indicate the target + dialog of the subscription. As such, the request can be + authorized without additional information. + + o A server acting as a proxy is a participant in an INVITE dialog + that establishes a session. The server would like to use the + dialog event package [15] to find out about dialogs at the + originating user agent. To do this, it sends a SUBSCRIBE request. + However, the Event header field of this SUBSCRIBE contains event + parameters that indicate the target dialog of the subscription. + + + +Rosenberg Standards Track [Page 6] + +RFC 4538 Target Dialog June 2006 + + + As such, the request can be authorized without additional + information. + + Specifications that intend to make use of the Target-Dialog header + field SHOULD discuss specific conditions in which it is to be + included. + + Assuming it is to be included, the value of the callid production in + the Target-Dialog header field MUST be equal to the Call-ID of the + target dialog. The "remote-tag" header field parameter MUST be + present and MUST contain the tag that would be viewed as the remote + tag from the perspective of the recipient of the new request. The + "local-tag" header field parameter MUST be present and MUST contain + the tag that would be viewed as the local tag from the perspective of + the recipient of the new request. + + The request sent by the UAC SHOULD include a Require header field + that includes the tdialog option tag. This request should, in + principle, never fail with a 420 (Bad Extension) response, because + the UAC would not have sent the request unless it believed the UAS + supported the extension. If a Require header field was not included, + and the UAS didn't support the extension, it would normally reject + the request because it was unauthorized, probably with a 403. + However, without the Require header field, the UAC would not be able + to differentiate between the following: + + o a 403 that arrived because the UAS didn't actually understand the + Target-Dialog header field (in which case the client should send + the request within the target dialog if it can) + + o a 403 that arrived because the UAS understood the Target-Dialog + header field, but elected not to authorize the request despite the + fact that the UAC proved its awareness of the target dialog (in + which case the client should not resend the request within the + target dialog, even if it could). + +4. User Agent Server Behavior + + If a user agent server receives a dialog-creating request and wishes + to authorize the request, and if that authorization depends on + whether or not the sender has knowledge of an existing dialog with + the UAS, and information outside of the Target-Dialog header field + does not provide proof of this knowledge, the UAS SHOULD check the + request for the existence of the Target-Dialog header field. If this + header field is not present, the UAS MAY still authorize the request + by other means. + + + + + +Rosenberg Standards Track [Page 7] + +RFC 4538 Target Dialog June 2006 + + + If the header field is present, and the value of the callid + production, the "remote-tag", and "local-tag" values match the + Call-ID, remote tag, and local tag of an existing dialog, and the + dialog that they match was established using a sips URI, the UAS + SHOULD authorize the request if it would authorize any entity on the + path of the request that created that dialog, or any entity trusted + by an entity on the path of the request that created that dialog. + + If the dialog identifiers match, but they match a dialog not created + with a sips URI, the UAS MAY authorize the request if it would + authorize any entity on the path of the request that created that + dialog, or any entity trusted by an entity on the path of the request + that created that dialog. However, in this case, any eavesdropper on + the original dialog path would have access to the dialog identifiers, + and thus the authorization is optional. + + If the dialog identifiers don't match, or if they don't contain both + a "remote-tag" and "local-tag" parameter, the header field MUST be + ignored, and authorization MAY be determined by other means. + +5. Proxy Behavior + + Proxy behavior is unaffected by this specification. + +6. Extensibility Considerations + + This specification depends on a user agent client knowing, ahead of + sending a request to a user agent server, whether or not that user + agent server supports the Target-Dialog header field. As discussed + in Section 3, the UAC can know this because it saw a request or + response sent by that UAS within the target dialog that contained the + Supported header field whose value included the tdialog option tag. + + Because of this requirement, it is especially important that user + agents compliant to this specification include a Supported header + field in all dialog forming requests and responses. Inclusion of the + Supported header fields in requests is at SHOULD strength per RFC + 3261. This specification does not alter that requirement. However, + implementers should realize that, unless the tdialog option tag is + placed in the Supported header field of requests and responses, this + extension is not likely to be used, and instead, the request is + likely to be re-sent within the existing target dialog (assuming the + sender is the UA on the other side of the target dialog). As such, + the conditions in which the SHOULD would not be followed would be + those rare cases in which the UA does not want to enable usage of + this extension. + + + + + +Rosenberg Standards Track [Page 8] + +RFC 4538 Target Dialog June 2006 + + +7. Header Field Definition + + The grammar for the Target-Dialog header field is defined as follows: + + Target-Dialog = "Target-Dialog" HCOLON callid *(SEMI + td-param) ;callid from RFC 3261 + td-param = remote-param / local-param / + generic-param + remote-param = "remote-tag" EQUAL token + local-param = "local-tag" EQUAL token + ;token and generic-param from RFC 3261 + + Figures 3 and 4 are an extension of Tables 2 and 3 in RFC 3261 [2] + for the Target-Dialog header field. The column "INF" is for the INFO + method [4], "PRA" is for the PRACK method [5], "UPD" is for the + UPDATE method [6], "SUB" is for the SUBSCRIBE method [3], "NOT" is + for the NOTIFY method [3], "MSG" is for the MESSAGE method [7], "REF" + is for the REFER method [8], and "PUB" is for the PUBLISH method [9]. + + Header field where proxy ACK BYE CAN INV OPT REG PUB + + Target-Dialog R - - - - o - - - + + Figure 3: Allowed Methods for Target-Dialog + + + Header field where proxy PRA UPD SUB NOT INF MSG REF + + Target-Dialog R - - - o - - - o + + Figure 4: Allowed Methods for Target-Dialog + +8. Security Considerations + + The Target-Dialog header field is used to authorize requests based on + the fact that the sender of the request has access to information + that only certain entities have access to. In order for such an + authorization decision to be secure, two conditions have to be met. + Firstly, no eavesdroppers can have access to this information. That + requires the original SIP dialog to be established using a sips URI, + which provides TLS on each hop. With a sips URI, only the user + agents and proxies on the request path will be able to know the + dialog identifiers. The second condition is that the dialog + identifiers be sufficiently cryptographically random that they cannot + be guessed. RFC 3261 requires global uniqueness for the Call-ID and + 32 bits of cryptographic randomness for each tag (there are two tags + for a dialog). Given the short duration of a typical dialog (perhaps + as long as a day), this amount of randomness appears adequate for + + + +Rosenberg Standards Track [Page 9] + +RFC 4538 Target Dialog June 2006 + + + preventing guessing attacks. However, it's important to note that + this specification requires true cryptographic randomness as set + forth in RFC 4086 [11]. Weaker pseudorandom identifiers reduce the + probability of collision, but because they are guessable, they are + not sufficient to prevent an attacker from observing a sequence of + identifiers, guessing the next one, and then using this specification + to launch an attack. + +9. Relationship with In-Reply-To + + RFC 3261 defines the In-Reply-To header field. It provides a list of + Call-IDs for calls that the current request references or returns. + It was meant to serve a similar purpose as the Reply-To in email: to + facilitate the construction of "threads" of conversations in a user + interface. Target-Dialog is similar, in that it also references a + previous session. Due to their similarities, it is important to + understand the differences, as these two header fields are not + substitutes for each other. + + Firstly, In-Reply-To is meant for consumption by a human or a user + interface widget, for providing the user with a context that allows + them to decide what a call is about and whether they should take it. + Target-Dialog, on the other hand, is meant for consumption by the + user agent itself, to facilitate authorization of session requests in + specific cases where authorization is not a function of the user, but + rather the underlying protocols. A UA will authorize a call + containing Target-Dialog based on a correct value of the Target- + Dialog header field. + + Secondly, Target-Dialog references a specific dialog that must be + currently in progress. In-Reply-To references a previous call + attempt, most likely one that did not result in a dialog. This is + why In-Reply-To uses a Call-ID, and Target-Dialog uses a set of + dialog identifiers. + + Finally, In-Reply-To implies cause and effect. When In-Reply-To is + present, it means that the request is being sent because of the + previous request that was delivered. Target-Dialog does not imply + cause and effect, merely awareness for the purposes of authorization. + +10. Example Call Flow + + In this example, user agent A and user agent B establish an INVITE- + initiated dialog through Server-A and Server-B, each of which acts as + a proxy for the INVITE. Server B would then like to use the + application interaction framework [14] to request that user agent A + fetch an HTML user interface component. To do that, it sends a REFER + request to A's URI. The flow for this is shown in Figure 5. The + + + +Rosenberg Standards Track [Page 10] + +RFC 4538 Target Dialog June 2006 + + + conventions of [19] are used to describe representation of long + message lines. + + A Server-A Server-B B + |(1) INVITE | | | + |----------->| | | + | |(2) INVITE | | + | |----------->| | + | | |(3) INVITE | + | | |----------->| + | | |(4) 200 OK | + | | |<-----------| + | |(5) 200 OK | | + | |<-----------| | + |(6) 200 OK | | | + |<-----------| | | + |(7) ACK | | | + |------------------------------------->| + | |(8) REFER | | + | |<-----------| | + |(9) REFER | | | + |<-----------| | | + |(10) 200 OK | | | + |----------->| | | + | |(11) 200 OK | | + | |----------->| | + + Figure 5 + + First, the caller sends an INVITE, as shown in message 1. + + INVITE sips:B@example.com SIP/2.0 + Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8 + From: Caller ;tag=kkaz- + To: Callee + Call-ID: fa77as7dad8-sd98ajzz@host.example.com + CSeq: 1 INVITE + Max-Forwards: 70 + Supported: tdialog + Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER + Accept: application/sdp, text/html + + Contact: ;schemes="http,sip,sips" + + Content-Length: ... + Content-Type: application/sdp + + + + +Rosenberg Standards Track [Page 11] + +RFC 4538 Target Dialog June 2006 + + + --SDP not shown-- + + The INVITE indicates that the caller supports GRUU (note its presence + in the Contact header field of the INVITE) and the Target-Dialog + header field. This INVITE is forwarded to the callee (messages 2-3), + which generates a 200 OK response that is forwarded back to the + caller (message 4-5). Message 5 might look like: + + SIP/2.0 200 OK + Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8 + From: Caller ;tag=kkaz- + To: Callee ;tag=6544 + Call-ID: fa77as7dad8-sd98ajzz@host.example.com + CSeq: 1 INVITE + Contact: + Content-Length: ... + Content-Type: application/sdp + + --SDP not shown-- + + In this case, the called party does not support GRUU or the Target- + Dialog header field. The caller generates an ACK (message 7). + Server B then decides to send a REFER to user A: + + + + REFER sips:A@example.com;gruu;opaque=urn:uuid:f81d4f + ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a SIP/2.0 + + Via: SIP/2.0/TLS serverB.example.org;branch=z9hG4bK9zz10 + From: Server B ;tag=mreysh + + To: Caller + + Target-Dialog: fa77as7dad8-sd98ajzz@host.example.com + ;local-tag=kkaz- + ;remote-tag=6544 + Refer-To: http://serverB.example.org/ui-component.html + Call-ID: 86d65asfklzll8f7asdr@host.example.com + CSeq: 1 REFER + Max-Forwards: 70 + Require: tdialog + Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY + Contact: + Content-Length: 0 + + + + + +Rosenberg Standards Track [Page 12] + +RFC 4538 Target Dialog June 2006 + + + This REFER will be delivered to server A because it was sent to the + GRUU. From there, it is forwarded to user agent A (message 9) and + authorized because of the presence of the Target-Dialog header field. + +11. IANA Considerations + + This specification registers a new SIP header field, a new option tag + according to the processes of RFC 3261 [2], and two new header field + parameters according to the processes of RFC 3968 [10]. + +11.1. Header Field + + RFC Number: RFC 4538 + + Header Field Name: Target-Dialog + + Compact Form: none + +11.2. Header Field Parameters + + This section registers two header field parameters according to the + processes of RFC 3968 [10]. + +11.2.1. local-tag + + Header Field: Target-Dialog + + Header Field Parameter: local-tag + + Predefined Values: None + + RFC: RFC 4538 + +11.2.2. remote-tag + + Header Field: Target-Dialog + + Header Field Parameter: remote-tag + + Predefined Values: None + + RFC: RFC 4538 + + + + + + + + + +Rosenberg Standards Track [Page 13] + +RFC 4538 Target Dialog June 2006 + + +11.3. SIP Option Tag + + This specification registers a new SIP option tag per the guidelines + in Section 27.1 of RFC 3261. + + Name: tdialog + + Description: This option tag is used to identify the target dialog + header field extension. When used in a Require header field, it + implies that the recipient needs to support the Target-Dialog + header field. When used in a Supported header field, it implies + that the sender of the message supports it. + +12. Acknowledgements + + This specification is based on a header field first proposed by + Robert Sparks in the dialog usage draft [12]. John Elwell provided + helpful comments. + +13. References + +13.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event + Notification", RFC 3265, June 2002. + + [4] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. + + [5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional + Responses in Session Initiation Protocol (SIP)", RFC 3262, + June 2002. + + [6] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE + Method", RFC 3311, October 2002. + + [7] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and + D. Gurle, "Session Initiation Protocol (SIP) Extension for + Instant Messaging", RFC 3428, December 2002. + + [8] Sparks, R., "The Session Initiation Protocol (SIP) Refer + Method", RFC 3515, April 2003. + + + +Rosenberg Standards Track [Page 14] + +RFC 4538 Target Dialog June 2006 + + + [9] Niemi, A., "Session Initiation Protocol (SIP) Extension for + Event State Publication", RFC 3903, October 2004. + + [10] Camarillo, G., "The Internet Assigned Number Authority (IANA) + Header Field Parameter Registry for the Session Initiation + Protocol (SIP)", BCP 98, RFC 3968, December 2004. + +13.2. Informative References + + [11] Eastlake, D., Schiller, J., and S. Crocker, "Randomness + Requirements for Security", BCP 106, RFC 4086, June 2005. + + [12] Sparks, R., "Multiple Dialog Usages in the Session Initiation + Protocol", Work in Progress, March 2006. + + [13] Rosenberg, J., "Obtaining and Using Globally Routable User + Agent (UA) URIs (GRUU) in the Session Initiation Protocol + (SIP)", Work in Progress, May 2006. + + [14] Rosenberg, J., "A Framework for Application Interaction in the + Session Initiation Protocol (SIP)", Work in Progress, + July 2005. + + [15] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- + Initiated Dialog Event Package for the Session Initiation + Protocol (SIP)", RFC 4235, November 2005. + + [16] Rosenberg, J., "A Session Initiation Protocol (SIP) Event + Package for Conference State", Work in Progress, July 2005. + + [17] Rosenberg, J., "A Framework for Conferencing with the Session + Initiation Protocol (SIP)", RFC 4353, February 2006. + + [18] Burger, E., "A Session Initiation Protocol (SIP) Event Package + for Key Press Stimulus (KPML)", Work in Progress, + December 2004. + + [19] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., + and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture + Test Messages", RFC 4475, May 2006. + + + + + + + + + + + +Rosenberg Standards Track [Page 15] + +RFC 4538 Target Dialog June 2006 + + +Author's Address + + Jonathan Rosenberg + Cisco Systems + 600 Lanidex Plaza + Parsippany, NJ 07054 + US + + Phone: +1 973 952-5000 + EMail: jdrosen@cisco.com + URI: http://www.jdrosen.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg Standards Track [Page 16] + +RFC 4538 Target Dialog June 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Rosenberg Standards Track [Page 17] + -- cgit v1.2.3