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

From: Dean Willis <[email-masked]>
Date: Wed, 26 Oct 2005 22:20:57 -0500

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.

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.

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

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.

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.

--
Dean

_______________________________________________
Sip mailing list  https://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: [email-masked]
Date: Thu, 27 Oct 2005 08:16:03 -0400

I agree wholeheartedly with Dean. A URL is a nice, generic way to specify
an alert signal, but unless you know what sort of URLs your client
understands, it's not very useful. Some clients might understand a URL that
returns an audio file, but for other clients that might be totally useless.
A set of standardized URNs that includes the various alerting patterns
typically used in traditional telephony applications would be of great
interest to me and my work. This would include the standard North American
alerting patterns generically identified by the integers one through five,
perhaps expressed more generically in some manner. And I imagine that there
are other forms of alerting that could be accepted as standard. In my
current work, we have had to invent a notation for this, and I've been
suggesting that we think about promoting a standard of some sort.

Dave Robbins
Verizon Laboratories
40 Sylvan Rd.
Waltham, MA 02451-1128
781 466 4188

             "Dean Willis"                                                 
             <dean.willis@soft                                             
             armor.com>                                                 To 
             Sent by:                  "MARJOU Xavier RD-MAPS-LAN"         
             sip-bounces@ietf.         <[email-masked]>   
             org                                                        cc 
                                       [email-masked], [email-masked]         
                                                                   Subject 
             10/26/2005 11:20          [Sip] Alert-Info Idea (was Re:      
             PM                        Comment on                          
                                       draft-willis-sip-answeralert-01)    

                                                                           

1) Normal alert

or maybe:

or

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Oct 2005 09:28:28 -0400

Dean - Inline.

Dean Willis wrote:
>> When reading Req-5 with "some sorts of emergency session", I  understand
>> field: "Amplified" so that as many people as possible are alerted  (e.g.
> (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.)

> 3) Null alert (which provides for the alert-mode behavior from this  draft)

I think URNs have a place here.

> think of this as "basic alerting options", and we could bound up the  

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.

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Oct 2005 09:54:08 -0400

I think it would be good if there was a set of URNs that are defined 
*semantically* rather than defining precisely what should be rendered. 
These would be of much broader applicability than those that specify 
particular audio waveforms, etc., because they could be rendered in a 
variety of ways: audio, video, tactile, in different languages, etc.

However there is probably value in having ones that have specific 
renderings as well.

There could also be scenarios where one entity (e.g. representing the 
caller) inserts a URN that is semantic in nature, and another entity 
(e.g. representing the callee) replaces that with a different URN (or 
URI) that identifies a specific rendering that is consistent with the 
intended semantic, the capabilities of the UAS, and the desires of the 
UAS in terms of culturally specific values.

	Paul

---

From: [email-masked]
Date: Thu, 27 Oct 2005 10:07:51 -0400

Agreed.

Defining URNs "semantically" is what I had in mind. In an application
carried over from the PSTN, distinctive alerting takes one of two different
forms, depending upon whether it is rendered as power ringing or as a
call-waiting alert tone. I would want to use a single URN, which the UAS
would render in whatever way is appropriate for the current state of the
device. Other semantic forms are surely useful as well.

I can also see the potential value in having a URN that carries a specific
rendering.

Dave Robbins
Verizon Laboratories
40 Sylvan Rd.
Waltham, MA 02451-1128
781 466 4188

             "Paul Kyzivat"                                                
             <[email-masked]                                             
             om>                                                        To 
                                       Dave C.                             
             10/27/2005 09:54          Robbins/EMPL/MA/Verizon@VZNotes     
             AM                                                         cc 
                                       "Dean Willis"                       
                                       <[email-masked]>,        
                                       [email-masked], "MARJOU Xavier        
                                       RD-MAPS-LAN"                        
                                       <[email-masked]>,  
                                       [email-masked], [email-masked] 
                                                                   Subject 
                                       Re: [Sip] Alert-Info Idea (was Re:  
                                       Comment on                          
                                       draft-willis-sip-answeralert-01)    

                                                                           

             Paul

>              armor.com>
To

>              org
cc

Subject

---

From: Dean Willis <[email-masked]>
Date: Thu, 27 Oct 2005 22:36:56 -0500

On Oct 27, 2005, at 8:28 AM, Paul Kyzivat wrote:
>
>
>> 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?
>

SIP is actually very clear here -- accepting the request with a  
Requires: option tag says only that you understand the extension, not  
that you are committing to doing what it says for this call.

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

Actually, I think that makes it not more complicated, but less. You  
act on the Alert-Info only to the extent that you trust the sender  
and forwarding elements to use it correctly -- kind of like not  
retrieving HTML links inside an unauthenticated email.  I think this  
can be wrapped up with some tight security considerations.

In an IMS-type environment, it would be reasonable to require the S- 
CSCF to strip off any foreign Alert-Info that it doesn't have reason  
to include. We can't say that in IETF, however, as we might well not  
have an S-CSCF.

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

Well, there's no way to tell WHO inserted an Alert-Info, is there?

So, what happens if we have an Alert-Info extension set, with a  
corresponding Require? If the proxy forks it (I LOATHE forking),  
there's a chance that the request might be delivered to a node that  
doesn't grok the extension, and the resulting 4xx response might be  
HERFP-eaten by the proxy if it gets a "better" response from some  
other branch.

So what?

Either a "better" response goes back to the UAC (perhaps from a  
branch that understands the require),  or it doesn't. Big loss. All  
that happens is that we don't get an error response back from a node  
we didn't want to talk to anyhow.

We could certainly insert caveats about Require and HERFP in the  
draft. Oddly enough, the answer-mode/alert-mode draft I did for OMA  
suffers from exactly the same quirk, but nobody complained there.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2005 09:08:57 -0400

inline

Dean Willis wrote:
>> 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?
> 

Yes, that was what I was thinking too. Which means that the option isn't 
good enough to ensure your chosen alert is rendered. But maybe it is 
good enough to know "it could have done it if it wanted to".

>> 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.
>>
> 
> Actually, I think that makes it not more complicated, but less. You  act 
> on the Alert-Info only to the extent that you trust the sender  and 
> forwarding elements to use it correctly -- kind of like not  retrieving 
> HTML links inside an unauthenticated email.  I think this  can be 
> wrapped up with some tight security considerations.
> 
> CSCF to strip off any foreign Alert-Info that it doesn't have reason  to 
> include. We can't say that in IETF, however, as we might well not  have 
> an S-CSCF.

Yes, things are simpler if we imagine this is the kind of environment 
when this feature is typically used.

>> I could pick at the details above, but now is not the time. Lets  get 
>> the basic concepts worked out first.
>>
>> 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.
> 

I don't loathe it the way you do. It presents some problems, but that is 
why they pay us the big bucks - to cope with the problems. :-)

> HERFP-eaten by the proxy if it gets a "better" response from some  other 
> branch.
> 
> So what?
> 
> Either a "better" response goes back to the UAC (perhaps from a  branch 
> that understands the require),  or it doesn't. Big loss. All  that 
> happens is that we don't get an error response back from a node  we 
> didn't want to talk to anyhow.

The problem is that there could be two UAs, one of which understands the 
A-I and another that doesn't. The one that supports the A-I isn't going 
to answer, because nobody is manning it. The one that doesn't support 
the A-I is ready and willing to answer.

The caller wants to use the A-I, but will fall back to not using it if 
necessary.

So the call is tried, and the UA that supports the A-I alerts for awhile 
using the chosen alert, but never answers. Eventually the caller gives 
up, and tries without the A-I. Now both UAs alert and the call is answered.

Of course the answer here is to not put the Required header if you don't 
really require the feature. That is a reasonable in this scenario. I 
wonder if there are any scenarios where the Require is helpful?

> We could certainly insert caveats about Require and HERFP in the  draft. 
> Oddly enough, the answer-mode/alert-mode draft I did for OMA  suffers 
> from exactly the same quirk, but nobody complained there.

Probably because it applies in a narrow context. But I would have to go 
back and look at it again.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 28 Oct 2005 15:51:33 -0500

On Oct 28, 2005, at 8:08 AM, Paul Kyzivat wrote:

>
>
>
>> there's a chance that the request might be delivered to a node  
>> that  doesn't grok the extension, and the resulting 4xx response  
>> might be  HERFP-eaten by the proxy if it gets a "better" response  
>> from some  other branch.
>> So what?
>> branch that understands the require),  or it doesn't. Big loss.  
>> All  that happens is that we don't get an error response back from  
>> a node  we didn't want to talk to anyhow.
>>
>
> The problem is that there could be two UAs, one of which  
> understands the A-I and another that doesn't. The one that supports  
> the A-I isn't going to answer, because nobody is manning it. The  
> one that doesn't support the A-I is ready and willing to answer.
>
> The caller wants to use the A-I, but will fall back to not using it  
> if necessary.
>
> So the call is tried, and the UA that supports the A-I alerts for  
> awhile using the chosen alert, but never answers. Eventually the  
> caller gives up, and tries without the A-I. Now both UAs alert and  
> the call is answered.
>
> Of course the answer here is to not put the Required header if you  
> don't really require the feature. That is a reasonable in this  
> scenario. I wonder if there are any scenarios where the Require is  
> helpful?
>

Exactly. If you don't actually require that the end point support the  
extension, don't insert a Require header for it. You can still offer  
the feature, and if it gets used, that's nice.

If we use an Alert-Info header for the "don't bother the user because  
this is just an administrative loopback test call" function allowed  
for in draft-willis-answeralert, we get some mileage out of having a  
Require. Because we REALLY DON'T want the phone to ring and get  
picked up, resulting in a very confused user. We WANT the call to  
fail if the client doesn't support the extension. There are probably  
other cases, but as with most SIP extensions, sending a Require is  
generally the exception, not the rule.

>> draft. Oddly enough, the answer-mode/alert-mode draft I did for  
>> OMA  suffers from exactly the same quirk, but nobody complained  
>> there.
>>
>
> Probably because it applies in a narrow context. But I would have  
> to go back and look at it again.
>

Well, please go have another look at that draft, because they're  
about to start gestating cattle over in OMA for the lack of a  
solution to this problem.

--
Dean