Hadriel, Thanks for including 6.3 and 6.4 on sdp media mismatch interop problems. It is very important that they get clearly and loudly communicated to the SIP community. However, there are a couple of sentences I want to discuss. 1. Do not encourage voice-centric call rejections. In 6.4 you say: "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." This is the type of unfortunate assumptions that complicate life for SIP device users who are not voice centric. The device manufacturer will usually not be in a position to judge how the users want to use media in a call. A call may very well be very valuable even if only matching video codecs were found. ( many users I know do not bother if audio gets connected or not, it is the video they want to use, and they want to be able to have calls with mainstream devices with mainstream settings. ) Rather than rejecting calls based on one medium not having matching codecs, I want to suggest that the normal behaviour should be to accept such calls. So, please revert the advice. If there is a desire to require specific media, it should be done under very obvious user control, and e.g. done by using the caller preferences and callee capabilities SIP headers, from RFC 3840 and RFC 3841. 2. Too early to outlaw some features in chapter 7. In chapter 7 you list some features that you think have not been used much after a couple of years existence and therefore should be discontinued. It is a long process to pick up these kinds of features in profiling groups like OMA SIPforum, IMSforum, 3GPP, TISPAN, etc, where selected sets of SIP features are implemented in controlled releases. You cannot know what features may be just on their way to be included in a new release in any such group. I expect for example the Accept-Language parameter to be one that eventually will be used in more advanced service deployment with service behaviour controlled by user profiles. I propose to restrict chapter 7 to warnings for features that have caused problems because of incompatible implementations. I have for example recently seen RFC 3428 SIP Message used for some kind of data collection about the call rather than for user - to- user text messages. That causes confusion in connection with a device that expects a text message to the user in the SIP Message. Such usage can chapter 7 warn for. Thanks Gunnar -----Original Message----- From: i-d-announce-bounces@xxxxxxxx [mailto:i-d-announce-bounces@xxxxxxxx] On Behalf Of Internet-Drafts@xxxxxxxx Sent: Saturday, July 11, 2009 11:00 PM To: i-d-announce@xxxxxxxx Subject: I-D Action:draft-kaplan-sipping-interop-bcp-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Best Current Practices for SIP Interoperability Author(s) : H. Kaplan Filename : draft-kaplan-sipping-interop-bcp-02.txt Pages : 18 Date : 2009-07-11 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-sipping-interop-bcp-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
