Browse Prior Art Database

A method to mandate compression in a SIP session

IP.com Disclosure Number: IPCOM000168342D
Original Publication Date: 2008-Mar-07
Included in the Prior Art Database: 2008-Mar-07
Document File: 6 page(s) / 256K

Publishing Venue

Motorola

Related People

Vignesh karthik. M: INVENTOR [+2]

Abstract

As devices using Session Initiation Protocol (SIP) increase, it is required to define a way for optimal usage of the available bandwidth. SIP addresses this problem by Signaling Compression (SIGCOMP). A device can choose to compress its message to the next hop after detecting its compression capability. RFC 3486[1] provides a mechanism to discover the compression capability of the next hop (a proxy or a User Agent). An alternative method using the current SIP infrastructure extensively to discover and mandate compression within a transaction is described in this disclosure.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 31% of the total text.

A method to mandate compression in a SIP session

By Vignesh karthik. M,

Narayanan Gayathri

 

ABSTRACT

As devices using Session Initiation Protocol (SIP) increase, it is required to define a way for optimal usage of the available bandwidth.  SIP addresses this problem by Signaling Compression (SIGCOMP).  A device can choose to compress its message to the next hop after detecting its compression capability.  RFC 3486[1] provides a mechanism to discover the compression capability of the next hop (a proxy or a User Agent).  An alternative method using the current SIP infrastructure extensively to discover and mandate compression within a transaction is described in this disclosure.

PROBLEM

There are limitations in detecting and mandating compression in a transaction.  They are listed below.

·        It is desirable to have a method wherein a User Agent (UA) can mandate compression in all incoming traffic.  A UA with limited bandwidth might want to mandate compression for an incoming response.  Operators might prefer compression in all traffic through an outbound proxy serving a number of UAs for optimized bandwidth usage.  However, it is not possible for a UA to mandate the remote UA (server or another UA) to compress the response.  According to [1], a client can only express its willingness to receive compressed responses by adding comp=sigcomp in its via header.  The server in this case is not mandated to compress the response as per [1].

·        In a scenario where the client sends an uncompressed request with comp=sigcomp in its via and contact header and receives an uncompressed response, the client cannot confirm the non-availability of the feature because the server is not mandated to send a compressed response as per [1].  The server might have chosen not to apply compression considering various possible factors.

·        [1] itself does not recommend the usage of NAPTR/SRV/DNS to detect next hop's compression capability as the number of intermediary layers tend to grow up and the solution is not scalable.  Further, [1] prohibits the UA from sending a compressed request to another without confirming remote UA’s capability.

SOLUTION

The solution recommends a sip extension for signaling compression of the format x=y, where x=compression and y=compression_mechanism.  Since sigcomp is the chosen compression mechanism in the SIP world, the sip extension becomes compression=sigcomp.  This sip extension for signaling compression satisfies all the recommendations proposed in RFC 4485 [2].  The solution also relies on the usage of existing SIP headers namely Require, Supported, Proxy-Require and Unsupported headers.    The rules of the solution are given below for a user agent client (UAC), user agent server(UAS) and proxy.

Behaviour of a UAC

·        A UA wishing to mandate compression in a transaction with a remote U...