Re: FW: I-D Action:draft-kaplan-sipping-interop-bcp-01.txt

[Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx>]

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