SIP Working Group H. Kaplan Internet Draft Acme Packet Intended status: Standards Track C. Holmberg Expires: May 8, 2008 Ericsson November 8, 2007 SIP INFO Event Framework draft-kaplan-sip-info-events-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May 8, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines a proposed solution for defining, negotiating and exchanging info-event notifications in INFO messages, within SIP invite-created dialogs, for applications which need to exchange session-related information inside the invite-created dialog. This draft addresses issues and open items from RFC 2976, and updates it. Kaplan Expires May 8, 2007 [Page 1] SIP INFO Events Framework November 2007 Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. Applicability...............................................3 4. Overview of Operation.......................................3 5. Event Negotiation...........................................4 5.1. UAC Behavior...........................................4 5.2. UAS Behavior...........................................5 6. INFO Method.................................................6 7. Re-Invites and usages and forks, oh my!.....................7 8. New Headers.................................................7 9. Example Exchange............................................8 10. Security Considerations.....................................9 11. IANA Considerations........................................10 12. References.................................................10 12.1. Normative References..................................10 12.2. Informative References................................10 Author's Address.................................................10 Intellectual Property Statement..................................11 Full Copyright Statement.........................................11 Acknowledgment...................................................11 1. Introduction The SIP INFO method was defined in [RFC2976] to convey session related control information inside an Invite-created dialog. While it has been widely adopted for specific application use cases, such as ISUP and DTMF exchange, the original RFC did not define a negotiation mechanism nor a means by which to explicitly indicate the type of application information contained in the INFO. This led to problems associated with static configuration, and potential interoperability problems due to undefined content syntax and semantics. This draft aims at addressing those deficiencies, to provide a framework for explicit negotiation of capabilities and content context using info-event packages. This draft is meant to update [RFC2976] SIP INFO. The INFO method as defined in [RFC2976] does not provide any context for the information which it carries. While it may sometimes be clear what the content is, based on the Content-Type, such is only true while only one contextual usage of the content-type is ever employed. For example, if the Content-Type were "image/jpeg", it would be clear that the MIME-attached content was a JPEG image, but not what its purpose was. It could be being sent as a caller-id picture, or as a contact-icon, or whatever. The sender is not sure which JPEG to give the receiver if it supports a JPEG content-type, Kaplan Expires - May 2007 [Page 2] SIP INFO Events Framework November 2007 and the receiver does not know which JPEG is being sent if it supports receiving more than one. Thus there needs to be a well- defined and documented statement of what the information sent is for. Event packages, as defined in [RFC3265] perform that role for Subscription-based events, whereas this document provides a similar framework for Invite-based events. Unlike [RFC3265], the mechanism defined in this draft is not based on the usage of the SUBSCRIBE and NOTIFY methods, and does not create a separate subscription dialog or a subscription usage within an existing dialog. Instead, it uses the INVITE method and its responses to indicate and negotiate supported Event packages, and the INFO method to convey the events. This mechanism is not appropriate for all IANA-registered Subscribe Event package types, and support for this mechanism should be explicitly indicated in future Info-Event package definitions and registrations. When the invite-created dialog is terminated the lifetime of the negotiated invite-events is also terminated. 2. 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. The terminology in this document conforms to RFC 2828, "Internet Security Glossary". 3. Applicability This draft proposes updating the [RFC2976] SIP INFO method to include explicit negotiation of supported info-event packages in the INVITE transaction, and indication of the indicated event using a new header in the INFO request. 4. Overview of Operation The general concept is that the UAC generating an INVITE request includes the Event packages it supports sending and receiving, in two new headers: Send-Event and Recv-Event. If the UAS supports this mechanism, it responds with the info-event packages it wishes to actually receive and send in the same named headers (in reverse), in the provisional and final responses. When either side has indication of what the far-end supports, it may send the information defined by the info-event package in an INFO request, following the same INVITE-created dialog and usage, as per [RFC2976]. The INFO request indicates the specific info-event package it is associated Kaplan Expires - May 2007 [Page 3] SIP INFO Events Framework November 2007 with, using an Event header with the package name, and any associated MIME-attached body defined for that Event package. 5. Event Negotiation The UAC and UAS MUST negotiate which event packages are supported and will be used in which direction, before sending an INFO message for any specific event package. Negotiation always starts with the UAC indicating which event packages it supports and wishes to send or receive, using the two new headers "Send-Event" and "Recv-Event", in the INVITE request. The UAS always indicates which events, of those offered by the UAC, it wishes to accept for sending and receiving to/from the UAC in its responses. 5.1. UAC Behavior A UAC supporting this draft MAY indicate one or more event packages it wishes to support sending during the Invite dialog, by including their package names in the "Send-Event" header in the INVITE request. Not including the Send-Event header in the INVITE means the UAC does not have an intention, and MUST NOT, send any invite- events during the dialog. The UAC MAY indicate one or more event packages it wishes to support receiving during the Invite-created dialog, by including their package names in the "Recv-Event" header in the INVITE request. Not including the Recv-Event header in the INVITE means the UAC will not accept info-events during the dialog. When the UAC receives a Recv-Event header in any provisional 1xx or 2xx response, it is an indication from the far-end UAS that it (the UAS) supports receiving the indicated event indications. Any indicated Recv-Events from the UAS which were not offered by the UAC in a Send-Event MUST be ignored, and MUST NOT constitute a protocol failure. Kaplan Expires - May 2007 [Page 4] SIP INFO Events Framework November 2007 When the UAC receives a Send-Event header in any provisional 1xx or 2xx final response, it is an indication from the far-end UAS that it (the UAS)_supports sending the indicated event indications. Any indicated Send-Events from the UAS which were not offered by the UAC in a Recv-Event MUST be ignored, and MUST NOT constitute a protocol failure. Once an early dialog is established, through a 1xx provisional response with To-tags, and the UAC has received a Recv-Event header from the UAS in the response, the UAC MAY send any event indications supported by the UAS. The 2xx final response updates the state of the event packages, such that the 2xx contains the full and final list of Send-Event and Recv-Event packages. If the 2xx does not contain a Send-Event header, the UAS is indicating it will not send any, and if it does not contain a Recv-Event header, the UAS will not accept any, regardless of what a previous 1xx response might have indicated. At this point negotiation is considered complete. 5.2. UAS Behavior When a UAS receives an INVITE request, it checks for a Send-Event and Recv-Event headers. One or both may exist. For each event package name in the received Send-Event header, the UAS decides if it wishes to accept receiving such events from the UAC. If so, it MUST copy the name(s) of those acceptable events into a Recv-Event header in any, and all subsequent, provisional 1xx and final 2xx responses. For each event package name listed in the received Recv-Event header, the UAS decides if it wishes to send such events to the UAC. If so, it MUST copy the name(s) of those events it wishes to generate into a Send-Event header in any, and all subsequent, provisional 1xx and final 2xx responses. Note that "any, and all subsequent," means that the UAS may decide not to indicate any events in early 1xx responses; but once it indicates such in a 1xx, it must continue to do so in subsequent responses including the final 2xx response in order to keep the event indication support state the same. The UAS MUST NOT send any INFO messages with info-events until it has received an acknowledgement (e.g. PRACK for a provisional response, or an ACK for a final response it sent) that the UAC has received the SIP response sent by the UAS, indicating that the UAC has received the Send-Event header from the UAS. This assures the UAC can perform any necessary logic it needs to in order to receive the event, and can associate the INFO with the proper dialog. Kaplan Expires - May 2007 [Page 5] SIP INFO Events Framework November 2007 NOTE: Unlike the NOTIFY method, the INFO method CAN NOT be used to establish a dialog. 6. INFO Method The INFO method as defined in [RFC2976] is update by this draft with a new "Event" header, which is identical to the header by the same name for SUBSCRIBE and NOTIFY methods. As in those methods, the "Event" header in an INFO request will contain a single info-event package name for which a notification is being signaled by the INFO request. The package name in the "Event" header MUST match one of the event packages received in the "Recv-Event" header in the received INVITE for the UAS, or response for the UAC. In other words one can only send what the other end is willing to receive. Event packages may define semantics associated with the body of their INFO requests; if they do so, those semantics apply. INFO bodies are expected to provide additional details about the nature of the event which has occurred and the resultant resource state. [NOTE: do we need to support the "id" concept as well? Is there a use case?] As per [RFC2976], the INFO method can only be used within an INVITE- generated dialog (early or full) and usage. It has no lifetime or usage of its own, as it is inexorably linked to that of the INVITE. The dialog identifiers defined in [RFC3261] must match those of the provisional or final responses to the INVITE, and as a result INFO requests do not fork. INFO requests may be sent in either direction, once the UAC or UAS has received the Send-Event/Recv- Event indications of what the far-end supports. For the UAS, it must receive the ACK for the INVITE's 200-ok, or the PRACK for a provisional response, before sending an INFO request. In other words it must know the far-end has received its indication of what events it is willing to send before it sends them. Kaplan Expires - May 2007 [Page 6] SIP INFO Events Framework November 2007 7. Re-Invites and usages and forks, oh my! A Re-INVITE or UPDATE request MUST NOT contain any Send-Event or Recv-Event headers, and such headers MUST be ignored on reception. The info-event package negotiation is performed during the initial INVITE transaction, and there is no re-negotiation. [Is that ok? Is there a need to have re-negotiation? (is there a use case?) It sure makes it simple not to have things change in the middle of a session] There is no separate "usage" for the INFO request, as defined by [RFC5057]. The INFO is related to but not integral to the Invite usage, such that some failure responses to an INFO request do not affect the Invite usage whatsoever, as described in [RFC5057]. Other failures may terminate the usage or dialog completely. The lifetime of info-events and thus is exactly the same as that of the Invite. If an Invite usage fails or is terminated, the Info-based event state no longer exists, and an INFO request MUST NOT be sent. The original INVITE request may be forked along the path, resulting in multiple 1xx provisional responses, each with a separate set of send/receive info-event packages supported. It is typically up to local-policy to determine how to handle such situations, however it should be clear that an INFO request does not itself fork, since it uses the dialog identifiers and thus follows the path to a specific fork. 8. New Headers [Should the new headers be optional for OPTIONS and REGISTER?] Header field where proxy ACK BYE CAN INV OPT REG PRA --------------------------------------------------------- Send-Event R - - - o - o - Send-Event 2xx - - - - o o - Recv-Event R - - - - - o - Recv-Event 2xx - - - o o o - Recv-Event 18x - - - o o - - 8.1 "Send-Event" header [Todo: Insert text] Kaplan Expires - May 2007 [Page 7] SIP INFO Events Framework November 2007 8.2 "Recv-Event" header [Todo: Insert text] 8.3 Augmented BNF Definitions Send-Event = "Send-Event" HCOLON 1*(invite-event-package *( SEMI invite-event-param )) Recv-Event = "Send-Event" HCOLON 1*(invite-event-package *( SEMI invite-event-param )) invite-event-package = token-nodot token-nodot = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) Invite-event-param = generic-param / ( "id" EQUAL token ) 9. Example Exchange In the following example, Alice initiates a call to Bob. Alice can support sending or receiving "foo" events, and sending "bar" events. Alice generates the following: (note: much has been left out for simplicity) INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 From: Alice ;tag=1234567 To: Bob Call-Id: 123456mcmxcix CSeq: 1 INVITE Contact: Send-Event: foo, bar Recv-Event: foo Bob checks the headers, can support sending but not receiving "foo", and sending but not receiving "bar". Note that since Bob does not support receiving anything Alice can send, the response does not list any Recv-Event events. SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 From: Alice ;tag=1234567 To: Bob ;tag=abcdefg Call-Id: 123456mcmxcix CSeq: 1 INVITE Send-Event: foo Kaplan Expires - May 2007 [Page 8] SIP INFO Events Framework November 2007 Since he sent the Send-Event header in the 180, Bob also sends it in the 200. SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 From: Alice ;tag=1234567 To: Bob ;tag=abcdefg Call-Id: 123456mcmxcix CSeq: 1 INVITE Contact: Send-Event: foo Alice can send an info-event as soon as she received the 180, but in this example she would not have been able to since Bob didn't say he could receive any Info-based events in his 180 response. Bob must wait to receive the ACK before sending any "foo" events (ACK not shown), at which point he sends the following: INFO sip:alice@192.0.2.1 SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Alice ;tag=1234567 From: Bob ;tag=abcdefg Call-Id: 123456mcmxcix CSeq: 2 INFO Contact: Event: foo 10. Security Considerations There are no specific security issues for this mechanism, beyond those already applicable to SIP-based session signaling. One interesting property of Info-based event indication is that the same digest-challenge mechanism used for Invite-based authentication can be reused for the INFO request. However this assumes the device which knows the credentials in order to perform the Invite challenge is still in the path for the INFO, or that the far-end UAS knows such credentials. Kaplan Expires - May 2007 [Page 9] SIP INFO Events Framework November 2007 11. IANA Considerations This document will define an info-event-type namespace, the specifics of which are TBD. 12. References 12.1. Normative References [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [RFC3261] 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. 12.2. Informative References [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, February 2007 Author's Address Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: hkaplan@acmepacket.com Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Kaplan Expires - May 2007 [Page 10] SIP INFO Events Framework November 2007 Intellectual Property Statement 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. Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kaplan Expires - May 2007 [Page 11] SIP INFO Events Framework November 2007 The authors wish to thank Brian Stucker, Francois Audet, Paul Kyzivat, Adam Roach, Eric Burger, Robert Sparks for their suggestions and comments; and for Dean Willis, who was ahead of his time, having submitted a similar draft 5 years ago. Kaplan Expires - May 2007 [Page 12]