Internet Engineering Task Force MMUSIC WG Internet Draft Casey Ong / Sha He draft-onghe-mmusic-sip-propose-00.txt Kent Ridge Digital 16th June 1999 Labs Expires November 1999 The SIP PROPOSE Method Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document proposes an extension to the Session Initiation Protocol, RFC-2543[3]. The extension adds the PROPOSE method to the SIP protocol. The intend of the PROPOSE method is to allow a Media Gateway or other types of server that is serving a SIP node in a live session to propose a revised session setting to the node due to changes in network or other constraints of the current session. An example of revised session setting could be a suggestion to the node to lower its quality of service or choose a lower bandwidth codec due to an increase in network traffic. C. Ong, S. He Internet Draft - Expires November 1999 [Page 1] draft-ietf-mmusic-sip-propose-00.txt 16th June 1999 2. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Definitions In addition to those defined in section 1.3 of RFC-2543[3], following are defined: Media Gateway: A network device or an application that provide media or user application specific gateway service to the user in a multimedia session. An example could be an Audio Gateway that allocate appropriate network resources to each audio channel under its service domain so as to guarantee certain quality of service for each channel. 4. Introduction SIP provides a simple yet effective and flexible text based mechanism to initiate a multimedia session. It also allows a session participant to re-negotiate a new session setting in a live session by initiating a new SIP INVITE transaction with a new session description. With successful completion of the INVITE transaction, the new session setting is used immediately for the live session. However, the re-negotiation of session setting for a live session is only available to the session participants, not the Media Gateways that are providing their services to the session participants. In most of the multimedia communication in the current and future Internet, there will be forms of Media Gateways that will provide their services to ensure certain quality and security in the communications. These Media Gateways essentially monitor the traffic and other constraints in the network and allocate appropriate resources to each media channel under their respective domains. There is a need to provide a feedback mechanism for a Media Gateway to suggest a new session setting to the respective session participant under its domain when need arise, e.g., due to the unforeseen surge of network traffic. C. Ong, S. He Internet Draft - Expires November 1999 [Page 2] draft-ietf-mmusic-sip-propose-00.txt 16th June 1999 PROPOSE method will provide such mechanism. In this case, a Media Gateway will just need to implement a SIP Client to initiate a PROPOSE SIP Request with the proposed SDP (Session Description Protocol) of the respective participant. The participant will just need to acknowledge the receive of the request. It will then act or ignore the request accordingly to its application logic, i.e., the ultimate decision to initiate a change of the session setting based on the feedback is still dependent on the user not the Media Gateway. A SIP based type of feedback mechanism for the Media Gateway has many benefits. Firstly, it is be open, allowing different vendor Media Gateway to make use of this mechanism. Second, computation intensive intelligence could be deployed in the central Media Gateway or server. Such intelligence could monitor the overall network traffic, suggest appropriate session setting based on the input policies. Finally, as the SIP session participant has already implemented the SIP User Agent, it needs little additional intelligence to be network sensitive. 5. PROPOSE Method A Media Gateway sends a PROPOSE SIP request to suggest a new session description to a user or service that is participating in a live session. It is assumed that the Media Gateway is providing some sort of network service to the user and has the current session description of the session. When a SIP user agent receives a valid PROPOSE request as defined in section 5.1 for its user, it will send back a 200 OK response regardless if the user is going to initiate a change in session description of the session. The PROPOSE method does not change the state of the session, and it is mainly designed for a session that is already established, but is also possible for a session that is still establishing. 5.1. Request Message These are the important header fields in a valid PROPOSE request: To: The To header field contains the address of the user that is participating in the referenced live session. From: The From header contains the address of the Media Gateway. This address should be known to the user. C. Ong, S. He Internet Draft - Expires November 1999 [Page 3] draft-ietf-mmusic-sip-propose-00.txt 16th June 1999 Call-ID: This is the same Call-ID of the referenced live session as far as the Media Gateway is concerned. Authorization: The Media Gateway may wish to authenticate with the user by including an Authorization header with the request. The Authorization field consists of credentials containing the authentication information of the Media Gateway for the realm of the network environment shared by the user and the Media Gateway. The PROPOSE request message MUST include a message body. Currently, only SDP message is identified. This SDP message describes the session setting specific to the targeted user. It typically is modified from the original SDP message body of the live session. 5.2. Response Message Other than the 200 OK response, following are the most likely final responses that could be generated from the user: 400 Bad Request: When the syntax of any the important request header field is malformed. 401 Unauthorized: The Media Gateway needs to provide the credentials in the Authorization field. 411 Length Required: The user refuses to accept the request without a defined Content-Length header field containing the length of the message body in the request message 481 Call Leg/Transaction Does not exist: When the referenced Call-ID in not valid as far as the user is concerned. 501 Not Implemented: The server does not support the PROPOSE method. These final responses for the PROPOSE method SHOULD not include any message body. 5.3. Header Fields Summary The "where" column describes the request and response types with which the header fields can be used. "R" refers to header fields that can be used in requests (that is, request and general header fields). "r" designates a response or general-header field as applicable to all responses, while a list of numeric values C. Ong, S. He Internet Draft - Expires November 1999 [Page 4] draft-ietf-mmusic-sip-propose-00.txt 16th June 1999 indicates the status codes with which the header fields can be used. "g" and "e" designate general (Section 6.1 of RFC-2543[3]) and entity header (Section 6.1 of RFC-2543[3]) fields, respectively. If a header field is marked "c", it is copied from the request to the response. where PROPOSE ______________________________________ Accept R - Accept 415 - Accept-Encoding R - Accept-Encoding 415 - Accept-Language R - Accept-Language 415 - Allow 200 - Allow 405 o Authorization R o Call-ID gc m Contact R - Contact 1xx - Contact 2xx - Contact 3xx - Contact 485 - Content-Encoding e o Content-Length e m Content-Type e * CSeq gc m Date g o Encryption g o Expires g o From gc m Hide R o Max-Forwards R o Organization g o Table 1: Summary of header fields, A--O 6. Behaviors of the SIP Servers with respect to PROPOSE method In general, there is no special consideration for handling PROPOSE request and response as far as the SIP servers are concerned. Obviously, for PROPOSE request, only 100 Trying provisional response SHOULD be sent by User Agent, Redirect Server and all types of Proxy Servers to indicate the in-progress of reaching the targeted user. C. Ong, S. He Internet Draft - Expires November 1999 [Page 5] draft-ietf-mmusic-sip-propose-00.txt 16th June 1999 7. Security Considerations It is very likely that Media Gateway is in the same security realm as the session user it is serving. In such situation, there is of little security concerns. However, SIP has catered the Authorization header field and WWW-Authentication header field, and other security measures, and they SHOULD be used if the communication link between the Media Gateway and user is not under the same security realm. 8. Acknowledgements We wish to thanks Dr. Michael Krautgartner and Mr. Hendrik Decker of Siemens for our discussion in Session Adaption Management in the project, MOVE (Mobile Middleware with Voice Enabled Services) which is a 3G Mobile project funded by EC(European Community) and (TAS)Telephone Authority of Singapore. 9. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Handley, M., Schulzrinne, H., Schooler E., Rosenberg J., "SIP, Session Initiation Protocol", Internet Engineering Task Force, RFC 2543, March 1999 C. Ong, S. He Internet Draft - Expires November 1999 [Page 6] draft-ietf-mmusic-sip-propose-00.txt 16th June 1999 10. Author's Addresses Casey Ong Kent Ridge Digital Labs 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65 8743110 Email: caseyong@krdl.org.sg Sha He Kent Ridge Digital Labs 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65 8746774 Email: hesha@krdl.org.sg Full Copyright Statement "Copyright (C) The Internet Society (date). 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 implmentation 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 C. Ong, S. He Internet Draft - Expires November 1999 [Page 7]