An Overview to SIP Extensions
-- Project of Multimedia Wired/Wireless Internet

Yinghua Jia

Department of Computer Science
University of Waterloo
July 29, 2001

1. Introduction

SIP (Session Initiation Protocol) is a flexible, yet simple protocol for initiating, modifying and terminating interactive sessions over Internet.  With the growing needs for personal mobility and spontaneous network features, various ways are employed to extend SIP to fit the specific request.  Generally, based on which part of SIP is extended, extensions to SIP can be categorized into four classes: new headers, new methods, new body type and new parameters for existing headers.  In order to facilitate effective and interoperable extensions to SIP, certain rules need to be followed when developing extensions to SIP. 
In this paper, I will first present some guidelines for how to extend SIP.  In section 3, I will present several SIP extensions, and by stepping through how these extension work, I will give evaluations regarding to the guidelines. 

2. Guidelines for Extensions to SIP

SIP is designed to provide specific, narrow functions instead of implementing all the communication requirements between a pair of devices. For example, SIP is only responsible for initiating and terminating a call. All the processing of the call, media types and any other detailed underlying network communication protocols are transparent to SIP. Therefore, SIP is like a co-ordinator of a conference. It brings all the participants into the session, but all the detailed ongoing processing are beyond the responsibilities of SIP. 
Based on the design goals of SIP, it has the following features:
•	Flexibility: SIP can be used in different applications such as Networked Appliances Communication over Internet, Intelligent Network, Spontaneous Conference and so forth.
•	Extensibility: since SIP only provides the framework and limited fundamental functions, it can be easily modified and extended to facilitate different requirements.
•	Scalability: since SIP is a lightweight protocol, it would not bring significant impact on the network traffic when more users are added to the SIP enabled network.
•	Interoperability: SIP is not a strict protocol. That is, if there are some extensions made by the 3rd party that is not understood by some receivers, they just discard the part that they do not understand and only response to understandable parts.
In order to maintain these features, all extensions to SIP should at least satisfy two basic criteria.  First, the extension falls in the SIP solution space.  Second any extension should not violate the underlying architecture model SIP assumes.  And this will bring the additional benefit of reducing interactions between added features, which I will discuss about in the final section.  In addition to the above general guidelines, there are other issues need to be addressed such as backwards compatibility, security and semantics.  Different types of extensions also require different considerations.

2.1 SIP Solution Space
Although SIP can be used to solve different problems, there are common characteristics among the services SIP provides. We assume that if there are similar problems in the future, they can be solved without significant changes to SIP. The set of the common features is called SIP solution space [1]. 
The primary purpose of SIP is to set up a session between initiator and recipient wherever they are. This is because SIP has the abilities to fork, register and route to locate them.  In addition, SIP can also provide information about communication progress and the final status of session establishment to both parties, which enables spontaneous session initiation and termination.  As such, features and capabilities such as automatic call distribution, instant and spontaneous call conference and networked appliances communications are well within the SIP solution space.
Nevertheless, SIP is not the all-mighty protocol that can solve every problem.  As mentioned before, SIP only provides limited functions. Many network layer services are needed to make SIP work. Those network layer services that are also needed by many other application layer protocols should not be addressed within SIP due to the principle of modularity. 
SIP is only responsible for initiating and terminating a session. It is independent of the session.  This implies that it should not be assumed that the SIP message and session paths are the same.  Thus, SIP is not a resource reservation protocol for session [1].  In addition SIP is not suitable for large amount data transfer, because it is designed to be an ultra-light protocol.  Thirdly because SIP is a very distributed protocol, it is not practical to use SIP as a strong control protocol.

2.2 SIP Architecture Model
 	SIP is an application layer protocol.  This implies that the underlying network type is transparent to SIP.  Any extensions should be able to work through multi-hop network administered by different providers.  And the type of the device supported by SIP should also be transparent to SIP.  Then extensions should not be defined which only function if all devices support the extension.  
SIP is designed to be an efficient, light protocol.  Extensions that require proxies to examine message bodies, to understand new method, or to span data over several INVITE messages, are not preferred.
To maintain the generality and ensure interoperability, extensions are expected to enhance SIP with more general capabilities if applicable.  And extensions should not decrease the interoperability. For example, extensions that use other components instead of request URI as the primary routing key are not appropriate.  For the same reason, extension should be able to work at stateful proxies as well as stateless proxies.

2.3 Issues to be Addressed
In addition to the above general constraints, there are also other issues that should be taken into consideration. Backwards compatibility, for example, is one of the most important issues, since severe interoperability and complexity problems may occur due to no backwards compatibility.  For example, an extension, which presents a new header, is implemented by inserting the new header in a request using an existing method and the mandate usage of Require and/or Proxy-Require headers in the request.  The mandate usage of these headers in turn can result in two scenarios: Requests cannot be serviced unless all the participating parties understand the extension.  This is basically an interoperability failure.  The second scenario: to maintain interoperability, UACs keep both implementations with and without the extension.  However, this will lead to excessive complexity as the number of extensions increases.
Semantics issue also deserves careful examination, for the same reason of interoperability.  That is SIP must clearly specify the behaviors of different parties (UAC, UAS, proxy) in the process of setting up and terminating a session.  Specifying procedures to take care of exceptions is also desired for robustness reason.

2.4 Additional Consideration
Extensions that employ new methods have their own issues to consider, such as how to indicate the existence of the new method, through headers or bodies?  How to handle cancellation since all SIP requests can generally be cancelled?  As for new headers, backwards compatibility is the most important issue, as I will show in detail in the next section.  Whatever the new body type is, the presence of a body is to enhance processing by providing necessary data, instead of packets transfer.

3. Several Extensions

In this section, I will examine several different types of extension against the guidelines discussed in section 1.  By stepping through the processing, I hope to display in detail how the guidelines are applied in different scenarios.

3.1 New Headers: SIP Caller Preferences and Callee Capabilities

Problem Description: when receiving a request a SIP server has a lot of choices with regard to the processing of the request, such as whether to proxy or redirect the request, whether to search the contact list recursively or not, whether to search in parallel or sequentially, etc.  And it has to make a decision.  Currently, such a decision is made based on local policy, which is actually the SIP server’s “opinion”.  But this is not reasonable, because not only the SIP server, but the user agent client (UAC) -- caller and the user to whom the request is directed -- callee are also interested in this call processing.  So we need a mechanism to provide the preferences of the caller and the callee to make the decision reasonable.  By examining existing components in SIP we find out the Contact header defined in SIP has the potential to provide such function, as we will see in the following part.  
According to [7], by including Contact header in the REGISTRAR request, a user agent (UA) can install logic at the server it trusts. For example, it can indicate the mode (proxy or redirect) it prefers the user agent server (UAS) to process the subsequent requests.  In the response, the UAS will indicate in the Contact header the mode used.  Additionally, by including Contact header in a request (e.g. INVITE) a UAS can let the UA know the address it would prefer the subsequent response to be directed to. That is, if the request received at UA includes Contact header, the response will be sent to the address indicated in the Contact header instead of “from” field.  Another reason that Contact header can be used to carry the preference information is that it has already defined the “extension-attribute” field which can be used to define additional information as needed.  Therefore, Contact header inherently has the ability to provide preferences of both the caller and callee.  In another word, this problem well fits into the SIP solution space.  Then basically defining a set of additional parameters to Contact header can solve this problem.  Doing so can bring two direct benefits: more information is available about the participants’ abilities, and format still remains unchanged, which guarantees backwards compatibility.  
There are a number of alternatives for implementing it though:
•	Ideally, caller preferences, callee preferences and administrator preferences all exist at each server, which altogether make the processing decisions [2].  But this is infeasible for two reasons: first, callee cannot install its logic at every server, but only at servers it trusts; second, caller cannot indicate in advance its preferences about every possible callee based on what it assumes about the callee.  
•	The caller and callee each provide abilities and preferences when necessary. The problem arises in the first approach is because the caller and the callee play different roles in a call session, in which the caller takes the active role by initiating the request, while the callee takes the passive role by waiting for the request.  This makes it reasonable to use callee-supplied scripts to indicate the callee abilities, and caller preferences included in the call request [2]. 
•	The approach of feature negotiation is also a possible alternative.  But the proposal described in [8] is far more complicated than fits in the current syntax structure of SIP.

Solution: In [2] callee abilities are provided by including Contact header in REGISTRAR request.  Here the Contact header is enriched to include the new parameters describing the characteristics of callee.  For example, there is a media parameter, which lists the media types supported by the callee.  In the context of SIP, any UA could be a callee.
Three new headers: Accept-Contact, Reject-Contact and Request-disposition, are defined to indicate caller preferences.  And all these new headers are matched against the Contact header at proxies.  So it doesn’t require proxies to understand new headers.    The caller preferences are divided into two categories: the first, the desired server behavior are carried in the Request-disposition header.  These desired behaviors include whether to proxy or redirect the request; whether to search the host in parallel or sequentially.  The second, the desired callees’ characteristics are carried in the Accept-Contact and Reject-Contact headers.  These two new headers contain rules that describe the desired callees.  
Basically the solution works like this:
•	A UA that supports this extension may provide information about their abilities together with location information when registering by including the enriched Contact header in REGISTRAR request.  This information is stored in registration database.  An example of a Contact header describe a PDA used by Silvia is like:
Contact: Yinghua Jia <sip:ysjia@math.uwaterloo.ca>
; language=”english, chinese”
; mobility=”mobile”
; media=”audio, video, text, application/chat”
; feature=”voicemail”
•	A UAC (caller) that wishes to express its preferences for a request includes the three new headers in the request. No additional behavior is required after the request is sent.
•	A UAS will act normally as no preferences contained in request it receives, unless the Accept-Contact header contained in the request has the strength parameter with value being set to “only=true”.  This value means that the request can only be processed by a UA matching the rules.  In another word, the caller wants its preferences to be known by the server.  Then the UAS can process the call with respond to the caller preferences.  It then creates a set of rules obtained from the Accept-Contact header or Reject-Contact header.  Next it matches those rules against the contacts in the contact list, which is constructed from registrations sent by UAs.
•	A UAS will act as either a proxy or redirect server as the Request-disposition header indicates. 
•	UAS acts as a redirect server.  If a rule in Reject-Contact header matches a contact, the address indicated by the contact should not be directed to.  At the same time, that contact is removed from the contact list.  If a rule in Accept-Contact header matches a contact, the UAS combines the q values [7] in the rule and the contact.  And the q value of that contact is updated with the combined q value, in order to incorporate the caller preference. The UAS then redirects the request to the matched contacts in the order of the q values.
•	UAS acts as a proxy. If a rule in Reject-Contact header matches a contact, that address is not proxied.  And that contact is removed from the contact list.  If a rule in Accept-Contact header matches a contact, the UAS combines the q values [7] in the rule and the contact.  And the q value of that contact is updated with the combined q value, in order to incorporate the caller preference.  The UAS then tries to search the matched contacts in the order of the q values.  The way it searches a UA ( in parallel or sequentially) is determined by the server local policy.
From the descriptions of working process above, we can see that this extension can provide information of callee capabilities and caller preferences without changing the normal working process.  This indicates that this extension not only obeys the architecture model SIP assumes, but ensures interoperability without complicating the SIP protocol as well.

3.2 New Methods: INFO

Problem Description: in real life applications, there are cases in which the participants of the session want to change characteristics of the session in the middle. For example, during a text based network conference, the participants want to change the media type to audio for better communication.  With the current available SIP methods, the participants have to end the current conference (session), and start a new audio-based session. To support spontaneously switching between different media types without interrupting the session, new method needs to be defined in SIP in order to carry the conference (session) control message.  Regarding the guidelines mentioned in section 1, the new method should be defined as a general-purpose mechanism if applicable.
Solution: in [4], a new method INFO is defined to provide mid-call signaling information. This new method conforms to the requirements of the existing SIP methods.  That is, in INFO request and response, only call leg -- Call-ID, Cseq, From -- and two other general header fields – Via and To -- are mandatory, all other header fields are optional. This conformity brings several benefits:
•	No additional actions are required at the proxy or the redirect server.  So this new method does not require the proxy or redirect server to change or examine the body to work. In another word, this extension maintains backward compatibility.  
•	There is no specific semantics associated with INFO method.  The semantics are derived from headers and message body that are used in INFO request and response.  In another word, this method is not designed for a specific application. It satisfies the generality requirement.
•	This extension ensures interoperability, because it does not depend on the use of Require or Proxy-Require header, which conforms to the guideline of ensuring interoperability as mentioned in section 1.
•	This extension also conforms to the guideline of maintaining extensibility as mentioned in section 1, because other new extensions can employ this new method just like the way they employ other standard method.
Basically, the details of how INFO request is processed at different parts of SIP is like following:
•	UA processes the INFO request in the same way as BYE request regarding the usage of tags, Route and Record-Route, retransmission and reliability, Cseq incrementing and message formatting [4][7].  As an INFO request may be cancelled, to conform to the processing of standard methods, a new response “487 Request Cancelled” is defined to handle CANCEL for INFO request.  When receiving a CANCEL, the 487 response will be sent out if a finale response for the INFO request has not been received.  Then the UA behaves like never receives the INFO request.
•	Proxy and Redirect Server process the INFO request in the exact same way as BYE request.  The details can be found in [7].
From the description of the extension above, we can see that this extension enhances SIP with the spontaneous ability, and in the same time maintains the flexibility, extensibility and interoperability of SIP. 

3.3 New Body: Device Message Protocol (DMP): An XML based format for wide area

Problem Description: although there are numerous technologies, such as X.10, HAVi, VHN and UPnP, enabling networked appliances (NA) to communicate, none of them supports communication over Internet.  In [9], the use of SIP to support wide-area communication of the NAs is well justified.  For details why this problem falls into SIP solution space please refer to [9].
Solution: to be able to control the NAs from the Internet, a set of extensions need to be made to SIP such as new body type (DMP) and new methods (DO, SUBSCRIBE and NOTIFY).  DMP is used to carry NA communication or control messages via DO or SUBSCRIBE and NOTIFY methods. However, DMP does not depend on the new methods.  It can be carried by any protocol that supports MIME types (application/dmp).  Here we will focus on how DMP is defined and why it is defined this way.  For further information of the new methods: DO, SUBSCRIBE and NOTIFY, please refer to [12] and [13] respectively.
The purpose of communicating with NAs can be generally categorized into the following:
•	Control NA, e.g. to switch on the air conditioner in the lounge;
•	Query, e.g. to determine the temperature in the house;
•	Event Subscribe and Notification e.g. receive notification if the coffee maker is done.  
For detailed requirements for NA communication please refer to [14].  In order to facilitate these actions, DMP is designed to be a data format that conveys information pertaining to control, query and event notification functionality.  And this data format is defined based on XML, which provides flexibility and extensibility to DMP:
•	DMP is independent of functionality associated with a specific device.  Different NA will have varying functionality. For example, a heater has a thermostat setting, whereas a timer has a duration setting. Instead of provide information for specific devices, DMP use XML schema to define only a minimal set of functions that are necessary for communicating with NAs.  This will not only make the device-specific function transparent to DMP, but also allows for introducing future NAs without changing the protocol stack;
•	DMP ensures interoperability between existing technologies for NA communication.  By using XML, DMP can be defined as a super class of the underlying NA communication technologies (Jini, HAVi, X.10, etc).  Through the protocol translator (implemented beyond SIP), the user agents (UA) that understand DMP and act on behalf of the devices can communicate with each other without knowing the underlying technologies;
•	DMP facilitates security management.  The DMP design approach to define limited general information of devices is more appropriate than detailed descriptions for security reasons.
In [5], the format of DMP request and response is described by XML (eXtensible Markup Language) schema.  Here for simplicity I will present them by CFG (Context Free Grammar) like grammar as follows:
DMPRequest := DMPAction
DMPAction:=(Device, (Control | Query | Subscribe )+ )+
Control := Action, Argument*
Query := Variable+
Subscribe := (Variable, Event*, Duration)+
Device := <String>
Action := <String>
Argument := <String>
Variable := <String>
Event := <String>
Duration := <String>
In the above grammar, <String> represents any string, and DMPAction, Device, Control , Query and Subscribe, etc. are all grammar variables.  The grammar for DMP Response is as follows:
DMPResponse := (Device, (ControlResponse | QueryResponse | Notify) +)+
ControlResponse :=(Action, (OutArgument, Value)*, ResultCode*)+
QueryResponse :=(Variable, Value+, ResultCode*)+
Notify := (Variable, Value+, Event+, ResultCode*)+
Device := <String>
Action := <String>
OutArgument := <String>
Value := <String>
ResultCode := <String>
Variable := <String>
Event := <String>

4. Conclusion

 	From the above discussion, we can see that SIP is a simple, flexible and scalable protocol that is easy to extend.  Extensions can be a new header, new method or new body.  However, extensions to SIP should take certain guidelines into consideration to maintain flexibility and ensure interoperability.  However, there are still some issues that need careful considerations. For example, SIP allows a proxy to be stateless, but stateless proxies are unable to retransmit messages and execute certain services. Therefore extensions that depend on some kind of proxy processing should consider how stateless proxy could affect that processing.   

Reference:

[1] J. Rosenberg, H. Schulzrinne, Guidelines for Authors of SIP Extensions, March 5, 2001, Internet Drafts.
[2] J. Rosenberg, H. Schulzrinne, SIP Caller Preferences and Callee Capabilities, June 14, 2001, Internet Drafts.
[3] W. Marshall, K. Ramakrishnan, etc., SIP Extensions for supporting Distributed Call State, February 2001 Internet Drafts.
[4] RFC 2976 The SIP INFO Method
[5] Sumit Khurana, Provin Gurung, Ashutosh Dutta, Device Message Protocol (DMP): An XML based format for Wide Area, November 2000 Internet Drafts
[6] J. Rosenberg, H. Schulzrinne, Reliability of Provisional Responses in SIP, 03/07/2001 Internet Drafts
[7] RFC2543
[8] G. Klyne, A syntax for describing media feature sets, RFC2533, Mar. 1999.
[9] www.argreenhouse.com/iapp
[10] www.w3.org/XML
[11] www.jini.org
[12]S. Tsang et al, SIP Extensions for Communicating with Networked Appliances, Internet Draft, November 2000
[13] J. Rosenberg et al., SIP Extensions for Presence, Internet Draft, June 2000
[14] S. Tsang et al, Requirements for Networked Appliances: Wide-Area Access, Control, and Interworking, Internet Draft, September 2000