SIPPING WG H. Kaplan Internet Draft Acme Packet Intended status: BCP Expires: January 11, 2010 July 11, 2009 Best Current Practices for SIP Interoperability draft-kaplan-sipping-interop-bcp-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 January 11, 2010. Copyright and License Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document identifies several commonly found interoperability issues with SIP, and provides guidance to implementers for how to avoid them. This is an initial set of commonly found problems. Kaplan Expires January 1, 2009 [Page 1] Internet-Draft SIP Interoperability BCP July 2009 Table of Contents 1. Introduction................................................2 2. Applicability...............................................2 3. Warning for Readers.........................................3 4. General Interoperability Issues and Recommendations.........4 4.1. Response code issues...................................4 4.2. SIP field and message lengths..........................5 4.3. SIP and TEL URI formats................................6 4.4. Tel URI's and their parameters in SIP URI's............7 5. Specific SIP Issues.........................................8 5.1. REGISTER response behavior.............................8 5.2. Contact-URI Handling...................................9 5.3. Require header values..................................9 5.4. Call-Forwarding Issues: Diversion vs. History-Info....10 5.5. REFER Call Transfer Issues............................11 6. Specific SIP-related SDP Issues............................11 6.1. Offer-less Invites and Re-Invites.....................11 6.2. Call-hold signaling...................................12 6.3. SDP Media Lines in Answers not matching Offers........13 6.4. Supported Media Incompatibilities.....................14 7. Rare SIP usages............................................15 8. IANA Considerations........................................16 9. Acknowledgments............................................16 10. Informative References.....................................16 Author's Address.................................................18 1. Introduction SIP has grown both in terms of vendor/customer adoption and protocol complexity, with numerous implementations, and differing assumptions, leading to numerous interoperability issues. Unlike some other protocols, it suffers from a lack of either a single dominant vendor, or of a single autocratic standards body. The large number of vendors involved, from different regions of the World, and the differences in needs and wants of the customers of those vendors, has led to a complicated interoperability problem space. This document lists some of the more common interoperability issues encountered in deployments, and provides BCP recommendations for how to avoid or resolve them. 2. Applicability This draft is focused on SIP interoperability issues only. Kaplan Expires - January 2010 [Page 2] SIP Interoperability BCP July 2009 3. Warning for Readers WARNING WARNING WARNING WARNING WARNING WARNING WARNW W W W The following list is an initial strawman. W W It is still under review. W W W W ! DO NOT USE ! W W W W this list for any purpose other than W W discussing what should be in this list. W W It is incomplete, probably wrong and W W it WILL change. W W W W If you think you have a use for this W W list outside this draft, please participate W W in the upcoming discussion and use some W W future version of the list that results. W W Do not use this one. W W W W Specifically, some Recommendations in this W W draft may well exacerbate problems, or lead W W to MORE or WORSE interoperability issues. W W W W ! You have been warned. ! W W W W NO! MNO! W W MNO!! MNNOO! W W MMNO! MNNOO!! W W MNOONNOO! MMMMMMMMMMPPPOII! MNNO!!!! W W !O! NNO! MMMMMMMMMMMMMPPPOOOII!! NO! W W ! MMMMMMMMMMMMMPPPPOOOOIII! ! W W MMMMMMMMMMMMPPPPPOOOOOOII!! W W MMMMMOOOOOOPPPPPPPPOOOOMII! W W MMMMM.. OPPMMP .,OMI! W W MMMM:: o.,OPMP,.o ::I!! W W NNM:::.,,OOPM!P,.::::!! W W MMNNNNNOOOOPMO!!IIPPO!!O! W W MMMMMNNNNOO:!!:!!IPPPPOO! W W MMMMMNNOOMMNNIIIPPPOO!! W W MMMONNMMNNNIIIOO! W W MN MOMMMNNNIIIIIO! OO W W MNO! IiiiiiiiiiiiI OOOO W W NNN MNO! O!!!!!!!!!O OONO NO! W W MNNNNNO! OOOOOOOOOOO MMNNON! W W MNNNNO! PPPPPPPPP MMNON! W W OO! ON! W W W WARNING WARNING WARNING WARNING WARNING WARNING WARNW Kaplan Expires - January 2010 [Page 3] SIP Interoperability BCP July 2009 4. General Interoperability Issues and Recommendations The following sections detail interoperability issues found, and general guidelines and recommendations for implementers to follow to avoid interoperability problems. This is by no means an exhaustive/comprehensive list. 4.1. Response code issues There are numerous reasons a given response code may be sent, and in some cases more than one response code may be appropriate, which has led to differing expectations and behaviors. The need to resolve such conflicts between domains of proxies has led to middle-boxes changing the response codes, which may well exacerbate the problem in the future. In general the interoperability problems that arise are where the upstream proxies or UAC perform automatic re-attempts to alternate paths for certain response codes but not others, and such action cannot be known in advance to the downstream device. For example a 404 Not Found or 480 Temporarily Unavailable are commonly returned by a proxy when it cannot find a route to the target for any number of reasons, and this response causes some upstream nodes to try alternate paths and some not to. Because a 404/480 can be returned for a variety of reasons, some of which should cause a re-route and some not, some vendors send different response codes than 404/480 for those conditions: response codes which are more explicit about whether a re-route is the appropriate action. Another example is 503, which seems to cover everything from temporary overload conditions, administrative-down state, permanent failure, and as a catch-all for anything not easily identified by other codes. Some devices treat this response code as a semi- permanent condition for the next-hop, and avoid sending any subsequent requests to the next-hop for a sustained period of time, which may or may not be the correct action to take. Unfortunately the upstream nodes have no idea which downstream proxy actually generated the 503. Interoperability problems also arise due to SIP response code reason-phrases, which are supposed to be ignored from a response processing perspective. They are useful for logs and to show the user, but only the response code itself should be used for response processing. Some vendors use unique reason-phrase string values for different events of the same code number, to aid in troubleshooting, while other vendors need the reason-phrase to be the default examples from the RFC's. Kaplan Expires - January 2010 [Page 4] SIP Interoperability BCP July 2009 See "REGISTER response behavior" section for related problems. Recommended Behavior: [Can we recommend any specific behavior about response codes here? It's not clear we can.] UA's, B2BUA's, and Proxies MUST ignore the received SIP response reason-phrase from a response processing perspective. The reason- phrase is an opaque string value useful for logging, troubleshooting, and displaying to human users. The example reason- phrases in the RFC's are only examples, and are non-normative. Many SIP nodes generate unique reason-phrase string values to aid in troubleshooting, which is a significant value for SIP operators and users. 4.2. SIP field and message lengths While the RFCs do not define any maximum lengths for SIP header fields (values, parameters, etc.) or SIP messages, the reality of computing technology is such that vendors often do impose maximum lengths for received fields and messages. Whether it's due to security concerns, product architecture, logging constraints, etc., the fact is there are many systems which cannot or will not handle fields as large as other systems can generate. Although [RFC3261] does define some specific response codes (413/414/513) for this case, it does not fix the underlying interoperability issue. Devices cannot simply stop sending larger fields based on a SIP response code. This issue has been appearing more frequently lately, with the use of embedded cookies in URIs and parameter growth. Recommended Behavior: It is RECOMMENDED that a UA, B2BUA or Proxy not generate any SIP field longer than 256 bytes. This includes any header parameters, URI, and header value. It is RECOMMENDED that a Proxy, B2BUA, and UA be able to process SIP fields of at least 1024 bytes in length. It is RECOMMENDED that a UA or B2BUA not generate any SIP message size larger than 64,000 bytes. Note this is not 65,535, in order to accommodate message growth due to header insertion in Proxies. It is RECOMMENDED that a Proxy, B2BUA, or UA be able to process SIP messages of at least 65,535 bytes. Kaplan Expires - January 2010 [Page 5] SIP Interoperability BCP July 2009 It is RECOMMENDED that a UA or B2BUA not generate any SIP message bodies larger than 32,768 bytes. It is RECOMMENDED that a B2BUA or UA be able to process SIP message bodies of at least 64,000 bytes in length. 4.3. SIP and TEL URI formats Despite all RFC wording to the contrary, the SIP URI format has seen widespread use as essentially the semantic equivalent of the TEL URI, albeit with different syntax. Many provider systems treat sip:16035551212@example.net as logically equivalent to tel:+16035551212, even though the former has local scope to example.net only, and the latter has global scope. Part of the reason for this, I believe, is that originating UA's have no real way of knowing when a URI should be one or the other - the user pressed digit buttons and hit "send", and all the UAC can do is send the request to sip:[digits]@[local-domain]. It doesn't know the numbers pressed were global in scope, or even E.164 numbers. Only the routing proxies know this, and even then they only know the numbers they're each responsible for. Thus we see the domain portion of SIP URIs getting replaced by middle-boxes at provider boundaries, if the username portion looks like an E.164 number. Furthermore, many systems have either been designed or provisioned to handle only one scheme type: SIP URIs. This has led to cases where requests are rejected unless the appropriate URI scheme is used, and frequently that single common scheme needs to be used in more than just the request-URI (e.g., To and From URI's as well). This wholesale replacement of schemes and domain names in URIs leads to interop issues when the same URIs are expected to be used for end-to-end purposes, in headers or XML bodies the middle-boxes do not or cannot change. The most recent example is [RFC4474] sip- identity. Recommended Behavior: It is RECOMMENDED that a UA or B2BUA only use SIP URIs for any SIP header field values which need a URI; for example the request URI, To, From, Contact, P-Asserted-Identity, P-Called-Party-ID, P- Associated-URI, History-Info, and so on. It is RECOMMENDED that a UA, B2BUA, or Proxy be able to process/support TEL and SIPS URI's per their associated RFC's. It is RECOMMENDED that SIP domains not allocate SIP URI AoR usernames which match the following regular expression syntax, unless they are actually E.164 assigned numbers for them: ^+?[0-9]{11,16}$ Kaplan Expires - January 2010 [Page 6] SIP Interoperability BCP July 2009 Note this is after removing visual-separators, and any user parameters. Providing AoR usernames which match E.164 syntax but which are not truly E.164 assigned numbers will lead to significant interoperability issues and user confusion, if such domain interconnect with other SIP domains. One SIP Service Provider is known to currently use such usernames. It is RECOMMENDED, that the SIP Working Group address the fundamental issue of E.164 or telephone number scope in SIP URI's. The TEL URI also has specific syntactic and usage issues beyond simply lack of broad industry support, which may be a reason for not supporting it. 4.4. Tel URI's and their parameters in SIP URI's Although the Tel URI has not seen much usage itself using the "tel" scheme, it is quite common to see SIP URI's containing Tel-URI parameters - i.e., Tel URI's in the form of SIP URI's. There are many URI parameters defined for Tel-URI that are popular, and thus frequently appear in SIP URI's, for example in the request-URI. The most common interoperability problem in this area is the placement of the Tel URI parameters, for example the "tgrp" and "trunk-context" parameters from [RFC4904], and the "rn", "npdi", and "cic" parameters from [RFC4694]. RFC 3261 section 19.1.6 is very clear that the entire telephone-subscriber portion, including parameters, is placed in the userinfo portion of a SIP URI. Thus the Tel-URI parameters become user parameters for SIP, not SIP URI parameters. An example, therefore, of a SIP URI containing some of the aforementioned Tel-URI parameters would be: sip:+12125551212;npdi;tgrp=foo;trunk-context=example.com@example.net Another common interoperability problem concerns the visual- separators. The Tel-URI format allows for visual-separators such as dashes and parenthesis to appear in Tel-URI's, and thus in SIP URI usernames, even though they are not truly part of the username from a processing perspective. The URI username "+12125551212" is semantically equivalent to "+1(212)555-1212". For humans and IETF document examples, this provides a nice visual representation of telephone numbers. However several systems cannot accept such usernames, or do not process/route them in the same way they do ones without the visual-separators. [And in this author's opinion, the SIP protocol should not have allowed a human-presentation-layer format to be incorporated into a machine-session-layer URI on the wire!] Kaplan Expires - January 2010 [Page 7] SIP Interoperability BCP July 2009 Recommended Behavior: UA's, B2BUA's, or Proxies which convert Tel URI's to SIP URI's, or insert Tel URI parameters into SIP URI's, such as those based on [RFC4904] or [RFC4694], MUST insert them as SIP URI userinfo parameters, not URI parameters. It is RECOMMENDED that UA's, B2BUA's, or Proxies which process received SIP URI's and support Tel URI parameters, such as those based on [RFC4904] or [RFC4694], be able to recognize and process such parameters regardless of whether they are SIP URI userinfo parameters or just URI parameters. It is RECOMMENDED that UA's, B2BUA's, or Proxies which generate SIP or Tel URI's containing telephone numbers do not include visual- separators in their usernames. UA's, B2BUA's, or Proxies MUST be able to process SIP or Tel URI usernames containing visual-separators, in the same manner and with the same results as they do ones without visual-separators. 5. Specific SIP Issues 5.1. REGISTER response behavior Another form of the interop problems that arise from responses is the behavior of UA's with regard to Registration and Subscribe response handling. For example, only a minority of UA's properly support 3xx redirects for REGISTER, even though it would be a useful mechanism for load-balancing. For REGISTER requests specifically, it would be beneficial if there was explicit documentation of what actions should be performed by the UAC. To reinforce this point, consider that UA's perform Registrations and Subscriptions in a fairly automatic fashion with little user interaction, and so the way in which they treat specific response codes can have dramatic consequences. For example, it is not well- defined what a UA should do when its REGISTER is rejected with a 404, or even 503, and hardly any UA's honor the Retry-After header. A very few UA's will give up altogether and wait for user input; some UA's will wait a few minutes and try again, indefinitely; some will re-attempt their Registration almost immediately, even faster, and never give up. This creates numerous problems in large network deployments, and has led SBC vendors to implement various protection schemes - from dynamic hardware ACLs, to even sending a 200 ok just to shut the UA up. [What can we say here that UA's will actually do?] Kaplan Expires - January 2010 [Page 8] SIP Interoperability BCP July 2009 5.2. Contact-URI Handling Contact URI's represent a significant role in SIP routing behavior. Record-Route URI's form a portion of the route set for in-dialog requests, but the Contact-URI is the final route hop to reach the UA, and many case a B2BUA. They also provide reachability information through REGISTER requests, along with the Path header fields. The common interoperability problems found with Contact-URI handling are around "unexpected" usernames, username and URI parameters, and transport information. In particular, some Registrars/Proxy-Registrars expect the Contact URI username for REGISTER requests to match the AoR username. This behavior is generally unsafe, because it makes guessing a UA's Contact-URI relatively easy. Conversely, some UA's constantly generate random Contact-URI's for every Registration refresh and out-of-dialog request they generate, in the misguided belief that it is more secure to do so. Interoperability issues have also been found with Contact URI username and URI parameters, whereby the parameters are not reflected/copied into the request-URI for upstream requests. This is incorrect behavior (i.e., a "bug") - the entire Contact-URI MUST be reflected/copied, per RFC 3261. Lastly, interoperability issues have been found with upstream request routing using Contact-URI's for transport information. This is particularly true for TCP-based scenarios, where in some cases a UA is not actually reachable at its indicated TCP server port, due to Firewalls or NATs. Some UA's will use their TCP client socket information in the URI, in the hopes of making upstream requests use the same TCP or TLS connection. 5.3. Require header values SIP offers a means of indicating extension use, in the Require, Proxy-Require, and Supported header fields. Some SDO's and vendors make assumptions about the capabilities of other UA's, and do not take user perception or expectations into account. Inserting an option tag into a Require or Proxy-Require header literally implies "I don't want this request to succeed, unless every possible recipient of this in the Universe supports this extension". For example, the 100rel option tag for supporting PRACK is sometimes inserted in the Require header of an INVITE request. This is fundamentally unsound in actual usage. The support for PRACK is not universal, by any measure, and inserting this tag in the Require header leads to failed calls. No user or operator wants a failed Kaplan Expires - January 2010 [Page 9] SIP Interoperability BCP July 2009 call, unless it is literally impossible to succeed. Such is not the case with PRACK. There is no condition under which not getting a provisional response should ever lead to call failure, because in fact there may be no provisional responses ever sent. The Require header field makes much more sense for requests which do not create sessions, such as REGISTER or OPTIONS; but again only if the client (and ultimately the human user) truly wants the request to fail if the other end cannot support the extension. Implementors should take note that requiring an extension may mean many failure cases, and so are advised to not implement things in such a way that they are actually required. 5.4. Call-Forwarding Issues: Diversion vs. History-Info To support specific features, billing models, and user-expectations, SIP requests which are routed to a different user than the originally intended target generally need some form of indication as to the original target of the request. An early form of indicating the original called party(ies), and the number of redirections, was documented in the Individual-Draft [draft-diversion], which used a multi-instance SIP header field named "Diversion" to record the redirection information. Although this draft expired and was never published as an RFC, and is therefore a proprietary header, it has gained fairly wide-spread use. Meanwhile, the official IETF RFC for indicating such information is [RFC4244] with the History-Info SIP header field, which is also popular. Unfortunately, the two mechanisms are not directly interoperable - either the receiver of the SIP request has to support both, or a middlebox must convert one form to the other. In fact, the only reliable means of indicating redirection information is to use one mechanism or the other but not both, because using both leads to cases where a redirecting Proxy only supported one mechanism, and thus its redirection information is only in one of the mechanism header fields, and the two mechanisms record different information. Therefore, while a UAS/Proxy can support both mechanisms, it actually needs to prefer one over the other whenever it receives both, and remove the one it does not use to avoid ambiguity downstream. In other words, within any given domain of SIP devices, only one of the two mechanisms should be used. To compound the issue, the semantics of the two mechanisms are not identical; Diversion was a simple equivalent to the PSTN ISUP Redirection parameter model, while History-Info is a richer, more generally applicable mechanism for all/any SIP routing mechanics. Because of this difference, it is not always clear which History- Kaplan Expires - January 2010 [Page 10] SIP Interoperability BCP July 2009 Info header field values should really be encoded in Diversion header field information, because History-Info records routing events which are not actually redirections from a Diversion (or PSTN) perspective. Work is underway in the IETF to address this, by providing specific semantic indications in the History-Info header field for the cause of the header field value's creation. 5.5. REFER Call Transfer Issues The call transfer mechanisms provided through the REFER method has been found to cause numerous interoperability issues. Some of the issues are due to specific assumptions on the part of vendor implementations; others are due to specific deployment models. For example, some implementations and deployment models do not support out-of-dialog REFER's. Another example is some implementations do not support the Replaces mechanism in [RFC3891], which is a pre- requisite for some call transfer models. It is not clear what more can be said/recommended regarding REFER which is not already documented somewhere in the plethora of RFC's on the subject. [the fact there are a "plethora" of RFC's on the subject may be part of the problem?] [Note: the various REFER models are something we should focus on testing at Sipit's] 6. Specific SIP-related SDP Issues 6.1. Offer-less Invites and Re-Invites Although this is clearly a device implementation issue (i.e., a "bug"), we have seen numerous devices from different vendors have trouble handling Invites or re-Invites that do not contain SDP. For initial Invites without SDP, often the root cause for failure is that specific request routing or admission decision logic of intermediate devices depends on the SDP; for example devices which route calls based on codec, or bandwidth allocation devices, or 3PCC transcoding devices which themselves send out offer-less Invites but didn't expect to receive such. (Apparently they never considered that a call could cross two such systems!) For re-Invites, the delayed SDP offer model is performed for very specific use cases which are common, but were simply not envisioned by the developers of the UA's. Recommended Behavior: Kaplan Expires - January 2010 [Page 11] SIP Interoperability BCP July 2009 It is RECOMMENDED that a UAC provide the SDP offer with its INVITE requests. A UAS or B2BUA MUST support receiving an INVITE without an SDP offer. 6.2. Call-hold signaling The legacy mechanism defined in [RFC2543] for call-hold by setting the SDP connection address to 0.0.0.0 is unfortunately far from obsolete in usage, despite the superior direction attribute (a=inactive/recvonly/sendonly) concept of [RFC3264]. To increase interoperability, some devices send both types in the re-Invite, which defeats the purpose of using a direction attribute (e.g., keeping RTCP flowing). Other vendors send the direction attribute first, and if the SDP answer does not mirror it they use the legacy approach, which leads to extraneous signaling overhead. An IETF recommendation/BCP for this is probably warranted. In hindsight [RFC3264] should have been backwards compatible (e.g., still using the 0.0.0.0 syntax with some new attribute for on-hold connection address, which would be ignored by legacy devices but used by newer ones). [note: I recognize this is SDP not SIP, but it's a big deal and was caused by rfc2543] A note for Implementors: this does not imply an address of 0.0.0.0 in the media line is inappropriate in all circumstances; quite the contrary, it is used in "black hole" cases, which are different from "on-hold" cases. A "black hole" case is one where the device sending the SDP literally does not want the far end to send RTP or RTCP anywhere. This is sometimes needed in 3PCC call scenarios, for example. An "on-hold" scenario is typically different: the media session was already established, and is only being temporarily disabled such that the party doing the on-hold does not wish to receive media from the far-end, but still wants to receive RTCP. Recommended Behavior: It is RECOMMENDED that a UA include only a "sendonly", or "inactive", direction attribute in an SDP offer for on-hold, and not set the address to 0.0.0.0. If the SDP answer does not have a direction attribute (i.e., of recvonly or inactive), then the offerer MAY wish to send another offer with a connection address of 0.0.0.0, if it is vital that no RTP be sent to the offering party. It is RECOMMENDED that a UA support both the direction attribute of (a=inactive/recvonly) and the 0.0.0.0 connection address semantic for on-hold, when processing received SDP offers, such that the existence of *either* one, or both, triggers on-hold behavior. Kaplan Expires - January 2010 [Page 12] SIP Interoperability BCP July 2009 If a UA receives an SDP offer with both attributes, it is RECOMMENDED that the UA use only the direction attribute in its SDP answer, and leave the connection address line set to whatever IP Address it wishes to receive RTCP on. UA's MUST support the direction attribute of "a=sendrecv" being an implicit default attribute, such that if another direction attribute does not exist in the SDP, sendrecv is implied. Note that a connection line of 0.0.0.0 means there is no remote address to send RTP/RTCP to, and thus implying "sendrecv" does not conflict with stopping RTP. It is RECOMMENDED that UA's include an "a=sendrecv" attribute in SDP, instead of relying on implicit behavior. [Note: should we include the sip.rendering media feature parameter? I fear that will cause even more interop problems] 6.3. SDP Media Lines in Answers not matching Offers A frequent interoperability problem arises when an SDP offer contains multiple "m=" media lines, but the SDP answer does not contain the same number of lines. According to [RFC3264]: For each "m=" line in the offer, there MUST be a corresponding "m=" line in the answer. The answer MUST contain exactly the same number of "m=" lines as the offer. This allows for streams to be matched up based on their order. This implies that if the offer contained zero "m=" lines, the answer MUST contain zero "m=" lines. Although the text is unambiguous, in the wild many implementations have been found which do not adhere to this policy. In general, it appears that the device receiving the SDP offer was designed to only look for and process the first "m=" media line, and ignore the rest; or in some cases only processes audio type media lines. Since standard-abiding devices receiving such an SDP answer detect this as a protocol failure, typically, they proceed to terminate the session request, leading to poor user experience. Furthermore, sending an SDP offer without any media lines, though technically legal, is extremely rare and is bound to cause interoperability issues. It is difficult to envision why such an SDP offer would be sent, since the SDP offerer presumably knows what type of media it wishes to offer. Recommended Behavior: A UA MUST include an "m=" media line in the SDP answer for every media line in the offer. If the answerer does not wish to use one Kaplan Expires - January 2010 [Page 13] SIP Interoperability BCP July 2009 or more of the offered medias, it MUST set the port number in the rejected media lines to zero ("0"), as per [RFC3264]. It is RECOMMENDED that a UA which receives an SDP answer which does not contain the same number of media lines as the offer, assume that the answered media lines align linearly with the offer, and that all media lines after the number in the answer are implicitly rejected, as if the answerer had set their port number to zero. It is RECOMMENDED that a UA which wishes to offer audio media streams along with other media stream types, list the audio type media lines first, before media lines for other media types. It is RECOMMENDED that a UA never send an SDP offer without media lines. [Note: should we say what it should do if such a need arises? There are multiple options] 6.4. Supported Media Incompatibilities In practice, a significant number of SIP devices only support specific media types, codecs, and transports. The overwhelming majority of such devices only support G.711 audio media, with RTP/AVP transport over UDP. This is not only limited to PSTN-based gateways and home IAD's, but even those device types represent a large population of SIP devices. Unfortunately, it is not uncommon for two SIP devices attempting to communicate to have no audio or video codecs in common. Even G.711 (of either companding mode) is not guaranteed to be supported by the far-end device, although it is by far the most common denominator for audio codecs. In scenarios where both UA's have no media in common, the SDP offer is typically refused, but with varying response codes or behaviors. While for some people it may not seem important how an SDP offer is refused, it is vitally important to others: for either troubleshooting such cases, or for providing middlebox "aid" in such cases, for example by invoking transcoding servers only when initial SDP offers fail. Unfortunately, it is also quite difficult to provide specific guidance on this issue, since the correct behavior is sometimes application-specific. For example, it is not uncommon that audio+video offers are (and should be) accepted by audio-only answerers, and they simply set the "m=" media line(s) of the video type to port value zero in the SDP response. But it is also not uncommon that audio+video offers are (and should be) rejected if the device receiving the offer supports both audio and video but just not the specific audio codecs in the offer - even though it does support the video media types offered. It is a local decision as to what the appropriate action to take is for such cases. Kaplan Expires - January 2010 [Page 14] SIP Interoperability BCP July 2009 What can be recommended is what is in fact documented in [RFC3261] and industry practice on such matters, with regard to response codes to use, should the answerer decide to reject the offer. While it is fairly clear how SIP requests, such as INVITEs, with unacceptable SDP offers should be handled, it is not as clear how SIP responses with unacceptable SDP offers should be handled. This issue is documented further in [draft-offeranswer-usage]. Recommended Behavior: A UA which receives a SIP request with an SDP offer it does not wish to accept at all, due to media incompatibilities, MUST respond with a 488 response code. Note that for re-INVITE's and UPDATE's sent in an established dialog, this does not terminate the dialog; it simply rejects the new offer, and the session continues using the previously accepted offer. A UA which receives a SIP response with an SDP offer it does not wish to accept at all, due to media incompatibilities, MUST continue to acknowledge the response with an ACK (or PRACK as appropriate), with matching SDP and every "m=" media line from the offer set to port value zero. The rejecting UA may then either end the session (e.g., with a BYE), or attempt a new round of negotiation by sending its own offer in a new in-dialog request, as documented in [draft- offeranswer-usage]. It is RECOMMENDED that a UA which sends a SIP request such as BYE, to end the session for a case where a SIP response had an unacceptable SDP offer, include a Reason header field in the BYE with the SIP 488 cause code in it, per [RFC3326]. [Note: one trick some vendors use is to pretend the unacceptable response was not received and send a CANCEL - should we recommend that?] 7. Rare SIP usages Although they have not led to interoperability problems yet, there are some incredibly rare SIP usages that will probably lead to interoperability problems if anyone actually tries to use them. In this author's opinion they should probably be deprecated or moved into an experimental RFC if they were published more than 2 years ago without success. In the mean-time, the ones which are 2 years old or older and have seen little use are noted here: . S/MIME in [RFC3261] . S/MIME AES [RFC3853] Kaplan Expires - January 2010 [Page 15] SIP Interoperability BCP July 2009 . The SIPS URI scheme (sips:...) in [RFC3261] . SDP ANAT Parameters [RFC4091] - this one *is* used by IPv6 nodes, but has issues and is rarely supported by IPv4 nodes, which basically defeats using it to begin with . AIB Authenticated Identity Body [RFC3893] . The following SIP Header fields in [RFC3261]: Accept-Language, Call-Info, Content-Language, Error-Info, In- Reply-To, Mime-Version, Organization, Priority, Reply-To [NOTE: Obviously the above list is the author's opinion for a starting volley. It may well be some of these are wildly popular, unbeknownst to this author, but we will never find out unless we start with some list and find differently. So please don't get upset if your favorite extension is in this list - simply email on the SIP mailing list that you've seen it really used in an interoperable fashion.] 8. IANA Considerations This document makes no request of IANA. 9. Acknowledgments Thanks to Gunnar Hellstrom, Paul Kyzivat, Andrew Hutton, Maureen Stillman, Markus Isomaki, and Simo Veikkolainen for additional issues/cases and recommendations to include; Robert Sparks for the Warning Label text idea, and Marco Lamberto's sunnyspot.org for the skull-n-crossbones ascii art. 10. Informative References [RFC2543] Rosenberg, J., Schulzrinne, H., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [RFC2833] Schulzrinne, H., Taylor, T., "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J., Schulzrinne, H., "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. Kaplan Expires - January 2010 [Page 16] SIP Interoperability BCP July 2009 [RFC3326] Schulzrinne, H., Oran, D., Camarillo, G., "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002. [RFC3608] Willis, D., Hoeneisen, B., "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003. [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004. [RFC3891] Mahy, R., Biggs, B., Dean, R., "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [RFC4091] Camarillo, G., Rosenberg, J., "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005. [RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005. [RFC4474] Peterson, J., Jennings, C., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [RFC4694] Yu, J., "Number Portability Parameters for the "tel" URI", RFC 4694, October 2006. [RFC4730] Burger, E., Dolly, M., "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006. [RFC4904] Gurbani, V., Jennings, C., "Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)", RFC 4904, June 2007. [draft-diversion] Levy, S., Yang, J.R., "Diversion Indication in SIP", draft-levy-sip-diversion-08.txt, August 2004. Kaplan Expires - January 2010 [Page 17] SIP Interoperability BCP July 2009 [draft-offeranswer-usage] Sawada, T., Kyzivat, P., "SIP (Session Initiation Protocol) Usage of the Offer/Answer Model", draft-ietf-sipping-sip-offeranswer-10, January 2009. Author's Address Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: hkaplan@acmepacket.com Kaplan Expires - January 2010 [Page 18]