Network Working Group J. Elwell Internet-Draft Siemens Enterprise Communications Intended status: Informational GmbH & Co KG Expires: May 30, 2008 T. Stach Siemens Enterprise Communications GmbH & Co KG /iSEC November 27, 2007 Common interoperability problems with SIP draft-elwell-interop-workshop-00.txt 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 (C) The IETF Trust (2007). Abstract This is a position paper as input to the SIP Forum Workshop on SIP Interoperability. It lists some of the most common sources of interoperability problems from the authors' perspective. Elwell & Stach Expires May 30, 2008 [Page 1] Internet-Draft Interop Workshop November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Common interoperability problems . . . . . . . . . . . . . . . 3 2.1. Call hold . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. re-INVITE without SDP . . . . . . . . . . . . . . . . . . . 3 2.3. Dynamic payload types for DTMF . . . . . . . . . . . . . . 3 2.4. Video . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.5. Unrecognised SDP extensions . . . . . . . . . . . . . . . . 4 2.6. Non-support of extensions . . . . . . . . . . . . . . . . . 4 2.7. Issues with the SDP ptime attribute . . . . . . . . . . . . 4 2.8. Interpretation of mid-call P-Asserted-Identity . . . . . . 5 2.9. Codec changes . . . . . . . . . . . . . . . . . . . . . . . 5 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Elwell & Stach Expires May 30, 2008 [Page 2] Internet-Draft Interop Workshop November 2007 1. Introduction This is a position paper as input to the SIP Forum Workshop on SIP Interoperability. It lists some of the most common sources of interoperability problems from the author's perspective. 2. Common interoperability problems Whilst interoperability problems are quite common, a substantial proportion of problems seem to be associated with a relatively small set of SIP/SDP capabilities. By focusing on trying to correct these through better specifications and publicity, significant improvements should be possible. 2.1. Call hold A recurring set of problems is to do with call hold. Setting aside issues with implementations that still use the RFC 2543 mechanism, the RFC 3264 mechanism is very badly understood by the community. Problems arise, for example, with: o mishandling of a received a=inactive when the holding party does not wish to send media during hold; o wrong information in an SDP offer sent by a UA that is already being held by the other UA; o the absence of a direction attribute is not always interpreted as being equivalent to a=sendrcv; o responding a=sendrcv to a=sendonly or a=inactive. Fortunately these issues are being addressed by the sipping- offeranswer draft, but how long will it take for the message to spread throughout the community and for implementations to be corrected? 2.2. re-INVITE without SDP Problems are sometimes encountered when a UA receives a re-INVITE request without SDP. The expected action is to return a 200 OK containing an SDP offer, but this does not always occur (e.g., a different response code). When a 200 response with SDP offer is returned, this does not necessarily reflect the correct hold status from the UA. 2.3. Dynamic payload types for DTMF Problems have been encountered with different interpretations of the range of dynamic payload types available, in particular Elwell & Stach Expires May 30, 2008 [Page 3] Internet-Draft Interop Workshop November 2007 implementations imposing a lower upper limit than expected or not accepting a value at the lower end (e.g., 96). 2.4. Video There are several issues relating to the use of video. When an offer contains multiple m-lines, the answer does not always reproduce those m-lines. For example, sending an offer with audio and video might result in an answer with audio only (rather than including m-line for video with port 0). This can occur whether audio came before or after video in the offer. Other problems relate to one-way video (use of a=sendonly / a=recvonly), and different specifications for video control. 2.5. Unrecognised SDP extensions Unrecognised SDP extensions are often handled badly, e.g., interpreted as something known rather than as something unknown. One example is RTP/SAVP transport, which is sometimes treated as RTP/AVP. The one area of SDP where implementations seem reasonably tolerant of extensions is attributes, where unrecognized a-lines are generally ignored. Related to this is the fact that there is currently no standardised way of achieving best effort SRTP, i.e., negotiating between RTP and SRTP. This is being addressed by the capability negotiation work in MMUSIC, but in the meantime there are several different non-standard approaches in the field. 2.6. Non-support of extensions ~Whilst mechanisms such as the Supported and Allow header fields allow a UA to determine what extensions are supported, lack of support for a common extension can sometimes cause problems. A prime example is REFER, which is important for common features such as call transfer. If known not to be supported, an implementation can take other approaches (based on 3rd party call control, 3PCC), but they too suffer from problems (e.g., the re-INVITE issue above). 2.7. Issues with the SDP ptime attribute This is not always handled correctly. Some implementations expect the received ptime value to apply also to the packet sizes they receive, not just the packet sizes they send, and have problems with received packet sizes that differ from the received ptime value (or differing from the default if ptime is not received). Some reject the whole offer if ptime is unacceptable (e.g., ptime indicates 40ms and G.723.1, with a frame size of 30ms, is asked for). Elwell & Stach Expires May 30, 2008 [Page 4] Internet-Draft Interop Workshop November 2007 2.8. Interpretation of mid-call P-Asserted-Identity A revised P-Asserted-Identity value in a mid-dialog request does not necessarily cause displays to be updated. Such a situation can arise during 3PCC operations, e.g., to achieve call transfer. The absence of a P-Asserted-Identity header field in a mid-dialog request is not specified and could be interpreted as meaning that the remote party identity has not changed or that it is no longer available (e.g., the identity of the transferred-to party is not available). 2.9. Codec changes The use of re-INVITE to change codecs (e.g., following actions such as 3PCC transfer) does not always result in the desired action. 3. Summary As will be seen from the above list, many of the problems are to do with SDP or the offer-answer model, rather than SIP itself. Also some of the problems are associated with 3PCC, which, whilst never the aim of SIP originally, is widespread in the field through lack of other standardised mechanisms. There are also many problems due to different implementations choosing different RFCs (or drafts) to implement the same feature, or using different versions (e.g., old drafts). Authors' Addresses John Elwell Siemens Enterprise Communications GmbH & Co KG Hofmannstrasse 51 D-81379 Munich Germany Phone: +44 115 943 4989 Email: john.elwell@siemens.com Elwell & Stach Expires May 30, 2008 [Page 5] Internet-Draft Interop Workshop November 2007 Thomas Stach Siemens Enterprise Communications GmbH & Co KG /iSEC Rampengasse 3 1190 Wien Austria Phone: +43 51707 47364 Email: thomas.stach@siemens.com Elwell & Stach Expires May 30, 2008 [Page 6] Internet-Draft Interop Workshop November 2007 Full Copyright Statement Copyright (C) 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). Elwell & Stach Expires May 30, 2008 [Page 7]