Subject: [Sipping] FW: I-D Action:draft-kaplan-sipping-interop-bcp-01.txt

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 9 Mar 2009 01:15:34 -0400

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: [email-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Monday, March 09, 2009 1:00 AM
> To: [email-masked]
> 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.

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 10 Mar 2009 17:46:13 +0000

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 09 March 2009 05:16
> To: [email-masked]
> Subject: [Sipping] FW: I-D 
> Action:draft-kaplan-sipping-interop-bcp-01.txt
> 
> 
> Howdy,
> Before you flame me for restricting SIP or having some evil 
> intention against some practice your implementation happens 
> to do, understand that:
> 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)

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 10 Mar 2009 22:09:22 -0400

My short term goal: gather input from others on interop issues they've seen which are common; add those to the list; refine the list of issues by deciding, per-issue, what can be given a BCP recommendation vs. what cannot; then publish.

Long term goal: I don't know.  I know there are interop problems with SIP... LOTS of interop problems with SIP.  And I think it would be better for SIP and all of us if we tried to resolve them, at least the more common ones.  Some of them are the fault of the RFC's, and some of them are vendor issues/bugs; and we probably need to go through each one at least at a high level to determine if we care and how to address them.

For the RFC ones, I am not sure anything can be done about them - making RFC changes may make things worse.  Or they may make things worse for a brief time, and make things better in the long run.  PRACK, for example, may be something we can fix with a change that is painful at first, but better in the long run.  Or another example is getting rid of the visual-separators concept. 

My goal was just to start the list - I am in no way claiming this is the top 10 either.  Obviously I am just one person and there are lots of people who see interop issues.  But even just for me it's not my top 10 - I forgot to add a few more common ones.  But I figured I'd submit a list and start it going.

-hadriel

> From: Elwell, John [mailto:[email-masked]]
> Sent: Tuesday, March 10, 2009 1:46 PM
>

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Wed, 18 Mar 2009 20:52:54 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Tuesday, March 10, 2009 6:46 PM
To: Hadriel Kaplan; [email-masked]
Subject: Re: [Sipping] 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

> Before you flame me for restricting SIP or having some evil intention 
> against some practice your implementation happens to do, understand 
> that:
> 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)
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

__________ NOD32 3923 (20090310) Information __________

Detta meddelande dr genomsvkt av NOD32 Antivirus.
http://www.nod32.com

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 18 Mar 2009 21:20:09 +0100

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Gunnar Hellstrom
Sent: Wednesday, March 18, 2009 9:53 PM
To: 'Hadriel Kaplan'; [email-masked]
Subject: Re: [Sipping] 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.

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.

Gunnar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John

Hadriel,

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 19 Mar 2009 15:58:46 +0100

If you can't get offer/answer to work there is no idea in trying to get
anything else work either :)

Regards,

Christer 

> From: Sumit Garg [mailto:[email-masked]] 
> Sent: 19. maaliskuuta 2009 16:56
> To: Christer Holmberg; Gunnar Hellstrom; Hadriel Kaplan; 
> [email-masked]
> Subject: RE: [Sipping] FW: I-D 
> Just wondering if this draft belongs in BLISS group even 
> though the charter for that is for services...
> 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: Wednesday, March 18, 2009 4:20 PM
> To: Gunnar Hellstrom; Hadriel Kaplan; [email-masked]
> 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 
> 
> [mailto:[email-masked]] On Behalf Of Gunnar Hellstrom
> 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.
> 
> Denying media shall be done by including a corresponding 
> m-line indicating port 0.
> 
> 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. 
> 
> 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.
> 
> There are designs that seem to have audio-centric roots and 
> do not handle audio-less sessions well.
> 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> 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 
> > I have submitted a rough draft for a BCP for implementers 
> to improve 
> > SIP interoperability.
> > 
> intention 
> This list is for NEW development of the application of SIP 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> This list is for NEW development of the application of SIP 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP 
> This list is for NEW development of the application of SIP 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 19 Mar 2009 19:35:36 -0400

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

> From: Gunnar Hellstrom [mailto:[email-masked]]
> Sent: Wednesday, March 18, 2009 3:53 PM
> Subject: RE: [Sipping] FW: I-D Action:draft-kaplan-sipping-interop-bcp-
> 01.txt
> 
> Hadriel,
> 
> can
> If
> media
> the

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 20 Mar 2009 06:59:09 +0100

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
[email-masked]
Tel: +46708204288
www.omnitor.se

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, March 20, 2009 12:36 AM
To: Gunnar Hellstrom; [email-masked]
Subject: RE: [Sipping] FW: I-D

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

> 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 
> 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.
> 
> 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.
> 
> 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
> 
> > intention against some practice your implementation happens to do, 
> > understand
> > that:
> > 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)

__________ NOD32 3950 (20090320) Information __________

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Mar 2009 17:14:47 -0400

Hadriel,

I like the concept, though not all the recommendations.

I especially dislike 5.3.1:

Continuing to send RTCP to an old address after that address has been 
changed to 0.0.0.0 is one of the most terrible ideas I have heard in a 
long time!!!

IMO, first trying just a=sendonly (or a=inactive) and falling back to 
0.0.0.0 is preferable to using both on the first attempt *if there is 
any value in keeping the old stream*. (That would be the case if there 
is a resource reservation for it, or you are using rtcp.) If there is 
*no* benefit to keeping the stream active then using 0.0.0.0 right from 
the start makes sense. But there can be some intelligence here. Having 
once learned if the other end supports the directionality attributes, or 
not, that can inform what is used in future exchanges in the same dialog.

5.6:

I predict this will lead to endless bickering. I know several of these 
that are in frequent use, though that use is often prorietary and hence 
won't have value in interop cases.

I think 3840 is used quite a bit in registrations and in Contact URIs, 
though I am not aware of a lot of usage of 3841. But I think IMS does 
use 3841. (Perhaps that's not a strong argument for considering it in an 
interop document.)

	Thanks,
	Paul

Hadriel Kaplan wrote:
>> ------------------------------------------------------------------------
>>
>> Use [email-masked] for questions on current sip
>> Use [email-masked] for new developments of core SIP

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 21 Mar 2009 19:16:04 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, March 20, 2009 5:15 PM
> 

Hehe, I thought someone would hate that one.  I thought it was deliciously evil. :)

> use 3841. (Perhaps that's not a strong argument for considering it in an

Yeah good point - someone in my company pointed out the same thing to me as well after I submitted the draft, and apparently we have seen both 3840/3841 used in practice.  I usually only see traces when there's a problem, so I guess they haven't had problems?

-hadriel

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sun, 22 Mar 2009 13:56:27 +0000

Hi Hadriel,

I also have a problem with 5.3.1. and agree with Paul's comment.

In addition do you think the recommendation should include the support
of sip.rendering parameter from RFC 4235 as a more explicit means of
indicating hold rather than relying on SDP alone? This parameter is also
used in some BLISS drafts like the shared appearances draft.

Maybe the recommendation should be that IP Address 0.0.0.0 should not be
generated but should be tollerated on receipt?

Regards
Andy

>[mailto:[email-masked]] On Behalf Of Paul Kyzivat
>Sent: 20 March 2009 21:15
>To: Hadriel Kaplan
>Cc: [email-masked]
>intention against some practice your implementation happens to 
>do, understand that:
>> 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)