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

Jesske, R wrote:
> Paul,
> I see what you are meaning. Perhaps I'm to much Bell head.
> So perhaps we can try it more general. not to have the many requirements you mentioned below.
> We have already the Language header so the Operator Language can be expressed within the call. 
> Is there within SIP a header that can be used to express what the Caller is.
> Category of the caller
> Like:
> 
> Operator
> Hotel
> Telephone Company
> Police
> Payphone
> ...

These seem not *too* different in character to existing callee 
capabilities (as defined in RFC3840). If so, they would be carried as 
parameters on the Contact header.

But before concluding that, it would be important to decide which of 
these are alternative values of a single feature, and which are distinct 
features.

And then there is the matter of how these are authenticated/vouched for. 
(I don't suppose you want just anyone to assert they are from the Police.)

These may more properly be handled as signed assertions, as proposed in 
draft-tschofenig-sip-saml-01.

> And then the purpose of the Call:
> Like:
> Data
> Test
> Priority
> ...

Well, there are probably multiple solutions for Priority already - you 
just need to figure out which one.

I have the impression that Test is really about accounting much more 
than testing. If the goal is just to have a non-billable call, then that 
probably ought to be addressed however billing is.

I *really* don't get Data as a call type. In the context of sip, what 
does it mean???

	Paul

> With such elements I can interwork with the PSTN/ISDN (That was what I mentioned below)
> Is that a starting point we can discuss on.
> 
> More comments inline.
> 
> Roland
> 
> 
>>-----Ursprüngliche Nachricht-----
>>Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
>>Gesendet: Dienstag, 4. Oktober 2005 18:39
>>An: Jesske, Roland
>>Cc: Miguel.An.Garcia@nokia.com; sipping-tispan@ietf.org; 
>>Alexeitsev, Denis
>>Betreff: Re: AW: AW: [Sipping-tispan] Requirements -02g
>>
>>
>>Roland,
>>
>>I am having great difficulty understanding the points you are 
>>trying to 
>>make. I will clarify inline where I don't understand.
>>
>>	Paul
>>
>>Jesske, R wrote:
>>
>>>Paul,
>>>It is the interpretation how you will interpret such values.
>>
>>I can't really parse the above sentence.
>>
>>If you are saying that it is up to the parties to interpret 
>>the values 
>>as they wish, then I will disagree. That is fine if there is only one 
>>party. 
> 
> I wanted only to express how we as people that are trying to standardise this issue are looking at these categories. I would like to have unique categories, where each user/network entity have the same understanding and interpretation.
> 
> But the whole purpose of standards is to allow multiple 
> 
>>implementations. If one implementer makes one interpretation when 
>>supplying the calling party category, and another makes a different 
>>interpretation when receiving it, then you have a mess. If 
>>you just want 
>>to tunnel stuff with no semantics, you can propose a "Any" 
>>header. (But 
>>it won't be approved.)
>>
> 
> As I said the interpretation must be unique.
> 
> 
>>>>From one point of view it is correct to distinguish like you did.
>>>The origin within the PSTN/ISDN only wanted to distinguish 
>>
>>the calling party if it is a French or English speaking operator
>>
>>What is to be done if the operator only speaks Chinese? Is 
>>there then no 
>>way to specify that it is an operator call without lying 
>>about the language?
> 
> 
> That was my fault. As I proposed above we can use the Language header + Category=Operator.
> 
> 
>>>or if it is a Test call done from O&M stuff of a telephone 
>>
>>company (so it was a call free of charge) or if it was a 
>>payphone call or data call.
>>
>>I don't understand your point. It seems to be that so far 
>>there has been 
>>no need for any other categories, so they aren't defined.
>>
>>But then what does one do if/when a need for another category does 
>>arise? If mechanisms have only been put into place to represent the 
>>existing ones, how can more be added?
>>
>>Perhaps your answer will be that you just wish to convey the 
>>byte, just 
>>as it is used in SS7, and that the values will continue to be defined 
>>however they are in SS7, and extended however they are for that. If 
>>indeed that is the intent, then that should be specified. 
>>(But if that 
>>is what you do, then expect some argument.)
> 
> No it is better to have a more generic approach. In future we want to supply more services. Such a category can help.
> 
> 
>>>The intension was to have a possibility so mark the call 
>>
>>for special routing an billing purposes.
>>
>>>So I don't think that we only need such a namespace to 
>>
>>identify such a category of the communication. If we split up 
>>I think we will end up in endless possibilities.
>>
>>Perhaps, but I think those are endless possibilities for new and good 
>>things.
>>
> 
> OK; see proposal above.
> 
> 
>>If it is not split up, then there are endless possibilities for bad 
>>things to happen, because the attributes that calling party category 
>>seems to encompass already are redundant with attributes 
>>present in sip. 
>>Encoding the same thing two ways is a guarantee of ambiguity.
>>
>>
>>>And the Interworking is also affected from such various 
>>
>>possibilities.
>>
>>Interworking with what? Interworking with regular sip devices is 
>>affected by using this odd encoding.
>>
> 
> With Interworking I meant the PSTN/ISDN.
> 
> 
>>>With regard to ACR there is no more requirement for 
>>
>>override ACR due to the originating party e.G. Police.
>>
>>>I know we had a long discussion with regard to that, but I 
>>
>>was pointed to that fact that ETSI does not describe or 
>>requires such a service. If ACR is active the police has to 
>>try it again with sending  a number. That is the way how it 
>>works in Germany.
>>
>>>So we don't need to define such a requirement.
>>
>>Fine. As long as that is off the table we need not talk about it.
>>
> 
> OK
> 
>>	Paul
>>
>>
>>>Roland
>>>
>>>
>>>
>>>
>>>
>>>>-----Ursprüngliche Nachricht-----
>>>>Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
>>>>Gesendet: Freitag, 30. September 2005 16:31
>>>>An: Jesske, Roland
>>>>Cc: Miguel.An.Garcia@nokia.com; sipping-tispan@ietf.org; 
>>>>Alexeitsev, Denis
>>>>Betreff: Re: AW: [Sipping-tispan] Requirements -02g
>>>>
>>>>
>>>>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
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan