Subject: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.txt

From: Laura Liess <[email-masked]>
Date: Fri, 5 Mar 2010 13:37:34 +0100

Hi,

We submitted a new version of the Alert-Info URN draft.

The new version incorporates the ML discussions where we think we
already reached a clear agreement. There are still open points.

The most important changes are:
- Requirements added/changed to incorporate the "semantic vs.
non-semantic" discussion and the new non-semantic examples from the
list.
- New alert-identifier "ringback" added.
- Chapter 4.2 "Public telephone network tones" deleted. "Busy",
"intrusion" and "record" were not correct anyway. Country list for
ringback tones deleted, reference to ISO 3166-1.
- Section 4.3.6 on crisis deleted
- "tone" and "ringback" combination deleted from chapter "Combinations of URN".
- Chapter "Combination Rules for Alert URN Indications" upgraded. We
hope the rules are  much more simple now when we distinguish between
ring tones and ringback tones.

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Alert-Info URNs for the Session Initiation Protocol (SIP)
	Author(s)       : D. Alexeitsev, et al.
	Filename        : draft-liess-dispatch-alert-info-urns-01.txt
	Pages           : 20
	Date            : 2010-02-26

The Session Initiation Protocol (SIP) supports the capability to
provide a reference to the alternative ringback tone (RBT) for
caller, or ring tone (RT) for callee using the Alert-Info header.
However, the reference addresses only the network resources with
specific rendering properties.  There is currently no support for
predefined standard identifiers for ringback tones or semantic
indications without being tied to a particular rendering.  To
overcome this limitation and support new applications, a new family
of URNs for use in SIP Alert-Info header fields is defined in this
specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert-info-urns-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.

Kind regards,
Laura

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Mar 2010 10:37:57 -0500

Laura,

Comments inline and at the end.

> - Section 4.3.6 on crisis deleted

Then why is it still mentioned in REQ-2?

> ring tones and ringback tones.

----------

Section 1:

    This specification does not change the usage of the SIP Alert-Info-
    header defined in the RFC3261.  The Alert-Info-header can be used in
    INVITE requests and 180 Ringing responses.

IMO it would make sense to make an extension to 3261 to permit this 
header in any 18x response. This could help resolve issues about what 
ought to be rendered to the caller in case of 182 or 183.

Section 3:

       ...  The left-most
       label is called "alert-category" and is separated from right-side
       of the alert-identifier, the alert-indication, by a semicolon...

          urn:alert:tone:{tone-indication}

The text says "semicolon" but the example uses colon, and the ABNF also 
shows colon.

Section 4:

The way the word "tone" is used in this section could cause confusion, 
after having gone to the trouble of explaining that this mechanism is 
for indicating semantic intent that might not be rendered as tones. Its 
further confused because section 4.1 PBX Tones are encoded using 
urn:alert:tone, but that 4.2 Service Tones are encoded using 
urn:alert:service.

I suggest using some other word than "tone" in cases when audio 
rendering may not be used. For example "indication". Perhaps "caller 
indication" could be used instead of ringback, and "callee indication" 
could be used instead of "ring". (Thats in descriptive text. Perhaps the 
alert-category of "tone" should be changed too, but I'm not ready to 
propose that yet.)

Sections 4.2.6, 4.2.7, 4.2.8:

These talk about "this sub-level". But sub-level isn't defined anywhere. 
There is "sub-indication" in the ABNF, but the examples given in these 
sections don't use that.

These are shown as urn:alert:tone, which means they can only be used for 
callee indication, not caller indication. Is that intended?

I know this might open old wounds, but perhaps it would be better to 
make these values simply be sub-indications on those values where it 
makes sense. But if you don't want to go there I understand.

Section 4.3:

Aren't there also country-specific ring tones? (I know the British ones 
in the movies are different from the American ones.) Should there be 
provision for specifying these? See more on this below.

Why no provision for non-country-specific ringbacks? This is potentially 
a case for customization - perhaps the callee's presence status could be 
used by the callee to select an appropriate ringback to the caller.

Section 4.4:

Are all combinations potentially valid? Or can there be at most one per 
category?

How about having alert:modifier as a category? Then all the other 
categories could be mutually exclusive, and zero or more modifiers would 
adjust whatever one was supplied. In that case, priority, zip, and 
delayed would be modifiers. (Maybe normal also ought to be a modifier, 
and maybe country code should also be a modifier - 
urn:alert:modifier:country:za.)

Section 5:

I think it would be a good idea to mention something about what a UA 
should do with these in more complex cases:
- alert-info received but in-band media also received
- an invite was forked and the UAC is getting responses from
   multiple early dialogs, containing conflicting alert-info
   and/or in-band media.

It occurs to me that in some cases early media should preempt the 
rendering of alert-info, but in other cases it should not. Maybe that 
should be left to implementor discretion, but maybe there are cases 
where this should be deterministic - I haven't thought about it enough 
to have a firm opinion.

Rolling all that up into some overall suggestions:

You have some things that only apply to the "ring", some that only apply 
to the "ringback" and some that apply to both. And then there are things 
that can act as modifiers to any of the others. But the distinction 
between ring and ringback is redundant with the message it travels in. 
So how about:

urn:alert:service:xxx has all the things you have as services plus all 
the things you have as "tones". In an INVITE external/internal describe 
the caller, and in a 18x they describe the callee. Maybe some additional 
values that are useful for describing the callee status.

urn:alert:modifier:xxx where xxx is priority/zip/delayed or country.cc
where cc is a country code.

Combinations allowed are one service, and one or more distinct 
modifiers. (Must be distinct based on top-level.)

---

From: Laura Liess <[email-masked]>
Date: Thu, 18 Mar 2010 16:57:33 +0100

Paul,

thank you for the comments and please excuse my late answer. I brooded
quite long about your comments.
I like very much your proposal about the "modifier"-category. I hope
Alan will agree to the change.
I talked to people involved in the DT IMS /NGN implementation
concerning some of the issues.

Please find the answers/comments in-line.

> Then why is it still mentioned in REQ-2?

 I will delete it in the next version.We just missed it when we did
the change.

> IMO it would make sense to make an extension to 3261 to permit this header
> in any 18x response. This could help resolve issues about what ought to be
> rendered to the caller in case of 182 or 183.

This would be very usefull, but can we do it in this draft? Or we need
to wait for 3261bis?

> The text says "semicolon" but the example uses colon, and the ABNF also

Agree. It should be "colon". I will change this.
>
> Section 4:
>
> The way the word "tone" is used in this section could cause confusion, after
> having gone to the trouble of explaining that this mechanism is for
> indicating semantic intent that might not be rendered as tones. Its further
> confused because section 4.1 PBX Tones are encoded using urn:alert:tone, but
> that 4.2 Service Tones are encoded using urn:alert:service.
>
> I suggest using some other word than "tone" in cases when audio rendering
> may not be used. For example "indication". Perhaps "caller indication" could
> be used instead of ringback, and "callee indication" could be used instead
> of "ring". (Thats in descriptive text. Perhaps the alert-category of "tone"
> should be changed too, but I'm not ready to propose that yet.)

Currently, the category "tone" is curently used only for PBX ring
tones (in case of audio rendering). It is somehow confusing, because
"service" and "ringback" are also tones. I don't like "tones", either.
I thought about changing it to ring-tone or PBX ring-tone, but I
didn't do it for the last version because such a change may affect
implementations of earlier versions of the draft. I think such changes
need a broad agreement before changing the draft. In particular, we
need Alan's agreement because the PBX tones is his part.

Personally, I would prefer "ring indication"  and "ringback
indication"  to   "caller indication" and  "callee indication". I
think the meaning is more obvious, even if the rendering is not audio.
In SIP we also habe 180 Ringing too, independent of the rendering. But
this is just a personal preference, I may be wrong .  We could ask on
the ML what other people think.

Another problem I see here is that currently "tone" (or "callee
indication" or "ring indication") is currently used only for PBX
ring-tones, not for ring tones in general. Somehow we should enable
also other kinds of ring tones. We can
a) delete the restriction to PBX ring-tones and use e.g.
urn:alert:ring-tone:normal also for public networks or
b) splitt the "tone" (or which ever new name we choose) category in
"pbx ring indications", and  "public ring indications" and maybe
others. People could then define new ring-tone categories in the
future,  e.g. "3GPP2 ring indications".
c) define the category as a chain consisting of a main-category and
sub-categories. , e.g. ring-indication:pbx,  ring-indication:public. .
The urns would be then urn:alert:ring-tone:pbx:normal,
urn:alert:ring-tone:pbx:internal,  urn:alert:ring-tone:pbx:external,
urn:alert:ring-tone:public:normal .

My preference is c), but then we have to change the ABNF Syntax and
define the alert-category in chap. 3 as being something like a chain
like

alert-categoryr= top-alert-category  *(":" alert-subcategory)
 top-alert-category = "ring-tone"/"ringback"/"service"  or
"callee-indication"/"caller-indication"/"service"
alert-subcategory = let-dig [*let-dig-hyp  let-dig]

I hope I don't run with this into the combination problems again....

> There is "sub-indication" in the ABNF, but the examples given in these

"Sub-level" is another relic from the old version. I will replace it
with "alert indication".
"Sub-indication"  is no longer used in the current use cases. We (Alan
and I) considered the issue, but decided not to delete the
sub-indication yet, until the new format is consolidated.  For the
examples in the draft, it is still correct, just not used th the
draft. If we agree to use things like urn:alert:modifier:country:za
or  urn:alert:ring-tone:pbx:normal we have to change the format
anyway.

> callee indication, not caller indication. Is that intended?

Yes. This is described in chap 7.2, second paragraph.

>
> I know this might open old wounds, but perhaps it would be better to make
> these values simply be sub-indications on those values where it makes sense.
> But if you don't want to go there I understand.

With the sub-indications we had the combination problem.....This is
why we changed it.

>
> Section 4.3:
>
> Aren't there also country-specific ring tones? (I know the British ones in
> the movies are different from the American ones.) Should there be provision
> for specifying these? See more on this below.

Up to now, nobody stated the requirement that they are needed.
I asked peopple within DT and they don't see a need for that. The DT
ring tone is implemented in each DT end device. (I am not happy with
it, but that's it.) There is no specific German ring tone, German
carriers have their own ring tone specification, but this
specifications are more or less the ITU-T specification on ring tone,
with some minor differences.

I think it should be possible in principle to define country ring
tones, if anyone needs them. With sub-categories we could do this with
<urn:alert:ring-indication:public:normal><
urn:alert:modifier:country:za> or just
<urn:alert:ring-indication:country:za>

I would avoid defining use cases for which it is very unclear if
someone needs them. But we should try to make the syntax as fexible as
possible for later use cases.

> Why no provision for non-country-specific ringbacks? This is potentially a
> case for customization - perhaps the callee's presence status could be used
> by the callee to select an appropriate ringback to the caller.

It's true. We have to be change the format to allow more than country
ringback tones. I don't have any clear idea how to do it yet. Maybe
<urn:alert:ringback-indication:country:za>  or
<urn:alert:ringback-indication:public:normal><
urn:alert:modifier:country:za> if we use sub-categories?

Concerning the presence status...I think this is more complex and
dedicated presence mechanisms should be used. We may run into privacy
and all other issues connected to presence. I would define here as a
use case. But it should be possible that people add this later if
there is a need for it.
> Are all combinations potentially valid? Or can there be at most one per

One per main category. I think we can state this if we use modifiers.
>
> How about having alert:modifier as a category? Then all the other categories
> could be mutually exclusive, and zero or more modifiers would adjust
> whatever one was supplied. In that case, priority, zip, and delayed would be
> modifiers.

I like the modifier :-). But we have to check with Alan and the
Mailing list, because of possoible existing implementations.

 (Maybe normal also ought to be a modifier, and maybe country code
> should also be a modifier - urn:alert:modifier:country:za.)
I don't have any opinion yet.

>
> Section 5:
>
> I think it would be a good idea to mention something about what a UA should
> do with these in more complex cases:
> It occurs to me that in some cases early media should preempt the rendering
> of alert-info, but in other cases it should not. Maybe that should be left
> to implementor discretion, but maybe there are cases where this should be
> deterministic - I haven't thought about it enough to have a firm opinion.

This is one of the basic SIP unsolved problems. I don't think we
should try to solve here this problem. Every end device, carrier...has
his own rules. DT already uses urn:alert:service: call-waiting. If a
UE receives it, the user gets the message "This is a waiting call"  on
the display if a display is there. We have no conflict with early
media. Other carrier or end devices can have other rules.

> You have some things that only apply to the "ring", some that only apply to
> the "ringback" and some that apply to both. And then there are things that
> can act as modifiers to any of the others. But the distinction between ring
> and ringback is redundant with the message it travels in. So how about:
>
> urn:alert:service:xxx has all the things you have as services plus all the
> things you have as "tones". In an INVITE external/internal describe the
> caller, and in a 18x they describe the callee. Maybe some additional values
> that are useful for describing the callee status.
>
> Combinations allowed are one service, and one or more distinct modifiers.
> (Must be distinct based on top-level.)
>

I think this would work and makes things quite simple, at least for
the use cases we have now.    I suppose if there is no service , but a
modifier like country.cc, then the default ring or ringback tone are
assumed. We also must remove the last paragraph on page 8 because
country.cc is a valid tone but country is not.   Country is here some
kind of modifier type.
I see only one problem here, which I don't nknow how to handle.What
happens when people add new alert-indications? Just add them to the
"service" or "modifier"-category? If so, we have two unstructured
lists of alert indications, which may become long with the time. I
suppose proxies may want to remove alert-indications which are not
relevant for their users, e.g. public carrier would want to remove
pbx-specific alert-indications generated at the other end of the
network, e.g. internal/external.  If there is no simple way to
recognize the alert indication which are not relevant for them, they
will use white lists and allow exactly the alert identifiers they use
within their own domain...I don't this is what we want.  But I may be
wrong with this.

Thanks  a lot
Laura

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Mar 2010 19:48:35 -0400

Laura - inline...

> This would be very usefull, but can we do it in this draft? Or we need

If I put on my (new) sipcore chair hat then I guess I should know the 
answer to this. But I don't. We aren't planning a bis, but changes are 
being managed. Will you be in Anaheim? Maybe we can corner a few people 
and discuss how this might be done.

> "service" and "ringback" are also tones. I don't like "tones", either.

I found it quite disconcerting as I was reading.

> indication"  to   "caller indication" and  "callee indication". I

I was just looking for *something*, and that works as well as my suggestion.

> define the alert-category in chap. 3 as being something like a chain

Or, urn:alert:ring-tone:normal.public, urn:alert:ring-tone:normal.pbx, ...

That way you can trim components off the end until you find something 
you understand.

The trouble with that is of course that it means that all the "pbx" 
extensions are not gathered together. If that is a problem.

Or, maybe "pbx" is a "modifier".

> possible for later use cases.

Yes, that is what I am pushing at - leaving enough wiggle room for these 
sorts of cases to fit later in a natural way.

> urn:alert:modifier:country:za> if we use sub-categories?

It seems to me that there ought to be symmetry for ring and ringback.

> use case. But it should be possible that people add this later if

I was only using presence as an example of why you might want other 
sorts of ringbacks. How they would be selected is a whole separate 
discussion.

> I don't have any opinion yet.

The modifier approach is a different spin on things and needs thinking 
through.

> assumed.

Right.

> We also must remove the last paragraph on page 8 because

It should be possible to add some hierarchy to help organize this.

> within their own domain...I don't this is what we want.  But I may be

I haven't thought about this. You are ahead of me.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Fri, 19 Mar 2010 13:43:12 +0100

2010/3/19 Paul Kyzivat <[email-masked]>:
>>>> - "tone" and "ringback" combination deleted from chapter "Combinations
>>>> of
>>>> URN".
>>> header
> If I put on my (new) sipcore chair hat then I guess I should know the answer
> to this. But I don't. We aren't planning a bis, but changes are being
> managed. Will you be in Anaheim? Maybe we can corner a few people and
> discuss how this might be done.

This would be great. I will be in Anaheim.
>>> after
> That way you can trim components off the end until you find something you
> understand.
>

We need something which helps proxies to decide quickly e.g. if it is
a public or pbx alert indication.
> Or, maybe "pbx" is a "modifier".
I would put  "pbx" in both "ring-indication"  fand "modifier"
alert-indications. External/internal are pbx "ring-indication" and
priority/zip/delayed are pbx modifiers.

>>> in
>>> a
Agree.
> I was only using presence as an example of why you might want other sorts of
> ringbacks. How they would be selected is a whole separate discussion.
>
>>> Section 4.4:
>>>
>>> categories

>>> rendering
>>> to
>>> the
>> I see only one problem here, which I don't know how to handle.What

There are some, probably few scenarios where filters are necessary.
E.g. an ED outside a PBX network sends "internal", just to get quick
phone access to a person inside an enterprise. The carrier or the
enterprise proxy should remove it, otherwise the callee gets a wrong
information. (maybe this is a security issue?) I would like to have
the structure which allows filtering which does not force filtering
proxies to use white lists consisting of discrete values, other
methods beeing too time consuming.

Let's have a chat in Anaheim about this.

Thanks a lot
Laura

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 21 Mar 2010 14:21:38 -0700

Hi,

> and discuss how this might be done.

we have approved a few specs that update RFC 3261. So, if needed, it is
possible to update it without issues a bis draft.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Mar 2010 14:50:35 -0400

I've been thinking about how the "namespace" of alert-info URNs might be 
reorganized. My goals in doing so are:
- allow the different "aspects" of the alert to be specified
- make it clear what the combination rules are for these
- allow for comparable expressiveness for rings and ringbacks
- provide room for extension

The following is a rough outline of a what I have in mind:

The urn syntax is as in the current draft, *except*:

alert-category  = "reason" / "priority" / "source" /
                   "duration" / "delay" / "locale" /
                   extension-category
extension-category = token

The principle for choosing these categories is that they are orthogonal. 
Hence there is a single rule for well-formedness of Alert-Info:
there can be at most one instance of each alert-category, and in 
principle any such combination is valid. (Though some may be silly or 
uninteresting.)

The above doesn't distinguish ring from ringback. That is to be 
determined from context - when present in a request it describes the 
ring. When present in a response it describes the ringback. Again, in 
principle any combination can be used for either ring or ringback, 
though some combinations may be silly or uninteresting.

The exact way in which the various categories are combined for rendering 
is left as an implementation issue. The implementation is free to ignore 
any or all at its whim.

Its my intent that things previously discussed in the draft can all be 
mapped onto these categories. Here is my swag at doing so:

urn:alert:reason:

- normal (default)
- call-waiting
- forward
- auto-callback
- recall.hold
- recall.transfer
- private.<private-name>

urn:alert:priority:

- normal (default)
- low
- high
- crisis
- private.<private-name>

urn:alert:source:

- unclassified (default)
- internal
- external
- friend
- family
- private.<private-name>

urn:alert:duration:

- normal (default)
- short (or could be "zip")
- long (for completeness, or omit if unneeded)
- private.<private-name>

urn:alert:delay:

- none (default)
- yes (not sure what to put here)
- private.<private-name>

urn:alert:locale:

- default (default)
- country.<ISO 3166-1 country code>
- private.<private-name>

In the above the "private.<private-name>" syntax is for extensions 
specific to independent organizations. The <private-name> is in the form 
of a "reverse FQDN" such as is used for Java package names. This gives a 
way of assigning unique names without the need for a new registry. The 
namespace for each alert category is independent. Those assigning new 
names must ensure they are in a position to assign names uniquely for 
the FQDN they choose.

(I have considerable reservation about introducing such an uncontrolled 
extension mechanism. I see how it can provide a lot of flexibility in 
providing tailored user experiences. But it can also lead to vendor lock 
in if a device is only capable of supporting a particular vendor's 
specific extensions. So I think this needs a lot of discussion.)

For example, I might want to define:

urn:alert:source:private.com.cisco.customer

If I were to do so, I should first ensure that I speak for cisco.com 
when coining this.

Additions to the values above other than via the "private" mechanism 
would be by standards action. The same for adding new categories.
(There could be a "private" mechanism for categories too. But I'm not at 
all confident that is a good thing.)

I'm not quite sure about "call-waiting" as a "reason" - it doesn't seem 
quite right. The reason could still be any of those other things. For 
the ring indication its far from clear to me that it is needed at all - 
the recipient already knows it is on a call, and doesn't need to be told 
that. It may make more sense for the ringback - in that case you are 
being told something about the state of the other party. Perhaps this 
should be replaced by something about the state of the party sending the 
message. E.g.

urn:alert:state:

- unknown
- waiting (in a request, means the caller is waiting
            for the call to complete. The normal case.)
- on-a-call (in a response, means the called party
              is on another call - the call waiting case.
              But could apply to a caller as well.)
- away (in a request, means the call has been generated
         automatically and the user will be summoned if/when
         the call completes. This is the converse of waiting)

(This "state" is really a form of presence. Whether its good to encode 
it here, rather than actually transmitting pidf, is an interesting 
question.)

How all of this might be mapped onto actual renderings is probably not 
something that should be standardized, but it might be worth including 
some possibilities as examples. One that comes to mind is:

(Assuming all rendering are audio):

- the device has a set of possible clips it can render
- each is attributed with the values it matches for each
   category above. (none, one, several, or all for each
   category.)

The device just finds the maximal match and renders that one.

This might be augmented if there are different sorts of renderings - 
e.g. audio, visual, tactile (vibrarion). In that case it might seek out 
a match for each sort and render them all.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Fri, 26 Mar 2010 02:26:51 +0100

Paul,

Thank you for the proposal and the elaborate description. I definitively
like it.
It seems to solve the combinations problem, it is extensible and easy to
understand. 
I have two comments on it, connected to "call-waiting".

1) It seems to me that there is some misunderstanding concerning the meaning
of the "call-waiting" alert urn. It is not the callee's presence state, but
the state of the call itself. The "call-waiting" tone tells the caller:
"Your call is temporary queued (waiting) at the callee's side because the
callee is currently involved in another call. The callee was informed that
your call is waiting." Having this information, the caller can decide to
wait for a while or to cancel the call. This is an already existing
PSTN-service which customers expect us to provide also when we migrate to
SIP.
Because this urn tells the user that the service "call-waiting" was
performed at the other side of the call, we name "service" was choosed for
this category. 

2) There are already implementations of urn:alert:service:call-waiting. This
syntax is used in the 3GPP Specification for the call-waiting service (TS
24.615 "Communication Waiting (CW) using IP Multimedia (IM) Core Network
(CN) subsystem"). If we change this name, people either change their
software, which means money and time for them, or they leave it as it is,
which means lack of interoperability e2e. The "reason"-category contains in
principles names for services, so I think it does not harm the proposal if
we just replace "reason" by "service" and keep the interoperability with
existing implementations.

Thanks a lot
Laura

-----Ursprüngliche Nachricht-----
Von: Paul Kyzivat [mailto:[email-masked]] 
Gesendet: Donnerstag, 25. März 2010 19:51
An: Laura Liess
Cc: [email-masked]; [email-masked]; Liess Laura; Gerold Pinker
Betreff: Re: [dispatch] FW: I-D
Action:draft-liess-dispatch-alert-info-urns-01.txt

urn:alert:reason:

- normal (default)
- call-waiting
- forward
- auto-callback
- recall.hold
- recall.transfer
- private.<private-name>

urn:alert:priority:

- normal (default)
- low
- high
- crisis
- private.<private-name>

urn:alert:source:

- unclassified (default)
- internal
- external
- friend
- family
- private.<private-name>

urn:alert:duration:

- normal (default)

urn:alert:delay:

- none (default)

urn:alert:locale:

- default (default)

urn:alert:state:

- unknown

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Mar 2010 22:02:19 -0400

> performed at the other side of the call, we name "service" was choosed for

I wasn't sure from the draft whether this was about the ringback to the 
caller (which is what you are describing), or whether it was about the 
"ring" to the callee, which is of typically different in this case.

As I noted, I didn't think it made that much sense as an indication to 
the callee, since the callee knows its status. So I think we are in 
agreement about the important use - for ringback when the callee is 
currently handling another call.

As I was writing things down I realized that this is really a statement 
about the state of the callee that happens to be known to the UAS and 
hence reportable. I realize in the commonly used case this is a 
"service" in the network, and hence is different from a feature of the 
UAS - such as a multi-line phone. But the two are functionally 
equivalent to both the caller and the callee - the callee is occupied on 
some other call, and may (or may not) be delayed in answering. (Whether 
this delay is likely to be longer, or shorter, than would be the case if 
not on another call, is debatable. I guess just reporting it to the 
caller as a datum does permit the caller to make his own judgement.

If this is reported as a distinct category, then it can be reported in 
an orthogonal way. For instance maybe the ringback will be "normal" but 
there will be a display on the phone - perhaps akin to a "on hold" light.

> existing implementations.

How to name things is a second order issue. If its just a matter of 
"service" vs. "reason" then I don't care very much. (I'm not especially 
attached to "reason", but I also find "service" somewhat confusing for 
the purpose.)

The orthogonality is more important. The way I partitioned the data is 
just a first cut, and I'm entirely open to alternative ways of doing 
that. But I would hate to see the categorization warped just to fit one 
preexisting use. IMO it would make more sense to special-case that one - 
perhaps treat it as a separate category of its own.

	Thanks,
	Paul