Subject: RE: [Sip] Alert-Info: header

From: "Sean Olson (EUS)" <[email-masked]>
Date: Tue, 16 Oct 2001 14:23:43 -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.

Yes, this is the primary feature I am looking for. However, it is
not the only feature I would like to support with this header.
For this reason, I think Alert-Info should remain a general header.
I will elaborate further below.

>
>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?

This is fairly confusing if you assume that the Alert-Info: can
only apply to ring(back) tone. If you broaden the header to mean
"this is information to be rendered to the end user during the
alerting period", then things start to make more sense. For example,
if I send an http: URL in the Alert-Info: header in the INVITE, this
could point to a thumbnail icon which provides an enhanced caller ID
feature. Or an http: URL could point to .wav file that could be
interpreted as an alternative to ring tone. Naturally for a SIP device
to make this meaningful to the end user, it has to be intelligent about
how it renders this media and flexible in its notion of "ringing". I would
expect that a device that supported this feature would first "alert" the
user using a default ring tone coupled with an appropriate message on a
LCD display. When the resource identified by the Alert-Info: header is
retrieved, the device should use the MIME type and some reasonable heuristics
to determine how to render and/or mix the media with the default "ring tone"
at the device.

>
>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.

Yes, this direction is more inline with what we have today. I would
still like to support the reverse direction as well. Leave it to the
device to figure out what it wants to do.  I'm certain there will
be service features in the future which will want to use Alert-Info
in both directions.

>
>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]

Thanks for the quick response. I hope my comments make sense.
Sean

>
>"Sean Olson (EUS)" wrote:
>
>>
>>
>> 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: [email-masked]
Date: Wed, 17 Oct 2001 16:05:23 -0600

Henning has a point that it is unambiguous.  If it is in a request it is
obviously for ring played to the callee (typically out loud on a speaker),
if it is in a response it is for ringback played to the caller (typically on
a handset or headset).  My opinion has been swayed provided it is defined in
the spec.  Less headers is probabally a good thing to keep SIP simple.
 
John

-----Original Message-----
From: Mart Nurmet [mailto:[email-masked]]
Sent: Wednesday, October 17, 2001 2:23 PM
To: Sean Olson (EUS)
Cc: [email-masked]
Subject: Re: [Sip] Alert-Info: header

Sean et all:
 
This does not seem to have that much consensus.  John's point would be
better served.    
 
-Mart

----- Original Message ----- 
From: Sean  <mailto:[email-masked]> Olson (EUS) 
To: [email-masked]' <mailto:[email-masked]'>  ;
[email-masked] <mailto:[email-masked]>  ;
[email-masked] <mailto:[email-masked]>  
Cc: [email-masked] <mailto:[email-masked]>  
Sent: Wednesday, October 17, 2001 9:24 AM
Subject: RE: [Sip] Alert-Info: header

This is a point well taken. I wanted to generalize the 
header to allow for a variety of cool new features. If 
extending this header is not an option, could we propose 
a new header for this purpose? (preferably a general header). 
I personally don't understand the problem with using this 
header for "ringback" if you are allowing it for "ring tone". 

With regards to spam, you must be very careful in both directions. 
But then again, you must be very careful about accepting an INVITE 
as well which has a larger potential for spam. (not to mention 
MESSAGE) 

Sean Olson 
Ericsson Inc. 

> I think using the header for both purposes is overloading it. 
> The idea is 
>good, but a different header should be used.  Good point on 
>the spam!  That 
>might wind up killing the intended functionality from getting 
>implemented. 
> 
>John Hearty 
>Level3 
> 
>-----Original Message----- 
>From: Alan Johnston [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>Sent: Tuesday, October 16, 2001 4:51 PM 
>To: Henning G. Schulzrinne 
>Cc: Sean Olson (EUS); [email-masked]' 
>Subject: Re: [Sip] Alert-Info: header 
> 
> 
>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. 
> 
>"Henning G. Schulzrinne" wrote: 
> 
>> Alan Johnston wrote: 
>> > 
>> > Sean, 
>> > 
>> This is for *ring* tone, not *ringback* tone. 
>> 
>> > 
>> 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... 
>> 
>> > This is how this header will be described in bis-05, so 
>let me know if I 
>> Yes, unfortunately. 
>> p 
>> -- 
>> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
<http://www.cs.columbia.edu/~hgs>  
>> 
>> _______________________________________________ 
>> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
<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 
> 
> 
>_______________________________________________ 
>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
<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: "Sean Olson (EUS)" <[email-masked]>
Date: Mon, 22 Oct 2001 09:17:09 -0500

>>feature. 
>I think this is what Call-Info was meant to do. In fact, an 
>"icon" parameter
>has already been defined for this purpose exactly. 

Sorry, bad example. The point was to illustrate that there
may be other useful information to render to the end user
in the alerting phase. In particular, I want to stress that
audio is not the only option here.

>I, for one, had also thought that Alert-Info was meant as a 
>response header.
>I don't see much use in the request for ringtone, since I 
>would expect that
>ringtone is primarily going to be something the called party 
>selects, not
>the caller.

I don't see the harm in allowing either. I don't expect to
mandate implementations to honor the Alert-Info: header. This
is strictly optional behaviour. I just don't want some overzealous
proxy in the middle discarding a request just because it has an
Alert-Info: header. (I wish this were a hypothetical concern)

>Whether its a new header, or a different header, the ability 
>for the caller
>to specify content that the callee should render, play, or 
>whatever, is at
>the same time both a powerful feature and a very dangerous 
>one.

Of course. I hope everyone realizes the same about an INVITE.
I'm not looking to add another capability to the Microsoft
Virus Developers Kit. Given a reasonable amount of caution, I think
this can be a useful header, in both directions.

>I think its
>important that the specification more clearly discuss the 
>security issues
>here, and recommend that these headers only be followed for 
>calls that can
>be authenticated. That doesn't mean that the called party needs to
>authenticate the caller; one can imagine a system in a call 
>center where the
>called party is an agent, and the agent system inserts these 
>headers after
>identifying the caller through some means (IVR, or whatever). 
>So, as long as
>the call comes from the agent system, the agent is safe in 
>rendering these
>headers.

Sure. The Call-Info: and Error-Info: headers should receive
similar attention.

>
>Furthermore, there is a tradeoff in how general you make this 
>header. The
>reason we made Alert-Info and Call-Info separate things is 
>that we want the
>headers to be as precise as possible about what the purpose of 
>the content
>is. This ensures that the UA can treat it in an appropriate 
>fashion for its
>UI, and it also helps the UA perform appropriate filtering. 
>For example, if
>a UA gets a request with a Call-Info that contains an http URL with an
>"icon" param, but the fetched content is an executable or 
>VBscript, its a
>safe bet its to be discarded.

Understood. 

>
>-Jonathan R.
>
>---
>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>[email-masked]                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com

/sean