Recent SIP Interoperability Experiences at SIPit
draft-johnston-sf-sip-interop-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 30, 2008.

Copyright Notice

Copyright © The IETF Trust (2007).

Abstract

This memo describes several recent experiences of SIP interoperability. They show common issues of "too many options" for feature implementation and feature interaction problems. They also highlight a less common specification error as well. The discovery of these interoperability issues at SIPit shows the value of this type of interoperability testing.

Table of Contents

1.  Overview
2.  Results
    2.1.  Simple Feature Failure - Call Hold
    2.2.  Feature Interaction Failure - Transfer and Line Appearance Number
    2.3.  Specification Error Failure - G.722 Codec Sampling Rate
3.  Conclusions
4.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Overview

This document discusses recent interoperability experiences with the Session Initiation Protocol SIP [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) from a User Agent perspective.

2.  Results

During the SIPit testing, most of the errors uncovered were not strictly SIP, but related to Offer/Answer and SDP failures. A few of these errors are discussed in the following section as they illustrate some common and not so common areas of interoperability failures.

2.1.  Simple Feature Failure - Call Hold

While call hold is one of the simplest features which has been extensively discussed and documented, we still found an issue. An implementation did not handle cases of the use of the SDP [2] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) attribute "a=inactive" properly. The implementation sent a "a=sendonly" and expected to receive this attribute. In another variation on this, an implementation used a session level (above the media "m=" lines) "a=inactive" attribute instead of the more common media level (below the "m=" line). These interoperability issues were caused by having a number of alternative ways to implement a feature, and failing to implement all of them. It is interesting that even the simplest feature can still cause interoperability issues.

These types of failure could be prevented by simple rigorous testing of SDP offers and answers per the specifications covering all possibilities.

2.2.  Feature Interaction Failure - Transfer and Line Appearance Number

This failure was due to a feature interaction problem, i.e. two features that work perfectly on their own but fail when used together. The two features were call transfer [3] (Sparks, R., “Session Initiation Protocol Call Control - Transfer,” July 2007.) and line appearance number [4] (Johnston, A., “Requirements and Implementation Options for the Multiple Line Appearance Feature using the Session Initiation Protocol (SIP),” February 2007.). Line appearance number involves the assignment of an "appearance number" to a particular call. In this failure, a call was initially established between A and B. A then transferred B to C, resulting in a call between B and C with no call between A and B. In particular, this version of transfer is known as "blind transfer" in which A "hangs up" after initiating the transfer, before the transfer has either completed or failed. In this case, the actual transfer worked as expected - however, while the initial call between A and B was on "line 1" on B, the resulting call between B and C was shown as "line 2" instead of the expected "line 1" (Recall, when doing transfers, all resources associated with the old call should be transferred to the new call, including appearance numbers.) Upon investigation, it was discovered why this was occurring. Although A was initiating the blind transfer, it was not sending the BYE immediately after sending the REFER. After the receipt of the first NOTIFY, A was sending the BYE. As a result, when B was sending out the new INVITE, "line 1" was still in use to A, resulting in "line 2" being selected by B. Other SIP phones which sent the BYE immediately after the REFER did not result in this occurring.

While this failure is not a critical failure, it was an unexpected user interface result. It is a feature interoperability problem since it only shows up when these two features are used together, and even then only for certain types of blind transfer.

These types of feature interaction problems are very difficult to discover without performing full regression testing (a matrix of each feature against each other feature) covering all known variants of each feature - quite a difficult task.

Also note that the multiple line appearance feature [5] (Kumar, A., “Implementing Multiple Line Appearances using the Session Initiation Protocol (SIP),” March 2007.) currently does not have a standard in SIP, although there are several proprietary implementations. Hopefully this important feature will be standardized by the SIP Working Group in the future.

2.3.  Specification Error Failure - G.722 Codec Sampling Rate

This failure was due to a mistake in a specification, the RTP Audio Visual Profiles (AVP) specification RFC 3551[6] (Schulzrinne, H. and S. Casner, “RTP Profile for Audio and Video Conferences with Minimal Control,” July 2003.). Section 4.5.2 says this:

  "Even though the actual sampling rate for G.722 audio is 16,000 Hz,
   the RTP clock rate for the G722 payload format is 8,000 Hz because
   that value was erroneously assigned in RFC 1890 and must remain
   unchanged for backward compatibility.  The octet rate or sample-pair
   rate is 8,000 Hz."

One implementation of G.722 used the standard (but nominally incorrect) value of 8000 but the other implementation used the value of 16000, causing a failure.

This is a somewhat rare example of an error in a specification causing an actual interoperability failure. As a result of the initial mistake, the value of 8000 will need to be continually used. This raises the question of whether there should be a future migration to the correct value of 16000 with the idea of eventually deprecating the value of 8000 for this codec.

3.  Conclusions

The interoperability failure examples described here show some common and not-so-common failures. While some of these failures are difficult to find and correct, others are not. More interoperability problems were encountered with SDP and offer/answer exchanges than with SIP itself. The discovery of these issues shows the value of SIPit participation.

4. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).