Subject: [dispatch] Charter proposal: SIP Alert-Info URN

From: <[email-masked]>
Date: Mon, 21 Sep 2009 19:45:10 +0200

Hello,

Please find below our charter proposal for the SIP Alert-Info URN.

Comments are very welcome!

Kind regards,
Laura 

The SIP Alert-Info URN (SAIU) working group is chartered to define a new
URN-scheme which allows SIP to convey a particular alert indication
using a name instead of a referenced URI. The Alert-Info URN solves
interoperability problems which we encounter today around the use of the
Alert-Info header field for services as call waiting, call forwarding,
blind transfer, automatic callback, call hold or emergency announcements
sent over PBX systems.    

RFC 3261 allows a UAS or proxy to provide a specific ring-/ringback-tone
as a reference (e.g. HTTP URI) which can be played to the user in the
Alert-Info header. 
This mechanism does not ensure interoperability on the semantic level
when there is no common understanding of the referenced content
(different countries, hearing impaired) or when the user has his own
tones configured in the end device. There are a variety of URI
conventions and proprietary Alert-Info header field parameters to
provide this today, all of which are non-interoperable.  A standardized
set of Alert-Info URNs will increase SIP interoperability for this
header field by replacing proprietary conventions.

The group will produce:

- A specification which describes the problem statement, the Alert-Info
URN-scheme and defines the specific Alert-Info URNs identifiers to solve
the known service interoperability problems. 

Goals and Milestones
====================

Dec 10 - Alert-Info URN specification to IESG (PS)

---

From: Dean Willis <[email-masked]>
Date: Mon, 21 Sep 2009 22:18:15 -0500

> the known service interoperability problems.

I think this is a very good idea for a short-lived, tightly-scoped  
working group, and I think the problem is valid and needs to be solved  
(indeed, every time one of the mobile standards groups tried to do  
something silly with ringtones, I suggested they look at alert-info).

I'd like the proposed charter text to g into a little more depth about  
the "known service interoperability problems." Where are these being  
drawn from? Will the WG just reference an external spec for a list, or  
do we need to invent our own list and come to consensus on it?

--
Dean

---

From: <[email-masked]>
Date: Tue, 22 Sep 2009 16:12:14 +0200

Dean,

Thank you for supporting the work. Please see answers in-line. 

> drawn from?

The cases I know of are mainly the use-cases for which indications and
sub-indications have been defined in 
Sections 3 and 4. of
http://www.ietf.org/id/draft-alexeitsev-bliss-alert-info-urns-02.txt .

- For the call waiting supplementary service provided by carriers, there
is a need for the callee's proxy informs the caller that the call is
waiting. The callee's proxy must provide this information at a semantic
to the caller's end device. A URI will not do it for different
countries, hearing impaired and so on. 
 
- All other use cases in the draft came from Alan's implementation
experience at Avaya and interoperability issues around the use of the 
Alert-Info header field when not-using an external ring file. Here is
Alan's text, which is not in the current version of the draft:      
 
For example, consider the PBX special ringtone for an external (to the
PBX) 
caller.  Different vendors use different approaches such as:

   Alert-Info: <file://ring.pcm>;alert=normal  where ring.pcm is a dummy

file

or:

   Alert-Info: <file://normal.ring.pcm>

or:

   Alert-Info: <sip:[email-masked]>

As a result, Alert-Info currently only works when the same vendor 
provides proxy and UA, as only then is the same "fake" proprietary URI 
convention is used.

Also draft-ietf-bliss-shared-appearances needs to specify a default
ringtone when using appearance Alert-Info parameter.  

> Will the WG just reference an external spec for a 
> list, or  

I intend to include the text above into the next version of the draft.
Maybe a separate section in the draft on the problem statement and use
cases would make sense. 

My understanding from your mail way that you know of other use cases
from other mobile standards group.  Is that correct? If yes, does it
make sense to consider them here? The syntax is open so people can add
new labels. 

In his message
http://www.ietf.org/mail-archive/web/bliss/current/msg01020.html   Adam
raised the issue of the tones defined in TIA/EIA-41-D and 3GPP2 A.S0014.
Personally, I don't have any experience with them. But, as John pointed
out in http://www.ietf.org/mail-archive/web/bliss/current/msg01025.html,
we should try to define names that reflect the meaning, rather than the
representation, of a tone.  I don't know anything about the meaning of
Short-Short2. For my feeling,  this are quite US specific and for my
feeling URIs could be used in this case. 

Thanks a lot
Laura

---

From: Dean Willis <[email-masked]>
Date: Tue, 22 Sep 2009 13:17:55 -0500

> make sense to consider them here? The syntax is open so people can add

It's been a while but I may remember conversations in 3GPP, 3GPP2, and  
OMA.

The ring-back for national standard ringers has always seemed like a a  
good application of URN in alert-info. In other words, if you call  
somebody in France, you might get back a 180 with an alert-info with a  
URN that basically means "France standard ring tone".

I vaguely remember discussion about URN-based alert-info for "public  
alert" calls, like storm warnings and evacuation orders.

There's also been discussion of use in forward-ring cases, as in alert- 
info in an INVITE request.

See http://www.ietf.org/mail-archive/web/sip/current/msg01385.html.  
This suggests several additional cases that may need to be considered,  
probably national variants of distinctive-ring indicators.

While we probably don't want to charter every possible use case, it  
would probably be appropriate to consider any published use cases from  
the mobile groups. So perhaps part of the task of the WG would be to  
review the extant standards and see if any of them should be added to  
the initial registry.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Sep 2009 21:11:42 -0400

I agree with Dean here.

The example of the "France standard ring tone" is a case where you have 
a URN that identifies some specific audio signal, but in a semantic way 
rather than by providing an encoding of it. This can be useful for a 
variety of reasons:
- its not biased towards a particular representation,
   which might not be suitable for all devices
- its convenient when you want to store the actual encoding
   locally rather than fetching it
- because it is specified "by name" rather than "by value",
   its easier to make policy decisions about whether to use it or not.
- it facilitates translation for the hearing impaired

	Thanks,
	Paul

Dean Willis wrote:
> It's been a while but I may remember conversations in 3GPP, 3GPP2, and OMA.
> 
> There's also been discussion of use in forward-ring cases, as in 
> alert-info in an INVITE request.
> 
> See http://www.ietf.org/mail-archive/web/sip/current/msg01385.html. This 
> suggests several additional cases that may need to be considered, 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>