If you can't get offer/answer to work there is no idea in trying to get anything else work either :) Regards, Christer > -----Original Message----- > From: Sumit Garg [mailto:sgarg@xxxxxxxxxxxxxxxxx] > Sent: 19. maaliskuuta 2009 16:56 > To: Christer Holmberg; Gunnar Hellstrom; Hadriel Kaplan; > sipping@xxxxxxxx > Subject: RE: FW: I-D > Action:draft-kaplan-sipping-interop-bcp-01.txt > > Just wondering if this draft belongs in BLISS group even > though the charter for that is for services... > > -----Original Message----- > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Christer Holmberg > Sent: Wednesday, March 18, 2009 4:20 PM > To: Gunnar Hellstrom; Hadriel Kaplan; sipping@xxxxxxxx > Subject: Re: FW: I-D > Action:draft-kaplan-sipping-interop-bcp-01.txt > > > 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 > _______________________________________________ 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
