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

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 21 Oct 2001 18:23:44 -0400

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Tuesday, October 16, 2001 3:24 PM
To: 'Alan Johnston'
Cc: [email-masked]'
Subject: RE: [Sip] Alert-Info: header

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

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

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. 

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

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.

-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

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Sun, 21 Oct 2001 23:10:37 -0400

> ringtone is primarily going to be something the called party selects, not

This is at variance with the discussion that I remember when we first
discussed this, where this came up in the context of distinctive
ringing. Yes, the called party should select the ring tone, but the idea
is that the callee's proxy inserts this header, based on some database
lookup, script or what have you. This seems like a pretty good
implementation to me, as it avoids end systems having to deal with
maintaining a callee mapping table, while still allowing the end system
flexibility in whether to observe the header or not. The callee's proxy
server can then also override any choices made by the caller, or if
sufficiently trusted, use that choice.

This seems like the right separation of policy from mechanism, i.e., any
number of policies can be supported, without encoding them into headers.

Proxy-signed headers are clearly helpful here.

> the call comes from the agent system, the agent is safe in rendering these

Or a proxy, for that matter. (I can't tell if you mean B2BUA when you
say "agent system").

> safe bet its to be discarded.

Not if the application is called Inhear :-)