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

[Dean Willis <[e-mail]>]

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.

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

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


_______________________________________________
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