Subject: [dispatch] Alert Info Charter

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 May 2010 13:50:51 +0300

Folks,

I have make a few editorial changes to the Alert Info charter proposal
in order to clarify what we want to do (see attachment). Please, let me
know if you have some comments. I would like to get the whole IESG to
review it relatively soon.

One thing that still needs a bit of work is the last sentence of the
charter: "Whenever possible, the Alert-Info URNs identifiers should be
semantic."

The whole charter motivates the use of semantic identifiers but then, in
the last sentence, it opens the door to non-semantic identifiers (e.g.,
urn:alert:duration:short).

We need to either focus on working on semantic identifiers only or add
more text explaining the reasons why we also want to define non semantic
identifiers. Opinions?

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 May 2010 09:46:52 -0400

> more text explaining the reasons why we also want to define non semantic

The distinction between "semantic" and (whatever the converse it - 
"literal"?) is a little fuzzy.

Would it be better to use "brief" or "concise" rather than "duration:short"?

Is "Beethoven's Fifth" (as a name) "semantic" or "literal"?

I do think there is a place for URNs that are "names" for more literal 
things like that. But defining those should probably be out of scope for 
*this* exercise.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Fri, 07 May 2010 08:54:04 -0500

> more text explaining the reasons why we also want to define non semantic

I've already explained my thoughts on the topic, but I'll summarize them 
again.

We are going to be interoperating with legacy systems for the 
foreseeable future. In many of these legacy systems, the mechanism used 
to convey information is inherently non-semantic. When we interwork this 
mechanism with those systems, we have two choices:

   1. Convert the non-semantic information that has arrived into a
      non-semantic indication in SIP (e.g., "short"), or
   2. Irreversibly discard the information that has arrived.

Option #2 leads to a clearly inferior experience.

So, while I understand the motivation for defining semantic-only codes 
in this space, I think we need to allow conveying non-semantic 
information under limited circumstances. To be clear, I would argue for 
MUST-level language that prohibits the use of non-semantic indicators 
except for legacy interoperation -- but I think we need the charter to 
allow it.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 May 2010 10:27:27 -0400

I haven't been following the Alert-Info thread at all, so maybe I'm a good test-case for whether this charter makes any sense. :)

Like Paul, I have absolutely no idea what "semantic" vs. "non-semantic" URNs are.  I'm not sure you want to use the word "semantic" here.  I think I know what the word "semantic" means: that the thing "has a meaning".  But the URN "urn:alert:duration:short" does have a meaning; it means play a short tone, presumably. :)

I *think* what you're getting at is you want the URN to indicate the alerting status, like urn:alert:status:call-waiting.  So that the UAC receiving this URN can play whatever tone it wants for that status.  Right?  So it's like defining specific SIP response sub-codes of 18x, but in a header instead of a response-code number? (or maybe it's like a Reason header value for a response)  Is that correct?

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Friday, May 07, 2010 9:47 AM
> 
> Gonzalo Camarillo wrote:
> > Folks,
> >
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Tom Taylor <[email-masked]>
Date: Fri, 07 May 2010 10:45:46 -0400

I can talk about how this sort of thing was handled on the legacy switching 
side, for a switch whose innards I am familiar with. The routing tables pointed 
to what was called a "treatment" (your semantic URN). A second table pointed 
from the treatment itself to its implementation as tones (or announcements, in 
the switching case). That's your non-semantic URN. Our software designers had a 
big problem confusing "reorder treatment", a response to a very specific 
condition, with "reorder tone", which was used to implement a number of treatments.

Anyway, I suggest a conscious effort be made to distinguish the semantics from 
the implementation, since the counterpart distinction exists on the 
circuit-switching side.

Hadriel Kaplan wrote:
> I haven't been following the Alert-Info thread at all, so maybe I'm a good
> test-case for whether this charter makes any sense. :)
> 
> Like Paul, I have absolutely no idea what "semantic" vs. "non-semantic" URNs
> are.  I'm not sure you want to use the word "semantic" here.  I think I know
> what the word "semantic" means: that the thing "has a meaning".  But the URN
> "urn:alert:duration:short" does have a meaning; it means play a short tone,
> presumably. :)
> 
> I *think* what you're getting at is you want the URN to indicate the alerting
> status, like urn:alert:status:call-waiting.  So that the UAC receiving this
> URN can play whatever tone it wants for that status.  Right?  So it's like
> defining specific SIP response sub-codes of 18x, but in a header instead of a
> response-code number? (or maybe it's like a Reason header value for a
> response)  Is that correct?
> 
> -hadriel
> 
> 
...

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 May 2010 10:54:56 -0400

> Like Paul, I have absolutely no idea what "semantic" vs. "non-semantic" URNs are.  I'm not sure you want to use the word "semantic" here.  I think I know what the word "semantic" means: that the th…

Well, I *have* been in the discussion. I do know more or less what is 
intended by "semantic", so now the word doesn't bother me, though there 
may indeed be some better word to use.

My point is really that "semantic" and "literal" (or whatever) are like 
"big" and "small" - names for ends or directions on a continuum.

In this case, "call-waiting" is closer to semantic than 
"tone:beep-beep". But "tone:beep-beep" is more semantic than an audio 
clip of the tone is.

> I *think* what you're getting at is you want the URN to indicate the alerting status, like urn:alert:status:call-waiting.  So that the UAC receiving this URN can play whatever tone it wants for that status.  Right? 

Or something that is not just a tone - flashing lights, something on a 
display, etc.

> So it's like defining specific SIP response sub-codes of 18x, but in a header instead of a response-code number? (or maybe it's like a Reason header value for a response)  Is that correct?

Yes.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 May 2010 10:59:35 -0400

Oh, sorry I thought you were saying the word "semantic" had no clear meaning in this context.

-hadriel

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, May 07, 2010 10:55 AM
> To: Hadriel Kaplan
> Cc: Gonzalo Camarillo; DISPATCH
> Subject: Re: [dispatch] Alert Info Charter
> 
> 
> 
> Hadriel Kaplan wrote:
> > I haven't been following the Alert-Info thread at all, so maybe I'm a
> good test-case for whether this charter makes any sense. :)
> >
> > Like Paul, I have absolutely no idea what "semantic" vs. "non-semantic"
> URNs are.  I'm not sure you want to use the word "semantic" here.  I think
> I know what the word "semantic" means: that the thing "has a meaning".
> But the URN "urn:alert:duration:short" does have a meaning; it means play
> a short tone, presumably. :)
> 
> > I *think* what you're getting at is you want the URN to indicate the
> alerting status, like urn:alert:status:call-waiting.  So that the UAC
> receiving this URN can play whatever tone it wants for that status.
> Right?
> 
> > So it's like defining specific SIP response sub-codes of 18x, but in a
> header instead of a response-code number? (or maybe it's like a Reason
> header value for a response)  Is that correct?
> 
> Yes.
> 
> > -hadriel
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 May 2010 11:11:40 -0400

> except for legacy interoperation -- but I think we need the charter to 

Adam, I understand your point in the abstract, but maybe not in practice.

If non-semantic (literal) information is arriving, is there any 
practical way to convert it to a URN of any sort? I.e. if a reorder tone 
is being received by a gateway in the media stream, can we expect that 
it will decode that and be able to determine that it ought to convey an 	
	Alert-Info: urn:alert:reorder-tone

OTOH, if it receives signaling that says "play a reorder-tone" then I 
agree it would be good to have an alert urn that specifies exactly that. 
How "semantic" the urn can be for that depends on the specificity of 
this signal in the environment in which it is received.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 May 2010 11:18:04 -0400

Right, that's what I was trying to correlate the issue to.
What this charter is really saying to me is that either there are not enough 18x response-code values for all conditions, or there are multiple "sub-causes" for a 18x response.

In other words, why isn't this just draft-jesske-dispatch-reason-in-responses-02, but possibly for protocol=SIP? 

Why don't we just solve these problems one common way?  Why do we need one status code in the SIP response start line, another one in the Reason header, and another one in an Alert-Info header?  Is there a need for the Reason header's status to be different than the Alert-Info's?  Inquiring minds want to know.

-hadriel

> From: Tom Taylor [mailto:[email-masked]]
> Sent: Friday, May 07, 2010 10:46 AM
> To: Hadriel Kaplan

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 May 2010 18:20:23 +0300

Hi,

thanks all of you for the input. I think all these comments will improve
the charter significantly.

In past conversations, the term "semantic" was applied to descriptions
of events. A semantic URN would describe *what* is happening. For
example, the call is waiting, or the callee is busy, or the call waiting
queue is one person shorter now.

On the other hand, non-semantic URNs would provide rendering
instructions. For example, play a short tone followed by a long one. Of
course, "play a given symphony" involves a more complex rendering, but
is nevertheless non semantic, because the entity receiving such an
instruction does not know anything about the event being signaled. Does
it need to play that symphony because the callee is busy or because they
call is waiting?

Now, people who were involved in past discussions are familiar with this
terminology, but it is clear from this thread that people reading the
charter proposal for the first time did not find it clear enough. We
have two options: we stick to the terms "semantic" and "non semantic"
and explain more precisely what they mean, or we use different terms.
Opinions?

Thanks,

Gonzalo

---

From: Alan Johnston <[email-masked]>
Date: Fri, 07 May 2010 10:27:44 -0500

Hadriel,

The answer is that different entities generate the SIP response
code/Reason value and select the alerting tone.  Alerting is typically
chosen locally, either by a UA or by a proxy/PBX for the UA, so this
can't use a common mechanism.

Also, every vendor implements this today using Alert-Info URI
conventions.  Unless you are arguing this is fundamentally broken
somehow, fixing this interop problem by standardizing a few URNs seems
like a very clean solution.

Sure, we could invent a grand unifying theory and mechanism, but would
it get deployed?

- Alan -

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 7 May 2010 17:28:22 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 07 May 2010 16:12
> To: Adam Roach
> Cc: DISPATCH
[JRE] This is confusing me further. What are the semantics of "reorder"? Does it mean "rearrange the order", or "place the order again". If the latter, is that a request or demand to place the order again (e.g., make the call again), or some sort of statement? I would suggest this word is not a very good example of a "semantic" tone. I would expect the name of a semantic tone to clearly indicate a particular condition, rather like SIP response codes do.

John

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 May 2010 18:26:55 +0300

Hi,

we could add text to the charter explaining that non-semantic (or
whatever we decide to call them) URNs are only useful for gateways
interworking with the PSTN or similar legacy telephone systems. The WG
would only work on them within that limited scope. Would that work for
everybody?

I believe an explanation along these lines would be much better than the
"whenever possible use semantic URNs" we currently have in the charter
proposal :o)

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 May 2010 18:33:41 +0300

Hi,

it would be good indeed to get comments on the alternative proposal
below. That is, using status codes instead of URNs in order to signal
the types of events we are dealing with in the URN proposal.

In any case, we need a story to explain why we choose or don't choose
such an alternative proposal.

Thanks,

Gonzalo

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 7 May 2010 17:35:44 +0200

In another place I think they used to talk about "functional" and "stimulus".

John 

> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: 07 May 2010 16:20
> To: Hadriel Kaplan
> Cc: DISPATCH
> Subject: [dispatch] Terminology WAS (Re: Alert Info Charter)
> 
> Hi,
> 
> >>>>> in order to clarify what we want to do (see 
> attachment). Please, let
> >> me
> >>>>> The whole charter motivates the use of semantic 
> identifiers but then,
> >> in
> >>>> things like that. But defining those should probably be 
> out of scope
> >> for
> >>>> *this* exercise.
> >>>>
> >>>> 	Thanks,
> >>>> 	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 7 May 2010 17:40:43 +0200

We already have the Alert-Info header field, which is meant to be the vehicle for ringing and ring-back tones, and I don't see the point in trying to be disruptive there.

On the other hand, some of the semantic tones suggested are for conditions that might not necessarily coincide with the sending of an INVITE request or a 18x response, and hence Alert-Info would not be available as things stand. So it depends whether people really see this work applying outside the context of INVITE requests and 18x responses.

John 

> Sent: 07 May 2010 16:34
> Subject: [dispatch] Alternative approach WAS (Re: Alert Info Charter)
> 
> Hi,
> 
> > What this charter is really saying to me is that either 
> there are not enough 18x response-code values for all 
> conditions, or there are multiple "sub-causes" for a 18x response.
> > 
> > In other words, why isn't this just 
> draft-jesske-dispatch-reason-in-responses-02, but possibly 
> for protocol=SIP? 
> > 
> > Why don't we just solve these problems one common way?  Why 
> do we need one status code in the SIP response start line, 
> another one in the Reason header, and another one in an 
> Alert-Info header?  Is there a need for the Reason header's 
> status to be different than the Alert-Info's?  Inquiring 
> minds want to know.
> > 
> > -hadriel
> > 
> > 
> >> side, for a switch whose innards I am familiar with. The 
> routing tables
> >> pointed
> >> to what was called a "treatment" (your semantic URN). A 
> second table
> >> pointed
> >> from the treatment itself to its implementation as tones 
> (or announcements,
> >> in
> >> the switching case). That's your non-semantic URN. Our 
> software designers
> >> had a
> >> condition, with "reorder tone", which was used to 
> implement a number of
> >> treatments.
> >>
> >> Anyway, I suggest a conscious effort be made to 
> distinguish the semantics
> >> from

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 May 2010 11:59:38 -0400

> We already have the Alert-Info header field, which is meant to be the vehicle for ringing and ring-back tones, and I don't see the point in trying to be disruptive there.

I agree.

> On the other hand, some of the semantic tones suggested are for conditions that might not necessarily coincide with the sending of an INVITE request or a 18x response, and hence Alert-Info would no…

Currently A-I is restricted to INVITE and 180. I have already proposed 
that this be relaxed, so that it can be used in 18x.

Whether the same "problem" extends beyond that scope is unclear to me.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 May 2010 12:42:22 -0400

> From: Alan Johnston [mailto:[email-masked]]
> Sent: Friday, May 07, 2010 11:28 AM
> To: Hadriel Kaplan
> 

Right, what you want is the device generating the response indicates the condition, and the UAC receiving the response generates a locally-mapped tone for that condition.  I get that, and it makes a lot of sense to me.

So ISTM what we want is for the device generating the SIP response to indicate a status code, which the UAC can map to whatever tones it wants.

The funny thing is we already have a way to do that. Two ways, in fact: the message's status-line status-code number, and the Reason header value. 

I'm not actually proposing the SIP message response status-code be expanded for this (both because of interop issues and because there aren't enough digits in 18x to accommodate all conditions).  But I think the Reason header isn't a bad choice.

> like a very clean solution.

Actually, it *is* broken, in three ways (though they may all be fixable):

1) You can't add more URN values later, because you don't know if the UAC understands the new URN.  Compare this to a status-code model, where you can treat a new 187 code as a 180 if you don't understand the 187. (although I suppose you could actually just make the URN a number format, or define the format to indicate a default as well, so you can get this property)

2) An Alert-Info header can only appear in 180 responses, and not 182, 183, etc.  I suppose 3261 could be extended though to include it in other responses, though.

3) You can't deploy this new URN scheme in a backwards-compatible fashion in practice, unless you have an indicator in the request which states the UAC supports it.  If you have such an indicator, you might as well put this in a Reason header instead and not have two different headers to indicate the same status.  And as it turns out, if you use the Reason header then I don't think you need an indicator in the request to begin with.

> Sure, we could invent a grand unifying theory and mechanism, but would

If there are real interop problems with Alert-Info, and people really want to fix them, and it's not much more work... then yes I think it would.  I'm not suggesting a lot of additional work, am I?

I don't think using the Reason header alone instead of both is such a big change.  Seems simpler to me, in fact.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 May 2010 12:47:06 -0400

Or you could make the charter not pre-suppose a solution. ;)

-hadriel

> Behalf Of Gonzalo Camarillo
> Sent: Friday, May 07, 2010 11:27 AM
> To: Adam Roach
>

---

From: Brett Tate <[email-masked]>
Date: Fri, 7 May 2010 09:55:37 -0700

> Whether the same "problem" extends beyond that scope is unclear to me.

The scope should likely be extended to allow Alert-Info within UPDATE.  It looks like rfc3261 already allows Alert-Info within re-INVITE.

---

From: Brett Tate <[email-masked]>
Date: Fri, 7 May 2010 10:26:41 -0700

Since REFER can be used to originate calls, Alert-Info should likely be valid within REFER.

Since I assume some vendors send Alert-Info within INFO or NOTIFY during a call waiting notification, Alert-Info potentially should also be valid there.  However I guess making it valid could wait until someone officially registers such a usages.

> From: Brett Tate
> Sent: Friday, May 07, 2010 12:56 PM
> To: 'Paul Kyzivat'; DISPATCH
> Subject: RE: [dispatch] Alternative approach WAS (Re: Alert Info
> Charter)
> 
> The scope should likely be extended to allow Alert-Info within UPDATE.
> It looks like rfc3261 already allows Alert-Info within re-INVITE.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 May 2010 13:45:51 -0400

> From: Elwell, John [mailto:[email-masked]]
> Sent: Friday, May 07, 2010 11:41 AM
> To: Gonzalo Camarillo; Hadriel Kaplan
> 
> We already have the Alert-Info header field, which is meant to be the
> vehicle for ringing and ring-back tones, and I don't see the point in
> trying to be disruptive there.

I can't tell in what way you mean that.  

Do you mean it's less disruptive to put a status code into Alert-Info, because people already use Alert-Info URI's for the ringing playback process?  

Or do you mean it's less disruptive to leave the Alert-Info for what it was intended for: to indicate the URI of a ringtone with no semantics, and instead put the status code into something which is actually meant for status code?

And what do you mean by "disruptive"?  To me "disruptive" is when interop or service issues happen due to the proposed change, but maybe you mean something different?

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Fri, 07 May 2010 13:40:31 -0500

On 5/7/10 10:11 AM, Paul Kyzivat wrote:
>> I've already explained my thoughts on the topic, but I'll summarize 
>> them again.
>>
>> foreseeable future. In many of these legacy systems, the mechanism 
>> used to convey information is inherently non-semantic. When we 
>> interwork this mechanism with those systems, we have two choices:
>>
>> So, while I understand the motivation for defining semantic-only 
>> codes in this space, I think we need to allow conveying non-semantic 
>> information under limited circumstances. To be clear, I would argue 
>> for MUST-level language that prohibits the use of non-semantic 
>> indicators except for legacy interoperation -- but I think we need 
>> the charter to allow it.
>
> practical way to convert it to a URN of any sort? I.e. if a reorder 
> tone is being received by a gateway in the media stream, can we expect 
> that it will decode that and be able to determine that it ought to 
> convey an
> agree it would be good to have an alert urn that specifies exactly 
> that. How "semantic" the urn can be for that depends on the 
> specificity of this signal in the environment in which it is received.

Not interworking with *in-band* tones -- I'm talking about other 
protocols that include indication of ringing and/or ringback tone in the 
signaling. For example, TIA/EIA-41-D and 3GPP2 A.S0014 both define a 
number of tones that end up being used all over the place. Some of these 
are what we've been calling semantic ("inter-group alerting"), while 
others clearly aren't ("short-short-long").

A.S0014 defines:

   1. Normal Alerting
   2. Inter-group Alerting
   3. Special/Priority Alerting
   4. Ping Ring (abbreviated alert)
   5. Abbreviated intercept
   6. Abbreviated reorder

I think #1 and #4 are covered in the current document, but the others
aren't clearly represented.

If you throw in the TIA/EIA values, you also have things like:

   1. Long (Normal)
   2. Short-Short
   3. Short-Short-Long
   4. Short-Short2
   5. Short-Long-Short
   6. Short-Short-Short-Short
   7. PBX Long (Normal)
   8. PBX Short-Short
   9. PBX Short-Short-Long
  10. PBX Short-Long-Short
  11. PBX Short-Short-Short-Short

Additionally, A.S0014 allows indication of pitch (high, normal, low) as 
part of the ringtone designation.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 May 2010 14:45:59 -0400

> [JRE] This is confusing me further. What are the semantics of "reorder"? Does it mean "rearrange the order", or "place the order again". If the latter, is that a request or demand to place the orde…

Sorry if my reasoning was obscure.

I was trying to query Adam about the point he was making, which was 
explicitly when "semantic" information is not available. So I grabbed 
something at random (reorder-tone) as an example of something that is 
*not* semantic.

So I do take Adam's point - *if* we have cases where a request to play a 
particular tone is received, identifying that tone "by name", then maybe 
there should be a way to include such names in the alert-info as URNs. 
That would lose less information than either dropping them or rendering 
them as actual media.

(These URNs would not necessarily have to be the same URN scheme as the 
"semantic" ones. I think that choice should be made based on who is 
going to administer them.)

	Thanks,
	Paul

P.S. In certain contexts it may be possible to infer semantics from 
either a named request for "reorder-tone" or even by decoding media 
rendering a reorder-tone, *if* you know that in the context where it is 
received it is only used as an expression of a particular semantic. But 
certainly that wasn't what Adam meant. If you can infer the semantics, 
no matter how, then of course you can signal it using the appropriate 
semantic URN.

---

From: Adam Roach <[email-masked]>
Date: Fri, 07 May 2010 13:46:42 -0500

On 5/7/10 10:28 AM, Elwell, John wrote:
> [JRE] This is confusing me further. What are the semantics of "reorder"?

http://dictionary.sensagent.com/reorder+tone/en-en/

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 May 2010 14:58:04 -0400

Adam,

OK, that is exactly what I was looking for.
(I'm just a SIP guy - none of this crufty old telco stuff for me.)

I've got no problem with covering such things.

The current proposal includes a number of orthogonal "dimensions" that 
can be provided, and are expected to be "combined" to select what to 
render. But those are all "semantic" dimensions.

This non-semantic sort is at least a different "dimension", and it 
probably makes little sense to combine it with semantic dimensions. They 
are most likely mutually exclusive.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 May 2010 23:00:49 +0300

Hi,

it is not really about presupposing a solution. It is about motivating
what we want to specify. It is just weird to have a charter that uses
several paragraphs justifying the need for semantic URNs and then in the
last line says that non-semantic URNs are also in scope without
providing any justification for them.

Cheers,

Gonzalo

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 May 2010 21:53:52 -0400

Sorry for the confusion - I meant not pre-suppose the solution uses a URN in the Alert-Info header to begin with.  Since what you really want is effectively a status code, it seemed silly to me to have two or more "status codes" in the same message, in different fields.  It's like the old "do what I mean not what I say", only here we have multiple things you say, each competing to be the one you really mean.

In particular, there's another I-D draft-jesske-dispatch-reason-in-responses-02, which could also solve the problem, but the charter would rule it out because the charter defines the solution.  Or think of it another way: perhaps the Alert-Info solution can accommodate the needs of the reason-in-responses draft as well.

-hadriel

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Friday, May 07, 2010 4:01 PM
> To: Hadriel Kaplan
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 08 May 2010 09:24:57 +0300

Hi Hadriel,

yes, I also think we should discuss that. That is why I changed the
subject lines in my replies so that the threads do not get too confusing
;o)... I called the discussion below "Alternative Approach", as opposed
to, for example, this one (Scope: Non-semantic URNs), which is about the
scope of the effort.

Thanks,

Gonzalo

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 8 May 2010 11:09:39 -0400

Proposed text for why the SIP Response Status-Code in particular is not useful:

"While the SIP Response 18x Status-Code in the Status-Line does offer semantic indication of the alerting state, it is not useful for solving this charter's problems because there aren't enough numeric values available to indicate all of the possible semantic alerting conditions.  Furthermore, it can only be indicated in a SIP Response message, whereas this charter's scope covers Requests as well."

-hadriel

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Saturday, May 08, 2010 3:07 AM
> 
> As Hadriel indicates, semantic indications (i.e., your call is in a
> queue) in SIP have been traditionally provided in status codes. If we
> decided to use Alert-Info URNs instead, we would need to explain why in
> the charter.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 8 May 2010 11:30:03 -0400

> To make this decision, we also need to agree on which messages need to
> carry these semantic indications. It is only INVITEs and 180 responses,
> INVITEs and 1xx responses, or something else?

RESPONSES:
If you don't support it in the 181, 182 and 183, we'd have to explain why not.  Because the use-cases for call-forwarding and call-waiting are explicitly indicated in the charter, and afaik those *are* 181 and 182.  And 183 is supposed to be the response code used when 180/181/182 are not semantically correct, so again it seems appropriate for this type of thing.

REQUESTS:
You may want it to be available in a BYE as well.  For example, disconnected calls due to error cases sometimes get special tones. 

Brett mentioned the UPDATE method, since re-INVITE is covered, which seems reasonable.

He also mentioned the REFER method, though I'm not sure in what way he meant it. (ie, is it for the receiver of the REFER, or is it meant to be in the INVITE created from it)

He also said "Since I assume some vendors send Alert-Info within INFO or NOTIFY during a call waiting notification, Alert-Info potentially should also be valid there.  However I guess making it valid could wait until someone officially registers such a usages."

Personally I don't see any reason to restrict what methods it's allowed to be put into - it's always up to the receiver to decide if it wants to use it anyway.  It doesn't affect dialog state, so what's the harm?

-hadriel

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 08 May 2010 13:48:47 +0300

Hi,

this is the most important issue we have to resolve before I revise the
charter again in order to get it reviewed by the IESG. Let me try and
summarize the discussions so far:

RFC3261 defines Alert-Info for non-semantic indications (e.g., you
should play this particular tone). Extending it to describe those
non-semantic indications (e.g., play a short tone followed by a long
one) seems not to be controversial. It seems we want to scope those
extensions to interworking situations, though.

Another conversation we have had a few times in the context of allowing
Reason header fields in responses is what happens when we carry two
semantic indicators about the status of a given call (e.g., the status
code and a URN, or the status code and another status code in a Reason
header field). Thinking of this can be useful in the context of
chartering this WG as well.

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 09 May 2010 11:03:00 +0300

Hi,

inline:

On 08/05/2010 6:09 PM, Hadriel Kaplan wrote:
> "While the SIP Response 18x Status-Code in the Status-Line does offer
> semantic indication of the alerting state, it is not useful for
> solving this charter's problems because there aren't enough numeric
> values available to indicate all of the possible semantic alerting
> conditions.

yes, this is a limitation... but it could be resolved relatively easily.
In fact, there were discussions about how to extend the status code
namespace some time ago.

>  Furthermore, it can only be indicated in a SIP Response
> message, whereas this charter's scope covers Requests as well."

yes, that explains why the "status line" cannot be used for this... but
Reason header fields can carry status codes in some requests (they could
be extended to cover INVITEs as well if needed).

In summary, Hadriel has identified two limitations about using status
codes for this. Is defining URNs a better or a worse solution than
specifying ways to overcome these limitations?

As indicated in this thread before, we need to look at backwards
compatibility issues as well so that whatever we define has as many
chances as possible to be deployed.

Thanks,

Gonzalo

---

From: Laura Liess <[email-masked]>
Date: Sun, 9 May 2010 18:44:26 +0200

Hi,

I don't think that replacing the Alert-Info URNs with respose/status
codes is a good idea, for following reasons:
- The Alert-Info URN is tightly coupled with the rendering. It is not
the rendering itself but an indication describing the semantic or the
characteristic(s) of the rendering. In the general case it does not
describe the call status.
- We choosed to use URNs as a flexible and extensible Internet-like
mechanism to work for the general case in Internet, beyond the
PSTN-like telephony. Currently we have only telephony use-cases, but
we intended to define a general mechanism.
- We choosed to use URN so the receiving UA can querry URN-resolvers
to get the rendering.
- We already have use cases which seems to me to be problematic if you
want to cover them with codes.  E.g. country ringback tones. With the
Alert-info URN we have urn:alert:locale:country.<ISO 3166-1 country
code>.  How could you represent this as response/status codes?
- What about combination rules? This was one of the issues for which
we had a lot of discussions for Alert-Info URNs.

Thanks to Paul, we have now a quite flexible and well-sttructured
syntax for Alert-Info URN (still not in the draft, but the the result
of a ML-discussion):

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

Values for alert-indications:

urn:alert:service:
- normal (default)
- call-waiting
- forward
- recall.callback
- recall.hold
- recall.transfer
- private.<private-name>

urn:alert:priority:
- normal (default)
- low
- high
- private.<private-name>

urn:alert:source:
- unclassified (default)
- internal
- external
- friend
- family
- private.<private-name>

urn:alert:duration:
- normal (default)
- short (or "zip")
- long
- private.<private-name>

urn:alert:delay:
- none (default)
- yes
- private.<private-name>

urn:alert:locale:
- default (default)
- country.<ISO 3166-1 country code>
- private.<private-name>

Combination Rules:
-The categories are orthogonal. There can be at most one instance of
each alert-category in an
Alert-Info header.
 - The implementation is free to ignore any or all received Alert-Info URNs.

I don't think it is possible to achieve something similar using
response/status codes.
I am definitively opposed to replace the Alert-Info URNs with response
or status codes.

Laura

---

From: Laura Liess <[email-masked]>
Date: Sun, 9 May 2010 21:17:47 +0200

Gonzalo,

I agree with you that the last sentence is confusing.  We discussed a
lot about semantic vs. non-semantic . But now I think now
'non-semantic' is the wrong word. E.g. 'short' *is* a semantic name
not for the tone itself, but for a tone characteristica.

I would propose to change the last sentence in

'The Alert-Info URNs identifiers must be semantic names for renderings
or rendering characteristics. '   Or to remove it without replacement.

Opinions?

Thanks a lot
Laura

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 10 May 2010 09:53:53 +0200

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 07 May 2010 18:46
> To: Elwell, John; Gonzalo Camarillo
> Cc: DISPATCH
> Subject: RE: [dispatch] Alternative approach WAS (Re: Alert 
> Info Charter)
> 
> 
> 
> Do you mean it's less disruptive to put a status code into 
> Alert-Info, because people already use Alert-Info URI's for 
> the ringing playback process?  
[JRE] I mean it is less disruptive to use Alert-Info, because that is what people do today. But that implies using a URL/URN in Alert-Info, not a status code.

John

> 
> Or do you mean it's less disruptive to leave the Alert-Info 
> for what it was intended for: to indicate the URI of a 
> ringtone with no semantics, and instead put the status code 
> into something which is actually meant for status code?
> 
> And what do you mean by "disruptive"?  To me "disruptive" is 
> when interop or service issues happen due to the proposed 
> change, but maybe you mean something different?
> 
> -hadriel
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 10 May 2010 10:00:58 +0200

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 07 May 2010 19:47
> To: Elwell, John
> Cc: Paul Kyzivat; DISPATCH
[JRE] So, as Paul says, it is literal, not semantic. It has several different meanings in North America, and no meaning elsewhere.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 May 2010 09:47:48 -0400

> If you don't support it in the 181, 182 and 183, we'd have to explain why not.  Because the use-cases for call-forwarding and call-waiting are explicitly indicated in the charter, and afaik those *…

Clearly 100 should be excluded, as should 199.
So limiting to 180-183 seems reasonable.
AFAIK there is no common semantic formally associated with 18x in 
general, so limiting to that probably doesn't make sense.

> Personally I don't see any reason to restrict what methods it's allowed to be put into - it's always up to the receiver to decide if it wants to use it anyway.  It doesn't affect dialog state, so w…

This draft is mostly about *what* is rendered, not *when* it is rendered.

Expanding beyond INVITE and its responses is really broadening alerting 
to contexts where it hasn't been applicable in the past. Thats even true 
of broadening beyond 180 to 180-183, but is arguably a much "smaller" 
change.

It is true that the actual alerting is always discretionary, so 
broadening need not be disruptive on existing implementations, since 
they are free to ignore.

I guess for now I am inclined to be "conservative" and broaden to 
180-183 but not further. But I'm not strongly against broadening further.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 10 May 2010 12:56:08 -0400

> Sent: Monday, May 10, 2010 3:54 AM
> To: Hadriel Kaplan; Gonzalo Camarillo
> 
> [JRE] I mean it is less disruptive to use Alert-Info, because that is what
> people do today. But that implies using a URL/URN in Alert-Info, not a
> status code.

But lots of people use the response's status-line status-code instead, too.  Heck, there's plenty of endpoints that ignore Alert-Info altogether.  There is no single thing _all_ devices do today.  I assumed that was one of the problems we're trying to fix.

Don't get me wrong - I'm not opposed to using Alert-Info to carry an "alert-status", I'm just trying to understand how it relates to the status-codes in the SIP response status-line and a Reason header (if there is a Reason header).  

So far, whenever a "semantic" URN is used, it sounds like the same thing to me as a status-code.  It's only the "literal" ones that are not.  Today Alert-Info carries "literal" ones - whether by reference (HTTP URL) or by value (a "short-short" URN), it's still a literal: "play this tone".  What you guys are saying is "sometimes we don't want a literal, we want a call status/condition indication which the UA/proxy can treat itself".  Well, we already have those, so I'm trying to understand what the problem is with what we have.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 May 2010 13:12:30 -0400

Hadriel,

The way the A-I stuff has developed, there are now a number of 
properties that can be provided as distinct URNs, which are then 
combined to determine the actual alert. I guess the same could be done 
with reason codes, except that it would be a bit contrived to say that 
"locale:FR" was a "reason".

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 10 May 2010 13:33:37 -0400

> From: Laura Liess [mailto:[email-masked]]
> Sent: Sunday, May 09, 2010 12:44 PM
> To: Gonzalo Camarillo
> 

Right, it does not describe the call status, just a "ringtone".

> - We choosed to use URN so the receiving UA can querry URN-resolvers

Sounds good.

> code>.  How could you represent this as response/status codes?

They wouldn't, because that indications is NOT "semantic" to begin with.  It's literal.  What that URN is, is really a ringtone.  It happens to be that the ringtone is by reference, and the reference is a name rather than location. (ie, a URN vs. a URL)

It is not "semantic" because it carries no more "meaning" than any other Alert-Info.  It's just a defined name for mapping to a tone.  (I'm not exactly sure how a country-specific name could ever work in practice nor why it solves interop issues, but that's another topic :)

> [snipped ABNF]

I snipped the ABNF out, because I think that's really for the solution to figure out.  But I sure hope the final list ends up being smaller than that, if what you want is universal interoperability. :)

> I don't think it is possible to achieve something similar using

Of course not - status codes are meant to provide status indication of the call.  Like "the call is ringing" or "the call is queued" or "the call is being forwarded".  *That* has "semantic" or "meaning".  I thought that the charter was saying that's what you guys wanted in Alert-Info.  

But the more it's being explained, the more I think you don't really want that.  You just want a resource name as opposed to a resource locator.  So why confuse it any further with language about "semantic"??  If the IETF decides to define a URN for "short-short", that's just as meaningful or meaningless as "call-waiting" - because this is being used ONLY for ringtone names, not for call status.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 10 May 2010 13:41:12 -0400

> Sent: Monday, May 10, 2010 1:13 PM
> 
> Hadriel,
> 

I *think* the real answer to this is to stop using the word "semantic".  These URNs have no real meaning.  They're just names.  The names may have properties, like priority or locale or whatever, but at the end of the day if the name "short-short" gets standardized, it's just as meaningful or meaningless as the name "call-waiting".  That way you can ignore the overlap with status-codes in other fields.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 May 2010 14:06:24 -0400

> I *think* the real answer to this is to stop using the word "semantic".  These URNs have no real meaning.  They're just names.  The names may have properties, like priority or locale or whatever, b…

I'm perfectly happy to shed the "semantic" term in favor of something 
else. I already stated that I think this is a continuum rather than 
black/white. I think in general there is a preference for "more 
semantic, less literal", but that varies.

So I do think "call-waiting" is more meaningful and more productively 
translated to suit various needs than "short-short" is. For instance it 
is more easily translated into something meaningful to deaf people.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 10 May 2010 14:10:37 -0400

Out of curiosity - how do you see this country locale thing working?

The charter says "For example, a user from a given country may not be familiar with the tone used to indicate call waiting in another country."

So let's say I'm in the US and I call a number in France.  Do I get back "urn:alert:locale:country.fr"?  How is that useful to me?  Or do proxies in the path convert it to "urn:alert:locale:country.us"?

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 May 2010 14:28:55 -0400

> So let's say I'm in the US and I call a number in France.  Do I get back "urn:alert:locale:country.fr"?  How is that useful to me?  Or do proxies in the path convert it to "urn:alert:locale:country…

That's a policy thing. Perhaps the UAS includes 
urn:alert:locale:country.fr because they want you to know they are in 
France, and so that you will get the true French experience.

Then you local proxy, if you have one, may exert its own influence. (If 
so, hopefully it is because you configured it to do so.) It may override 
the locale with your default, or leave it alone, or whatever.

And then your UA may honor it if it knows how, or ignore it, or ...

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Mon, 10 May 2010 22:51:27 +0200

Hadriel,

please see inline.

> The charter says "For example, a user from a given country may not be familiar with the tone used to indicate call waiting in another country."

This sentence does not refer to the country locale, only to call
waiting where user A and user B  are in different environements. If A
calls B and UA B initiates call waiting, UA B wants A to get a call
waiting specific rendering instead of the normal ringing tone. If UA B
sends to UA A a URL for a specific tone known to UAB as "call waiting
tone", e.g. AT&T call waiting tone, A, being a DT customer may not
understand it, because DT uses another tone for call waiting. If it is
a URN instead of a URL, this URN can be resolved by the UA A in the DT
call waiting tone.

> So let's say I'm in the US and I call a number in France.  Do I get back "urn:alert:locale:country.fr"?  How is that useful to me?  Or do proxies in the path convert it to "urn:alert:locale:country…

The requirement for Alert-Info URNs for country ringing tones came
from Dean. My understanding was that it was needed in some other SDO
(3GPP2?). We had a lot of discussion on this issue during one of the
past IETF-meetings. It seams that in many cases in PSTN when A calls
B, A gets the B's country ringing tone. They want to have the same
with SIP using Alert-Info URN. Paul already described the handling.

Laura

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 11 May 2010 13:09:17 +0200

> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 10 May 2010 18:34
> To: Laura Liess; Gonzalo Camarillo
> Cc: DISPATCH
> Subject: Re: [dispatch] Status codes vs Alert-Info URNs WAS 
> (Re: Alert Info Charter)
> 
> 
> 
> They wouldn't, because that indications is NOT "semantic" to 
> begin with.  It's literal.  What that URN is, is really a 
> ringtone.  It happens to be that the ringtone is by 
> reference, and the reference is a name rather than location. 
> (ie, a URN vs. a URL)
> 
> It is not "semantic" because it carries no more "meaning" 
> than any other Alert-Info.  It's just a defined name for 
> mapping to a tone.  (I'm not exactly sure how a 
> country-specific name could ever work in practice nor why it 
> solves interop issues, but that's another topic :)
> 
> 
> >  - The implementation is free to ignore any or all received 
> Alert-Info
> > URNs.
> 
> I snipped the ABNF out, because I think that's really for the 
> solution to figure out.  But I sure hope the final list ends 
> up being smaller than that, if what you want is universal 
> interoperability. :)
> 
> 
> Of course not - status codes are meant to provide status 
> indication of the call.  Like "the call is ringing" or "the 
> call is queued" or "the call is being forwarded".  *That* has 
> "semantic" or "meaning".  I thought that the charter was 
> saying that's what you guys wanted in Alert-Info.  
> 
> But the more it's being explained, the more I think you don't 
> really want that.  You just want a resource name as opposed 
> to a resource locator.  So why confuse it any further with 
> language about "semantic"??  If the IETF decides to define a 
> URN for "short-short", that's just as meaningful or 
> meaningless as "call-waiting" - because this is being used 
> ONLY for ringtone names, not for call status.
[JRE] I think "call-waiting" is a lot more meaningful than "short-short". The former can be rendered (audibly or otherwise) in a way consistent with the user interface, with a good chance that a user familiar with that user interface will understand that the ringback tone means the call is waiting. On the other hand "short-short" would presumably result in two short burst of tone of some arbitrary duration, and what am I, the user, to make of that? A user in a particular locale where two short bursts of tone are generally understood to have a particular meaning might understand, but a user outside that locale would not.

John

---

From: Laura Liess <[email-masked]>
Date: Tue, 11 May 2010 22:35:51 +0200

Gonzalo,

I looked again at the mails and it seems to me that there is some
misunderstanding here. 

The identifier in the Alert-Info header contains information about what the
receiving UA should render to the user. We have two types of identifiers
which can be used in the Alert-Info-header: 

1) URIs which refer to a specific rendering (tone,text...). In this case the
specific rendering is selected by the sending UA and played to the receiving
UA's user. This is covered by the RFC 3261.  
2) Names, semantic or non-semantic, are not covered by the RFC 3261. They
shouldbe covered by the Alert-Info URN. Using names instead of references
allows the receiving UA (or it's service provider) to select a specific
rendering which is appropriate for its own user. Also in the "non-semantic"
case we are still dealing with names, e.g. urn:alert:duration:short and this
is not covered by the RFC 3261. 

I think the text in the charter "... to exchange this type of alerting
information in a semantic way." (first sentence in third paragraph) is
confusing. I propose small changes to this paragraph:

" These issues can be resolved with a mechanism for user agents to
exchange rendering names instead of references to a particular renderings.
Rendering names can be resolved by the receiving UA according to local
rules. For example, a user agent client instructed to inform its user about
a call waiting service can use the personalized renderings (tones or text)
that were previously configured by the user or the service provider's
renderings."  

The Alert-Info URN being about names, not only about semantic names, I am
not sure if the semantic/non-semantic issue belongs in the charter or in the
requirements. If it should be in the charter, what about replacing the last
sentence" Whenever possible,
the Alert-Info URNs identifiers should be semantic." by the following text:
 " When Alert-Info URNs are bound to a semantic supposed to be known in
general, e.g. call waiting or French ringback tone, the name must reflect
this semantic. 
The Alert-Info URN scheme also should allow non-semantic names, e.g. for
ringing tones used in certain environments or when tones from legacy
protocols must be translated to SIP at the edge of a network."

Thanks a lot,
Laura 

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im
> Auftrag von Gonzalo Camarillo
> Gesendet: Samstag, 8. Mai 2010 12:49
> An: Hadriel Kaplan
> Cc: DISPATCH
> Betreff: [dispatch] Status codes vs Alert-Info URNs WAS (Re: Alert Info
> Charter)
> 
> Hi,
> 
> > Right, what you want is the device generating the response indicates
> the condition, and the UAC receiving the response generates a locally-
> mapped tone for that condition.  I get that, and it makes a lot of sense
> to me.
> >
> > So ISTM what we want is for the device generating the SIP response to
> indicate a status code, which the UAC can map to whatever tones it wants.
> >
> > The funny thing is we already have a way to do that. Two ways, in fact:
> the message's status-line status-code number, and the Reason header
> value.
> >
> > I'm not actually proposing the SIP message response status-code be
> expanded for this (both because of interop issues and because there
> aren't enough digits in 18x to accommodate all conditions).  But I think
> the Reason header isn't a bad choice.
> >
> >
> > 1) You can't add more URN values later, because you don't know if the
> UAC understands the new URN.  Compare this to a status-code model, where
> you can treat a new 187 code as a 180 if you don't understand the 187.
> (although I suppose you could actually just make the URN a number format,
> or define the format to indicate a default as well, so you can get this
> property)
> >
> > 2) An Alert-Info header can only appear in 180 responses, and not 182,
> 183, etc.  I suppose 3261 could be extended though to include it in other
> responses, though.
> >
> > 3) You can't deploy this new URN scheme in a backwards-compatible
> fashion in practice, unless you have an indicator in the request which
> states the UAC supports it.  If you have such an indicator, you might as
> well put this in a Reason header instead and not have two different
> headers to indicate the same status.  And as it turns out, if you use the
> Reason header then I don't think you need an indicator in the request to
> begin with.
> >
> >
> > If there are real interop problems with Alert-Info, and people really
> want to fix them, and it's not much more work... then yes I think it
> would.  I'm not suggesting a lot of additional work, am I?
> >
> > I don't think using the Reason header alone instead of both is such a
> big change.  Seems simpler to me, in fact.
> >
> > -hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 12 May 2010 08:21:17 +0200

This works for me. I think we have had enough charter-bashing and really should get on and form the group and work on refining the requirements in Laura's I-D.

John 

> Sent: 11 May 2010 21:36
> To: 'Gonzalo Camarillo'; [email-masked]
> Cc: 'Paul Kyzivat'; 'Hadriel Kaplan'; Elwell, John; 'Liess Laura'
> Subject: Alert Info Charter
> 
> Gonzalo,
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 May 2010 07:09:49 -0600

I'm a bit concerned about the discussion of the call waiting tones. Assuming we had a "call waiting tone" URN we could put in Alert-Info, how would this work? when would it be used - I'm wondering what message in what dialog would cary it?

On May 7, 2010, at 4:50 AM, Gonzalo Camarillo wrote:

> <alert-info-charter-proposal.txt>_______________________________________________
> dispatch mailing list
> [email-masked]

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 May 2010 10:21:31 -0400

> I'm a bit concerned about the discussion of the call waiting tones. Assuming we had a "call waiting tone" URN we could put in Alert-Info, how would this work? when would it be used - I'm wondering…

My understanding is that this would be used as the A-I in a 180 response 
to the "second" caller, thus indicating something that some people seem 
to find interesting.

(Personally, I don't get the value of this. The fact that the called 
party is on another call on a phone that has the "call waiting" feature 
doesn't really tell me whether I should wait longer, or hang up sooner 
than if I didn't get it. And I don't know how it differs from a case 
where the callee is on a different "line" on a business phone, or on an 
entirely different phone - cases where I gather the call-waiting alert 
probably would not be used.)

Nevertheless, people seem to like this, and who am I to say they 
shouldn't have it?

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 May 2010 10:41:40 -0400

+1.

> Sent: Wednesday, May 12, 2010 2:21 AM
> To: Laura Liess; 'Gonzalo Camarillo'; [email-masked]
> 
> This works for me. I think we have had enough charter-bashing and really
> should get on and form the group and work on refining the requirements in
> Laura's I-D.
> 
> John
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 May 2010 10:57:07 -0400

Personally I would really like to know if the person I am calling is on another call and my call is in a call-waiting state.  Because that tells me it's more likely the person is there, and I likely *will* wait longer if my call is important, or hang up if it's not and I don't want to interrupt them.

-hadriel
(Technically it should return a 182 to tell me that anyway, but I'm not opening that can of worms again ;)

> Sent: Wednesday, May 12, 2010 10:22 AM
> 
> Cullen Jennings wrote:
> > I'm a bit concerned about the discussion of the call waiting tones.
> Assuming we had a "call waiting tone" URN we could put in Alert-Info, how
> would this work? when would it be used - I'm wondering what message in
> what dialog would cary it?
>