Hi Gunnar, I was trying to keep the BCP to just the SIP layer (though I know I got into SDP a couple times). But I agree we do see enough SDP issues, that I'll include these too in the next rev for now. I've seen 1, 2, and 4, but I don't think I've seen 3. I guess it depends on what you think "misbehaving" is - usually they just end/cancel the session. -hadriel > -----Original Message----- > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@xxxxxxxxxx] > Sent: Wednesday, March 18, 2009 3: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
