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

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sun, 12 Jul 2009 00:20:24 +0200

Hadriel,

Thanks for including 6.3 and 6.4 on sdp media mismatch interop problems.

It is very important that they get clearly and loudly communicated to the
SIP community. 

However, there are a couple of sentences I want to discuss.

1. Do not encourage voice-centric call rejections.
In 6.4 you say:
"But it is also not uncommon that audio+video offers are (and should be)
rejected if the 
   device receiving the offer supports both audio and video but just 
   not the specific audio codecs in the offer - even though it does 
   support the video media types offered."

This is the type of unfortunate assumptions that complicate life for SIP
device users who are not voice centric. The device manufacturer will usually
not be in a position to judge how the users want to use media in a call. A
call may very well be very valuable even if only matching video codecs were
found. ( many users I know do not bother if audio gets connected or not, it
is the video they want to use, and they want to be able to have calls with
mainstream devices with mainstream settings. )

Rather than rejecting calls based on one medium not having matching codecs,
I want to suggest that the normal behaviour should be to accept such calls.
So, please revert the advice.

If there is a desire to require specific media, it should be done under very
obvious user control, and e.g. done by using the caller preferences and
callee capabilities SIP headers, from RFC 3840 and RFC 3841. 

2. Too early to outlaw some features in chapter 7.
In chapter 7 you list some features that you think have not been used much
after a couple of years existence and therefore should be discontinued. It
is a long process to pick up these kinds of features in profiling groups
like OMA SIPforum, IMSforum, 3GPP, TISPAN, etc, where selected sets of SIP
features are implemented in controlled releases. You cannot know what
features may be just on their way to be included in a new release in any
such group. 
I expect for example the Accept-Language parameter to be one that eventually
will be used in more advanced service deployment with service behaviour
controlled by user profiles. 

I propose to restrict chapter 7 to warnings for features that have caused
problems because of incompatible implementations. I have for example
recently seen RFC 3428 SIP Message used for some kind of data collection
about the call rather than for user - to- user text messages. That causes
confusion in connection with a device that expects a text message to the
user in the SIP Message. Such usage can chapter 7 warn for.

Thanks

Gunnar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Saturday, July 11, 2009 11:00 PM
To: [email-masked]
Subject: I-D Action:draft-kaplan-sipping-interop-bcp-02.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-02.txt
	Pages           : 18
	Date            : 2009-07-11

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-02.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: Hadriel Kaplan <[email-masked]>
Date: Sun, 12 Jul 2009 02:28:26 -0400

Hi Gunnar, 
inline...

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Gunnar Hellstrom
> 

Yeah I screwed up that section.  It was not actually intended as "advice" or the "right thing to do" in all cases.  It was meant to point out that it is not uncommon that they are (and should be) rejected, but what's missing is a statement pointing out the opposite is true as well - that they are (and should be) accepted.  For example, a video-phone might well be usable in video-only mode; whereas a video-conference-system might prefer to reject the request to force a transcoder into the mix, or to fallback to ISDN.

That's why it goes on to say it is a local decision as to what the appropriate action to take is for such cases.  I'll correct it in the next iteration.

-hadriel

---

From: David Schwartz <[email-masked]>
Date: Sun, 12 Jul 2009 15:22:03 +0300

Hi Hadriel and thanks for this draft.

So last year I attempted to address your first issue (4.1) with regard to a response code that would "force" a failover (http://tools.ietf.org/html/draft-schwartz-sipping-nsr-code-01) and there was no take-up. I was relating at the time exactly to this problem you describe that has since been solved by reason phrases and other silly and proprietary mechanisms.

I still think that there should be a difference between: 
* I can't help you and no one can (e.g. user is not online - 404)
* I can't help you do to some temporary issue (network - 503 or otherwise - 480)
* I can't help you but feel free to try elsewhere (e.g. cannot find a route to the target do to one of many reasons)

And I still feel that there should be a new response code to this last category. 

Your thoughts?

D.

---

From: David Schwartz <[email-masked]>
Date: Sun, 12 Jul 2009 15:24:47 +0300

I was being sarcastic regarding the problem being solved in the previous email. The word "solved" should have been surrounded by double quotes :)

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 13 Jul 2009 02:00:19 -0400

> From: David Schwartz [mailto:[email-masked]]
> Sent: Sunday, July 12, 2009 8:22 AM
> 
> * I can't help you but feel free to try elsewhere (e.g. cannot find a
> route to the target do to one of many reasons)
> 

I thought that the last category *is* what a 404 is for, while the first category is a 604. (well, I assume you don't actually mean "cannot find a route to the target" for the last category - because that is what a 480 is for :)

It just happens that in practice hardly anyone ever sends a 604, even though they maybe should.  So if devices today send 404 for both case-1 and case-3 when they already have two different response codes for the two cases, then why would they change that behavior just because a new response code is created for one of the cases?  Or am I missing the gist of the problem?

-hadriel
p.s.  My guess is that it's not because they can't generate a 604 physically, but rather that the systems can't consistently and programmatically know when it would be correct to do so.  It's kind of a bold statement to say "I know you can't reach this user by any means anywhere", when the URI is an E.164 number.  For example some products only ever issue a 604 response when the ENUM server has an explicit entry for the target number, and the entry's NAPTR is the VOID/UNUSED type.  But otherwise they're dealing with provisioned route tables and HLR's and such, which may simply not have an entry for a number that isn't active, vs. an actual entry which explicitly says "not-active".  But that's just my personal theory.

---

From: David Schwartz <[email-masked]>
Date: Mon, 13 Jul 2009 10:05:43 +0300

> I thought that the last category *is* what a 404 is for, while the first category is a 604. 

So I always understood the difference between these two to be that a 404 indicated more of a "temporary" problem (i.e. user is valid but not online) as in fact a Retry-after can be added to a 404, while a 604 was more of a permanent problem (i.e. no such user) - not exactly what I was looking for. 

> (well, I assume you don't actually mean "cannot find a route to the target" for the last category - because that is what a 480 is for :)

My problem with the 480 is the "temporary" aspect associated with it which implies that there is a point in trying again (possibly after a Retry-after interval). In cases where I cannot route your request not due to network capacity issues (5xx) but due to the lack of the necessary commercial relationships - I do not see how this header is appropriate.

> It's kind of a bold statement to say "I know you can't reach this user by any means anywhere", when the URI is an E.164 number.  

I wasn't really referring to E164 with regard to 404 - more of registry based AORs.

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 16 Jul 2009 12:51:27 -0400

> mainstream devices with mainstream settings. )

The example that comes to mind is a call made to a deaf person, with
intention to use sign language over the video media.  But the deaf
person has disabled the audio media on his UA...

Dale