Hi, I agree on bullets 1) and 2). Regarding bullets 3) and 4), I think it's also a policy issue whether non-audio (or non-whatever-media) sessions are allowed. Or, the user may be prompted whether he is ok with a non-audio (or non-whatever-media) session. But, I do agree that it's good to mention that these kinds of offers should not be considered as errors - the client should be able to handle them. Regards, Christer -----Original Message----- From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Gunnar Hellstrom Sent: Wednesday, March 18, 2009 9:53 PM To: 'Hadriel Kaplan'; sipping@xxxxxxxx Subject: Re: FW: I-D Action:draft-kaplan-sipping-interop-bcp-01.txt Hadriel, I think this is a good initiative, and believe that a document like this can have an important task to both remind developers about common problem areas and propose good practices. The area I see most interoperability problems in is multimedia and offer/answer handling in SDP. Even these problem areas are related to SDP rather than SIP, I think they are so closely related to SIP that they should have a chapter in this draft. The following are typical interop problems: 1. Answer containing fewer m-lines than the offer. Each m-line in the offer MUST have a corresponding m-line in the answer. Denying media shall be done by including a corresponding m-line indicating port 0. 2. Offer containing more m-lines than the answering device was designed for. ( similar to 1 ) Each m-line in the offer MUST have a corresponding m-line in the answer. If an answering device was not designed to handle a specific medium in the offer, a corresponding m-line with port=0 MUST anyway be included in the answer, otherwise the media during the session may not even get into the intended ports and codecs. 3. Device misbehaves if no common audio codec is negotiated. The offer/answer cycle may result in no common audio codec, but other media agreed( e.g. video or text ). It is not uncommon that this results in no media flow at all or other malfunctions. Devices shall behave consistently even if no audio codec is agreed. 4. Device misbehaves if no m=audio line is included in the offer. Similar behaviour as no 2. There are designs that seem to have audio-centric roots and do not handle audio-less sessions well. I suggest that a section on this kind of problems is included. Gunnar -----Original Message----- From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Elwell, John Sent: Tuesday, March 10, 2009 6:46 PM To: Hadriel Kaplan; sipping@xxxxxxxx Subject: Re: FW: I-D Action:draft-kaplan-sipping-interop-bcp-01.txt Hadriel, Without commenting on specifics, I agree with the general principle, that there are lots of common sources of interop problems, and anything we could do to try to reduce these problems would be good. Each one of the topics requires a lot of discussion to determine what we want to do. However, what are your expectations? For example, do you want to develop the present draft to the extent of providing a single BCP covering these and perhaps other problem areas that we might identify? Or do you want to see these addressed during the revving of RFC 3261 etc.? Or does each topic need to be dealt with separately? John > -----Original Message----- > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Hadriel Kaplan > Sent: 09 March 2009 05:16 > To: sipping@xxxxxxxx > Subject: FW: I-D > Action:draft-kaplan-sipping-interop-bcp-01.txt > > > Howdy, > I have submitted a rough draft for a BCP for implementers to improve > SIP interoperability. > > Before you flame me for restricting SIP or having some evil intention > against some practice your implementation happens to do, understand > that: > a) this is just a first draft (though it's labeled version 01) > b) this is just a strawman, for discussion > c) interop problems are getting worse not better > d) interop problems are bad for us all, because it harms SIP's rep > e) this is a bit of a rushed job, and I haven't proof-read it well due > to time constraints (I have a day job, like anyone) > f) I am flame resistant (of the email variety, anyway) > > As always, comments/criticism/sarcasm/flames are welcomed. > > Have a nice day. :) > > -hadriel > > > -----Original Message----- > > From: i-d-announce-bounces@xxxxxxxx > [mailto:i-d-announce-bounces@xxxxxxxx] > > On Behalf Of Internet-Drafts@xxxxxxxx > > Sent: Monday, March 09, 2009 1:00 AM > > To: i-d-announce@xxxxxxxx > > Subject: I-D Action:draft-kaplan-sipping-interop-bcp-01.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-01.txt > > Pages : 13 > > Date : 2009-03-08 > > > > 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- > > 01.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 __________ NOD32 3923 (20090310) Information __________ Detta meddelande dr genomsvkt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ 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 _______________________________________________ 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
