DISPATCH Working Group Sunil Kumar Sinha Internet Draft Cisco Intended Status: Informational Sankar Raman V Expires: January 2, 2017 Cisco June 3, 2016 Only Incremented header transmitted in Session Initiation Protocol (SIP) draft-sunil-sankar-dispatch-sip-incr-00.txt Abstract This document outlines a new optional tag called "incr" as an extension for the SIP Message indicating that only those header(s) will be present in the subsequent request or response whose attribute is changed. This is necessary to increase the processing speed of any proxy server and also prevents fragmentation of messages over UDP and provides congestion control for larger messages in the Session Initiation Protocol. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. 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." This Internet-Draft will expire on January 2, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction............................................02 2. Terminology.............................................02 3. Motivation..............................................02 4. Over all operation......................................03 5. Security Considerations.................................03 6. IANA Considerations.....................................03 Sunil_&_Sankar Expires January, 2017 [Page 1] Internet-Draft SIP incr Option Tag June 2016 6.1. IANA Registration of the incr Option Tag.........03 7 Normative References....................................03 8. Authors' Address........................................04 1 Introduction The Session Initiation Protocol (RFC 3261 [1]) is a request-response protocol for initiating and managing communications sessions. This request-response contains a number of headers. There are six mandatory headers (To, From, CSeq, Call-ID, Max-Forwards and Via) which are the fundamental building blocks of a SIP message. They jointly provide for most of the critical message routing services including the addressing of messages, the routing of responses, limiting message propagation, ordering of messages, and the unique identification of transactions. The main motivation of addition headers in SIP message to provide facility in finding and establish a session with desire destination. It is observed that there is a less need of additional headers once the session is established successfully. The request-response which is sent after the session is established is actually a burden over the network as it consumes the network bandwidth. Proxy has to process these additional header each time which results in the resource consumption and delay in processing. Therefore, a negotiation mechanism is needed to eliminate unnecessary headers from the SIP message which is described in this specification. This negotiation is intended to work between end-to-end SIP entities. 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[2]. 3 Motivation Over the course of last decade, the demand for SIP has increased significantly among enterprises and individuals due to its low cost. This increasing demand in turn puts load and reduces the network bandwidth. The problem arrives when sip proxy is busy with the client requests and more requests arrive from new clients. At such times the server starts to drop the calls. The challenge is to find out the ways by which the latency and packet loss of SIP messages can be decreased. Various investigation models were suggested for the sip proxy entity on overcoming this issue. The negotiation mechanism described in this document can be implemented so that the resources can be freed up from all of the intermediate network elements involved in the SIP session so that more calls can be attempted due to high bandwidth availability without any additional cost. Sunil_&_Sankar Expires January, 2017 [Page 2] Internet-Draft SIP incr Option Tag June 2016 4 Over all Operation The Operation of this extension is straightforward. For User's sake, let us consider a simple case where both sides support this extension. The User Agent Client (UAC) starts the dialog by sending an INVITE Method. This Method includes a Supported header field with the option tag "incr", indicating the support for this extension. This request passes through intermediate proxies and eventually arrives at the User Agent Server (UAS). The UAS, which also support this extension, will also include a require header field with the option tag "incr" in the 2XX response. The 2xx response travels back through the proxy chain and both UA will know each of their capabilities. Once the dialog is established, either User Agent (UA) can (apart from six mandatory headers) include only those headers whose field value has been changed or being added or new header which is required in the subsequent request-response. If any one of the UAS do not support this extension, then the current behavior of dialog is followed as mentioned in RFC 3261. 5 Security Considerations The option tag "incr" in this document does not have security considerations by itself. However, as mentioned in RFC 5727[3], an important reason for the IETF to manage the extensions of SIP is to ensure that all extensions and parameters are able to provide secure usage. 6 IANA Considerations This document registers a new option tag based on the IANA registration process of RFC 3261. 6.1 IANA Registration of the "incr" Option Tag This specification registers a single option tag, incr. The required information for this registration, as specified in RFC 3261, is: Name: incr Description: This option tag is for informing the UA that only header having increment field value will be transmitted after the session established. When present in a Supported header, it indicates that the UA can send or receive only header having increment field value. When present in a Require header in a request, it indicates that the UAS MUST send or receive only header having increment field value. 7 Normative References Sunil_&_Sankar Expires January, 2017 [Page 3] Internet-Draft SIP incr Option Tag June 2016 [1] 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. [2] S. Bardner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [3] J. Peterson, C. Jennings, and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", RFC 5727, March 2010. 8 Authors' Addresses Sunil Kumar Sinha SEZ Unit, Cessna Business Park, Kadubeesanahalli Village, Varthur Hobli, Sarjapur - Marathahalli Outer ring road, Bengaluru, Karnataka 560087 EMail: sunsinha@cisco.com Sankar Raman. V SEZ Unit, Cessna Business Park, Kadubeesanahalli Village, Varthur Hobli, Sarjapur - Marathahalli Outer ring road, Bengaluru, Karnataka 560087 EMail: sramanv@cisco.com Sunil_&_Sankar Expires January, 2017 [Page 4]