Subject: RE: [Sipping] Question on do not disturb indication

From: "Elwell, John" <[email-masked]>
Date: Fri, 04 Aug 2006 16:19:55 +0100

Paul,

If it doesn't allow the proxy or UAC to take automated action, I find it
hard to agree with your opinion that Error-Info seems a reasonable approach.
A new response code would allow an automated action (particularly by a
proxy), and a UAC could also put up a suitable display. Admittedly this
would not be extensible to other conditions (except by defining yet more
response codes), but adding response codes for a small number of common
conditions ought to be feasible.

John

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 04 August 2006 14:13
> To: Dean Willis
> Cc: Elwell, John; Dolly, Martin C, ALABS; Scott Lawrence; 
> [email-masked]
> Subject: Re: [Sipping] Question on do not disturb indication
> 
> 
> Dean Willis wrote:
> 
> > If we believe that we'd like to convey a distinction between 
> > "Temporarily unavailable" and "Temporarily unavailable due 
> to subscriber 
> > choice" to a human, perhaps a reason phrase on a 480 would 
> be adequate? 
> > Like "480 Do Not Disturb", maybe.
> 
> I have never understood the purpose of reason phrases, or the 
> value of 
> sending different ones with the same response code.
> 
> Doing so implies an expectation that the UAC will do 
> something different 
> as a result. Its hard to do something different 
> algorithmically, because 
> there are no useful specs on what can be there. (Some UASs 
> may choose to 
> send the reason phrases translated into the language of the UAS 
> developer - say Klingon.)
> 
> About the best one could hope for would be for some UACs to *display* 
> the value, uninterpretted. But that only works for UACs that have the 
> capability to do so, and that in fact do so. Realistically, providing 
> that is only useful to geeks.
> 
> > Now, I will say that Martin is right in that there might be 
> many reasons 
> > to reject a call, that DND is just the tip of the iceberg, and that 
> > there's no way we can define them all.
> 
> Right.
> 
> There *is* a mechanism defined for this: Error-Info. There is 
> good and 
> bad to it:
> 
> - good: because the value is a URI (or several) it is arbitrarily 
> extensible to new reasons
> 
> - good: it can make it possible for the UAC to obtain 
> something that can 
> be rendered to the calling user, without the UAC needing to know all 
> possible reasons.
> 
> - bad: its still hard for the UAC or a proxy to take 
> programatic action 
> based on the reason because there are no standards for what 
> the reasons 
> might be. It is possible that two different UASs might choose 
> different 
> URIs to represent the same reason.
> 
> On balance, this seems like a reasonable approach to me.
> 
> 	Paul
> 

_______________________________________________
Sipping mailing list  https://www1.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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Aug 2006 13:53:46 -0400

> hard to agree with your opinion that Error-Info seems a reasonable approach.

An Error-Info URI wouldn't permit a proxy to automatically know what to 
do for all possible responses from all possible UASs. But it would allow 
local conventions to be established. If TISPAN wanted to establish a 
convention about an E-I URI that means whatever they think DND is, then 
the proxy can be taught how to react to that.

That could be done with URNs that have no other utility. Or it could be 
done with standardized URLs that could also be dereferenced and rendered 
by something that doesn't understand the convention.

> conditions ought to be feasible.

I'm with Jonathan that trying to define them that way is futile. There 
will not be sufficient agreement on what they mean. I don't want to see 
SIP locked down to a small fixed set of services.

	Paul