Re: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping)

[Paul Kyzivat <[e-mail]>]

I mostly agree with Jonathan. One slight difference inline.

	Paul

Jonathan Rosenberg wrote:
> inline.
> 
> Paul Kyzivat wrote:
> 
>> Brian,
>>
>> The case you specify is almost the same case I am talking about, but 
>> make more specific.
>>
>> I didn't say anything about what values the specific URIs should be. I 
>> think there are three interesting categories:
>> 1) a URL of a remote resource that the UAS may actually retrieve
>>    and render
>>
>> 2) a URL of a resource local to the UAS.
>>
>> 3) a URN, that simply specifies a name of a particular alerting style.
>>    The UAS must know what to do for one of these to use it, or have its
>>    own way of discovering that given the URN.
>>
>> I have seen (2) used, but usually as an alternative for (3) in that it 
>> isn't really expected that the UAS will necessarily have something 
>> stored in exactly this way. I find (2) to be unreasonable in most 
>> deployments, and (3) to be a much more reasonable approach, that has 
>> equivalent functionality.
>>
>> This is all orthogonal to how trustworthiness of Alert-Info headers is 
>> managed. I find it difficult to imagine any cases when the UAS would 
>> want to honor a value sent by the UAC.
> 
> Well, here is where URN helps. Since the UA that has to render the URN 
> has to know what it means, you can authorize it or not based on that 
> understanding.
> 
> As others have pointed out, the URN is not going to help cases where 
> people want Britney Spears songs as ringback, but it can help with 
> country-specific ringbacks, where we could easily create a registry.
> 
> I've become convinced that custom ringtones are best done the way they 
> are done today. The ringtone is stored on the called party device, and 
> logic on the phone itself selects which one to use based on the identity 
> of the caller.

I think the above is a perfectly reasonable mechanism, well suited to 
reasonably smart devices with UIs and capabilities for the necessary 
configuration, and when it makes sense to manage each device independently.

I also see value in a case where some of this logic is offloaded from 
the device to a server acting on its behalf. The server makes a decision 
about which alert as appropriate for each call, while the device does 
the rendering of that alert. This is potentially useful for devices that 
are limited in their capabilities in general and their UI in particular. 
  It also could be helpful when there are multiple devices and the same 
alert selection logic is desired for them all.

> Having the caller select content that gets rendered at 
> the called party, without asking the called party for authorization 
> (which is the case for ringtones), is a recipe for absolute disaster. 
> I'm not worried about tasteless music - I'm worried about some malicious 
> user that decides to record some highly offensive content and then start 
> calling random numbers to cause the content to get played out 
> automatically. Big mistake.

Yes, I agree. At most, I can see a UA (or a proxy acting on behalf of 
the UA) accepting a small selection of Alert-Info values that it 
considers benign. Other values should be ignored.

If a UA knows it has a proxy acting on its behalf in screen Alert-Info, 
and perhaps inserting values based on policy carried out by the proxy, 
then the UA may be willing to trust any value it receives via that 
proxy, and render any Alert-Info value it is capable of rendering.

	Paul

> 
> -Jonathan R.
> 

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