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

[Paul Kyzivat <[e-mail]>]

inline

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

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

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

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

>>> 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),  

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

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

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

_______________________________________________
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