Subject: [dispatch] Alert Info Charter

From: <[email-masked]>
Date: Tue, 11 May 2010 23:17:02 +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,
> 
> 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.
> 
> 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.
> 
> 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?
> 
> 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
> 
> 
> On 07/05/2010 7:42 PM, Hadriel Kaplan wrote:
> >
> >> -----Original Message-----
> >> From: Alan Johnston [mailto:[email-masked]]
> >> Sent: Friday, May 07, 2010 11:28 AM
> >> To: Hadriel Kaplan
> >>
> >> 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.
> >
> > 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.
> >
> >
> >> 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.
> >
> > 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
> >> it get deployed?
> >
> > 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
> > _______________________________________________
> > dispatch mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: <[email-masked]>
Date: Wed, 12 May 2010 16:17:10 +0200

Cullen,

The call waiting Alert Info URN is carried in 180 Ringing. Alice
called Bob. Bob is already in a phone call. Bob's UA does not respond
with busy ( as it would do without the call waiting feature), but
tells Bob (e.g. by a repeated acustic signal) that a second call is
waiting and sends to Alice's UA a 180 Ringing with an Alert-Info URN.
Alice gets a special ringback tone which tells her that Bob is in
another phone call but was informed about the new call. Bob may decide
to terminate or put on hold the first call and talk to Alice.

Thanks,
Laura

2010/5/12 Cullen Jennings <[email-masked]>:
>
> 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:
>
>> 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?
<alert-info-charter-proposal.txt>_______________________________________
________
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
>