Internet DRAFT - draft-sunil-sankar-dispatch-sip-incr
draft-sunil-sankar-dispatch-sip-incr
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]
