Re: AW: [Sipping-tispan] Requirements -02g

[Paul Kyzivat <[e-mail]>]

I've pruned the conversation, and then replied inline.

	Paul

Jesske, R wrote:

>>I have a comment about one of the added requirements, than then some 
>>response to your  questions. First, the added requirement:
>>
>>
>>>REQ-CAT-1: For service applicability to special groups and
>>>           interoperability with the PSTN/ISDN, application servers
>>>           providing services require to have an indication of the
>>>           calling party category.  This is needed because some
>>>            services apply a special behavior to certain user groups
>>>           (e.g., like Pay-Phones).
>>
>>This isn't helpful without some additional information about calling 
>>party category.
>>- What is it?
> 
> The CPC is an indication within the PSTN to categorise groups of users/entities like Payphones.
> This is used for special routing and also billing and charging purposes.
> 
>>- Is it a single attribute with a well known enumeration of
>>   possible values?
> 
> The CPC values within the ITU-T ISUP are:
> operator, language French
> operator, language English
> operator, language German
> operator, language Russian
> operator, language Spanish
> ordinary calling subscriber
> calling subscriber with priority
> data call (voice band data)
> test call
> payphone
> 
> Some other values are specified for national purposes like emergency, police or other ones.> 
> 
>>- Or is the set of values open ended?
> 
> ITU-T is very restrictive in specifying such values for international purposes.
> 
> Countries like US have additional parameters and values identifying the category of the calling party.

OK. Then if you want to preserve the existing semantics, this consists 
of a single value drawn from a standardized enumeration. Apparently the 
values in the enumeration consist of some that are internationally 
standardized and some that are nationally standardized.

To me this cries out for the use of a URN - a new one created for the 
purpose. But that is a solution, not a requirement.

But then I think the requirement REQ-CAT-1 needs to specify the precise 
namespace(s) that it must be possible to draw values from.

This is *if* the goal is to preserve the existing behavior, rather than 
to improve upon it. I would observe that what you have described has a 
bunch of problems:

- Operator, language *
   combines two orthogonal attributes: operator and language.
   It is also not extensible to other languages.
   It doesn't support things like: Police, language French.

- Test Call - seems to be an attribute of the call, not the caller.
   Could not an Operator, or a Police make a test call?

- Data Call - again seems to be an attribute of the call,
   not the caller. It would seem that this is in fact potentially
   orthogonal to all of the other listed categories.
   Presumably police can make data calls, probably operators too,
   and privileged callers. And probably there could be data
   test calls.

If you have to make extensions to SIP to support this stuff, do you 
really want to replicate the mistakes of the past? How about instead 
create individual requirements for the different caller and call 
attributes that need to be conveyed:

REQ-CAT-a: It must be possible to convey the language(s) known to
   the caller.

REQ-CAT-b: It must be possible to indicate that the caller is
   an operator. (Needs a suitable definition of what an operator is.)

REQ-CAT-c: It must be possible to assert that the caller has priority.

REQ-CAT-d: (Something about data call, though it is hard for me to
   understand exactly what the assertion would be.)

REQ-CAT-e: (Something about a payphone. Just saying payphone doesn't
   seem to mean much. Something about how charging is to be done
   would seem more appropriate.)

Yadda, yadda, yadda.

Done that way, I think it will become apparent that there are existing 
mechanisms for many of these more finely diced requirements.

>>>- We had a pending action point to revisit the ACR 
>>requirements once we 
>>>have drafted the Calling Party Category requirements. Now we have 
>>>achieved this state, and my opinion is that we don't need 
>>to add any 
>>>extra wording to ACR, since the Calling Party Category requirements 
>>>cover the use case we have been discussing (police 
>>anonymously call a 
>>>user with ACR activated).
>>
>>The existing wording does not seem at all sufficient to me to 
>>cover this 
>>case. The following is in the description of ACR:
>>
>>    services also contains provisions for exceptional cases where the
>>    service is overridden.  ... Another case is when the caller
>>    has been duly authorized to override the ACR service 
>>    running at the
>>    called party's network.  This is the case, e.g., when a police
>>    officer or any other authority is anonymously calling to a user
>>    having the ACR simulation service activated.
>>
>>There are no requirements corresponding to this description. What 
>>determines when a caller has been "duly authorized"? IMO the 
>>insertion 
>>of a calling party category does not constitute any kind of 
>>authorization. At best it is a kind of authentication.
> 
> The CPC shall be included by an trusted network element that knows about the originating user. So the procedures should be equal to the one used for the P-Asserted-Identity.

I will repeat what I have said before. An assertion by the originating 
network that the caller is a policeman, while it may be trusted by the 
terminating network, is not any kind of authorization. It is simply a 
form of authentication.

If the ACR service wants to specify particular overrides, then it needs 
to specify the cases in which they apply. Or it can simply state that 
the ACR service may decide on overrides as it wishes, based on known 
attributes of the call and caller.

The distinction is whether a caller that knows he has particular 
attributes (say a policeman) *knows* he will get ACR override, 
regardless of where he calls, or only knows what the result will be for 
a particular terminating network whose policies he is familiar with.

So I may agree with you that ACR requires no added mechanisms, as long 
as the description of the service is modified to be clear that overrides 
are at the discretion of the terminating network ACR service implementation.

	Paul

_______________________________________________
Sipping-tispan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan