HAdriel, I have seen issue 3. If m-lines for audio are included properly, but no common codec was found, then I have seen cases when the session stays connected but the video flow or the realtime text flow does not work. It is probably part of the voice centric inheritage that the draft can contribute well to get away from. Gunnar ------------------------------------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@xxxxxxxxxx Tel: +46708204288 www.omnitor.se -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@xxxxxxxxxxxxxx] Sent: Friday, March 20, 2009 12:36 AM To: Gunnar Hellstrom; sipping@xxxxxxxx Subject: RE: FW: I-D Action:draft-kaplan-sipping-interop-bcp-01.txt 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 > __________ NOD32 3950 (20090320) 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
