Subject: [Sip] Alert-Info: header

From: "Sean Olson (EUS)" <[email-masked]>
Date: Tue, 16 Oct 2001 13:10:58 -0500

Hi,

I was wondering if it would be possible to make 
Alert-Info: a general header instead of a request
header. In particular, it would be nice to be
able to use the Alert-Info: header to carry an
appropriate URL in a 180 Ringing response.
The change I am proposing is:

   The Alert-Info header field indicates that the content indicated in
   the URLs should be rendered instead of ring tone or ringback tone. 
   A user SHOULD be able to disable this feature selectively to prevent
   unauthorized disruptions. When present in a request, the Alert-Info
   header specifies an alternative ring tone. When present in a response,
   the Alert-Info header specifies an alternative ringback tone.

        Alert-Info     =  "Alert-Info" ":" # ( "<" URI ">" *( ";" generic-param ))
        generic-param  =  token [ "=" ( token | host | quoted-string ) ]

   Example:
   Alert-Info: <http://wwww.example.com/sounds/moo.wav>

Comments?
Sean Olson
Ericsson Inc.

---

From: Alan Johnston <[email-masked]>
Date: Tue, 16 Oct 2001 14:01:50 -0500

Sean,

I have always assumed that the Alert-Info header being listed as a
Request header was an error - it only makes sense for it to be used as
you describe - in a response (180 Ringing, to be specific, since this is
the only SIP response that tells the UAC to play ringback tone to the
caller).

This then allows a UAS to deliver a customizable ringback tone without
resorting to early media.

The use of Alert-Info in an INVITE never made any sense to me.  There
would be a delay in the UAS from the receipt of the INVITE until it had
fetched the alert sound.  Then, assuming that the UAS played the sound,
how would the user even know that his SIP phone or client was ringing?

Used the other way around, the header does not introduce a delay in the
session setup (a delay of audible ringback while the UAC fetches the
ringback sound does not delay the UAS answering), and the caller just
hears a different sound besides ringing, something perfectly possible
with early media, but handled in a much more efficient way using this
header.

This is how this header will be described in bis-05, so let me know if I
am totally off base here.

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

>    Alert-Info: <http://wwww.example.com/sounds/moo.wav>

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 16 Oct 2001 15:44:25 -0400

> am totally off base here.

It needs to remain an option for INVITE's
so that a proxy can indicate 
distinctive/priority alerting to its user.

I am fine with its usage in other 
requests and response.  It could help a UAS 
to indicate that it can no longer apply
remote ringback; thus please apply it 
locally.  However if the header is present 
anywhere except the first INVITE, parameters 
or documented text would need to describe 
its relationship to current media streams.
For instance, listen/render until media
received.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 16 Oct 2001 16:05:30 -0400

> resorting to early media.

This is for *ring* tone, not *ringback* tone.

> how would the user even know that his SIP phone or client was ringing?

The delay would often be minuscule (a second or less), in particular if
the Alert-Info is inserted by the local proxy on the receiving side
(e.g., to do caller-dependent ring tones). 

I don't understand the last question. If the URL is sound, the callee
would hear it...

> am totally off base here.

Yes, unfortunately.

> "Sean Olson (EUS)" wrote:
p

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Alan Johnston <[email-masked]>
Date: Tue, 16 Oct 2001 17:50:45 -0500

Henning,

So are you opposed to the use of this header as Sean describes it?    The use
of the header for personalized ringback without resorting to early media is a
good idea.

As for its use in distinctive ringing, we'll just need a note to say that the
use of this header requires the strongest security and trust relationship
otherwise it will be the cause of the worst kind of SPAM.

Thanks,
Alan.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 16 Oct 2001 22:51:28 -0400

> of the header for personalized ringback without resorting to early media is a

No, I'm not opposed to this - sorry if my message came across as such.
It's indeed a very useful feature (I vaguely remember that this was
discussed when this topic came up the first time around).

> otherwise it will be the cause of the worst kind of SPAM.

Yes, although the potential for mischief seems to exist in both
directions, to different degrees. 

One potential easy check is for the user to only allow local ring tone
URLs (or URLs from the provider's domain); this prevents the spam case
you mention, but still provides the distinctive ringing service. Indeed,
if the URL path name is a random string, it's pretty difficult for an
outsider to guess and invoke without the callee's consent. Not sure
whether it's worth mentioning this in detail.