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

[Paul Kyzivat <[e-mail]>]

Jesske, R wrote:
> Sorry this mail slipped through.
> The capabilities in the contact header can solve many of the problems.
> How is it with the interworking. Normally you put into the contact header
> the URI of the Interworking unit and not of the originating PSTN user.
> So can I put in the capabilities of the origin user or have I to take
> then the capabilities of the interworking unit.

The interworking unit can insert whatever capabilities it wishes.
It would probably be best if they were true, but there is certainly
no *requirement* that they be complete. Because the interworking unit is 
probably transparent to many capabilities, it makes sense that they 
reflect those of the user it is representing.

> The draft-tschofenig-sip-saml-01 has a lot of information that can be
> included in an INVITE. But my question is if this is not a little bit
> overloading such an INVITE with all that XML stuff for saying that
> this is an payphone.

In an environment where there is complete transitive trust, this 
mechanism may be overkill.

As we go forward, I don't know how much transitive trust there will be. 
(Will Deutche Telecom believe Vonage that a call is from the police?)

Probably the saml approach is good in the same environment where sip 
identity is used. In an environment where P-Asserted-ID is used rather 
than sip identity, something simpler than saml will be sufficient.

	Paul

> 
> 
> 
>>-----Ursprüngliche Nachricht-----
>>Von: Paul Kyzivat [mailto:[e-mail]] 
>>Gesendet: Donnerstag, 6. Oktober 2005 18:53
>>An: Jesske, Roland
>>Cc: [e-mail]; [e-mail]; 
>>Alexeitsev, Denis
>>Betreff: 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:[e-mail]] 
>>>>Gesendet: Dienstag, 4. Oktober 2005 18:39
>>>>An: Jesske, Roland
>>>>Cc: [e-mail]; [e-mail]; 
>>>>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:[e-mail]] 
>>>>>>Gesendet: Freitag, 30. September 2005 16:31
>>>>>>An: Jesske, Roland
>>>>>>Cc: [e-mail]; [e-mail]; 
>>>>>>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
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan