CA2349957A1 - Method for using a sip header - Google Patents

Abstract

The Session Initiation Protocol (SIP) is a highly flexible and extensible signalling protocol used in Internet (IP) telephony. As per the internet's nature, two peers engaged in a SIP session might not be from the same vendor, and/or might not implement the same set of capabilities and SIP extensions. For example, vendors might sometimes want to add or remove capabilities, as some implementations can be customized to fit the resources available to embedded devices, or the features required by the vendor's clients. This invention provides a flexible and easily extensible method of adding or removing the ability of understanding, accessing and creating certain SIP structures, at compile time.

Description

TITLE OF THE INVENTION
METHOD FOR USING A SIP HEADER
FIELD OF THE INVENTION
The present invention relates to Internet telephony. More specifically, the present invention is concerned with a method for using a SIP header.
BACKGROUND OF THE INVENTION
SIP (Session Initiation Protocol) is an ASCII text-based peer-to-peer signalling protocol running on top of the IP (Internet Protocol) layer. It is an extensible and flexible protocol, and as a result implementations can sometimes differ in the capabilities that they support.
For example, two different vendor's SIP applications may interact, each supporting a different set of SIP extensions. In that case, the session can be created using the extensions and capabilities that both vendors support.
At the implementation level, SIP capabilities are supported in two ways. A first implementation requirement of SIP is to parse the data exchanged on the Internet, to figure out what capabilities are supported by the peer. The opposite of this operation is the creation of the ASCII
text strings (SIP Messages) that must be sent on the network to the peer that is the source of the incoming data. The second implementation requirement is the logical utilization of these capabilities.
In the SIP Stack, a need for customizability emerges from the fact that different vendors will probably require different SIP
capabilities. The basic implementation of SIP is discussed by M. Handley et al. in "SIP: Session Initiation Protocol", November 2000, IETF (Internet Engineering Task Force).
Shortcomings have arisen and extensions to the SIP
protocol have emerged to fill-in for these shortcomings. For example, basic call transfer is not a part of the basic SIP specification, but is defined in a SIP-based extension (see R. Sparks, "SIP Call Control Transfer", November 2000, by IETF). Some extensions merely point out a new way of using pre-existent SIP functionalities, while others add new semantics, syntax and call flows to the SIP core.
A SIP message is conveyed from endpoint to endpoint on the Internet. The message contains either a request or a response line, as defined in the core SIP protocol. Next, the message contains a series of lines that SIP refers to as "headers". SIP Headers are used to convey specific information about the capabilities or the current session going on between the endpoints. Typical headers found in SIP messages are the originating address, and the destination address. It is by understanding and replying to those header messages that the session can be set up for both peers.

A method that allows a compile-time selection of which SIP
headers to use in the course of the Session Initiation and that also allows the customers using the stack to implement and seamlessly attach new kinds of header parsers to the stack is thus desirable.
BRIEF DESCRIPTION OF THE DRAWINGS
In the appended drawings:
Figure 1 is a block diagram illustrating the relationships between the different entities of a SIP header module according to an embodiment of the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENT
This invention provides a method to customize the application at compile time and customize which SIP headers are to be used by the Sip Stack, and thus by the vendor's application. This method also allows vendors to override old headers, and/or add their own.
The method according to the present invention includes two steps:
Step 1 includes "registering" the kinds of headers that are to be handled, to customize the application and providing a way to add new headers.

Step 2 includes accessing and controlling features included with the headers once the headers have been "registered".
According to a preferred embodiment of the present invention, a combination of C++ or another object-oriented programming language features, macros and object-oriented programming are advantageously used to provide the functionality of steps 1 and 2.
More specifically, step 1 is achieved using compile-time definitions and exclusions. A benefit from this is that unsupported headers completely disappear at compile-time, thus reducing the size of the compiled application.
A class is created for each kind of header that are supported in the SIP Stack. For each of these headers, a define must be created, and the class' existence is conditional to this define. Example:
#ifdef EXAMPLE HEADER
class EXAMPLE HEADER
// class definition here #endif To take advantage of the method according to the present invention, a customer using the stack declares the EXAMPLE HEADER
define during compilation of the SIP stack. If the define is not defined, the class does not exist at all.
Next, the header types are configured in the stack by having the SIP stack use a Factory pattern. A factory is an entity that maintains 5 a list of similar (but not identical) items (in this case, headers). Using a given data element, the factory has the ability to search through its list and identify a specific item. The factory then generates a copy of that item. In the case of the present invention, we use the header name as the uniquely identifying data element. The benefit of a factory is that it replaces a static conditional structure by a dynamic structure, and it can even be modified at run-time.
Preconditions to using a Factory Pattern are:
- All header classes implement a functionality that can look at the data element and determine if they can handle that element. No two header classes answer "yes" for the same data element.
- Object-Orientedly speaking, all headers have a common parent. The factory uses that common parent to abstract the fact that all the headers are actually different.
Step 2 is advantageously achieved by creating a C++ class to abstract the concept of SIP Message as discussed previously. This class will be used as a bridge between the vendor application and the core SIP Stack modules (the SIP headers source code). Then macros containing a generic interface that can be used to access any one header are defined. Each header customizes the macro by defining it in a header (.h) file. For example, HDR_INTERFACE(EXAMPLE HEADER) will generate the interface to access that header. All the macro definitions are then introduced in the "SIP Message" class by using an #include statement, thusly adding these interface functions to the "SIP Message"
class' interface.
From there, the vendor application is free to access directly any header that was found in the SIP message using the generic interface, and then interact with the header directly.
A benefit from the method according to an embodiment of the present invention is that the vendor can choose to customize the current SIP stack (by defining which headers to use). Another benefit is that a vendor could also choose to create its own headers, and add them for the stack to use. Doing so is as simple as creating the new header class, adding that header to the factory's list, and defining the correct macro for the class (making sure it is included in the SIP message class).
Turning now to Figure 1 of the appended drawing, the method according to the present invention will be summarized.
1- The vendor application registers Hdr1 and Hdr2 to the factory;
2- The factory actually uses the base class interface;
3- All header classes registered in the factory are children of the header base class;

4- To parse a header, the SIPMessage class asks the factory to find a class that can handle a given data indicator;
5- The SIPMessage class will actually use the base header class' interface to parse the headers. SIP Message does not know that the header he uses is of type Hdr1 or Hdr2. Preferably, the SIPMessage keeps only references on Header bases. All headers can identify themselves if the need arises (for example, in our implementation, the access macros rely on a search method that uses every header's capability to identify itself).
6- The vendor code can gain access to Hdr1 or Hdr2 directly by using the access interface provided by the macros that have been defined for Hdr1 and Hdr2 and included in SIP Message's interface. The Vendor code works directly with Hdr1 and Hdr2 from that point.
This method allows any user of the SIP Stack to change the list of supported headers, and to add their own headers to the stack. Since SIP is designed to be extensible (new extensions and services may be added) and flexible (some extensions and services are optionally supported), this design will help anyone that wishes to implement new extensions or services.
This solution is not limited to SIP headers, or to SIP in particular. The same pattern could be reused in many fields. Any application that requires customization of the interface to many objects of the same type could benefit from the invention described in this document.
Although the present invention has been described hereinabove by way of preferred embodiments thereof, it can be modified without departing from the spirit and nature of the subject invention, as defined in the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A method for using a SIP header as recited herein.