Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-answeralert-01)

[Paul Kyzivat <[e-mail]>]

Dean - Inline.

Dean Willis wrote:
> 
> On Sep 13, 2005, at 4:59 PM, MARJOU Xavier RD-MAPS-LAN wrote:
> 
>> Hi,
>>
>> When reading Req-5 with "some sorts of emergency session", I  understand
>> that an "emergency mass alert" is a candidate use-case.
>>
>> Thus, in section 6, I suggest a new value for the Alert-Mode header
>> field: "Amplified" so that as many people as possible are alerted  (e.g.
>> an amplified ring tone). In this case, a UAS could also decide to
>> increase the volume of audio.
>>
> 
> I've been thinking about this, and working on some client specs, and  
> I'm beginning to think that maybe the Alert-Info header might offer a  
> better way to do this, as well as do a number of other things  
> (including possibly the alert-mode function of the draft in  question). 
> Maybe somebody already suggested this, and it just now  percolated 
> through my brain, so I apologize if I'm failing to credit  this idea 
> correctly.

I think I may have mentioned this somewhere, sometime. At least I have 
also been thinking about it, and talking about it in fora where you 
weren't present.

> The problem with Alert-Info is that it's almost completely  unspecified. 
> As I read it, 3261 says it takes a URL as a value,  without providing 
> any way to negotiate (or confirm) the range of URLs  that might be 
> meaningful to the UAS. Not good.

The lack of negotiation capability is somewhat of a problem, though the 
ability to negotiate any behavior of the callee at this stage of the 
call is dubious. (Potentially a UAS could return an error for an 
unrecognized Alert-Info, but that would then yield a HERFP problem.)

> Some implementations (aka Cisco) use totally bogus integers or  
> cadence-maps or other stuff in the Alert-Info header.  Also not good.
> 
> What if we were to define a series of URNs that refer to standardized  
> alert-behaviors? We could have registered URNS for:
> 
> 1) Normal alert
> 2) Distinctive alert (possibly indexed by an integer, for different  
> distinctive alerts)
> 3) Null alert (which provides for the alert-mode behavior from this  draft)
> 4) One or more types of request-encoded alerts, like the Cisco  
> integers, where the encoded value is carried as a URN parameter set
> 5) Emergency alert

I think URNs have a place here.

> We could lump these into one URN set (namespace?) and associate a SIP  
> OPTION tag with support for the entire set of alerting behaviors. I  
> think of this as "basic alerting options", and we could bound up the  
> whole set in one I-D.

In general, alerting is normally considered to ultimately be up to the 
one doing the alerting. In most cases I would expect any indication by 
the caller to be advisory. E.g. the callee may not trust the caller, 
and/or may want to use some kind of distinctive alerting it chooses to 
indicate who is calling. Ultimately, both the caller and the callee may 
want to choose, and somebody has to win.

The question then is: if the OPTION tag is there, should the request be 
rejected if the Alert-Info value isn't understood, or if it won't be 
honored?

This is further complicated because I think there will be many cases 
where intermediaries may want to insert an Alert-Info. For instance, I 
know of one proposal for a proxy acting on behalf of the callee to 
implement distinctive alerting by inserting an Alert-Info header with a 
value chosen according to who the caller is. Then the UAS only has to 
honor the Alert-Info, not figure out the circumstances when distinctive 
alerting should apply. I guess the usage for PoC would be simiar to 
this. In some sense things are simpler if the Alert-Info is inserted by 
an agent operating on behalf of the UAS, because it can perhaps be 
assumed to know what the UAS is capable of processing.

> Thus, an INVITE request might carry something like:
> 
> Alert-Info: urn:org.ietf.sip.alert.basic//emergency
> Require: alert.basic
> 
> or maybe:
> 
> Alert-Info: urn:org.ietf.sip.alert.basic//distinct.1
> 
> or
> 
> Alert-Info: urn:org.ietf.sip.alert.basic//cadence?3,1,3,5
> 
> 
> Then for "downloaded" alert sets (aka HTTP or other URLS) we could  
> potentially have additional URN sets, perhaps by URL type, or by  
> payload type, or some other combination. This could provide subject  
> material for additional IDs.

I could pick at the details above, but now is not the time. Lets get the 
basic concepts worked out first.

I'm worried about conflicts between the desires of the caller and 
callee, and also about the HERFP problem if we use Require. I think 
these can be sidestepped IF we assume the caller never inserts mandatory 
Alert-Info headers, and that A-I is generally only inserted by an agent 
of the callee that can have been provisioned to be aware of the UAS 
capabilities.

	Paul

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