AW: [Sipping-tispan] Requirements -02g

"Jesske, R" <R.Jesske@t-com.net> Fri, 30 September 2005 06:25 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELEKa-0004aB-MM; Fri, 30 Sep 2005 02:25:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELEKZ-0004a6-8y for sipping-tispan@megatron.ietf.org; Fri, 30 Sep 2005 02:25:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23091 for <sipping-tispan@ietf.org>; Fri, 30 Sep 2005 02:25:14 -0400 (EDT)
Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELESN-0004OP-FK for sipping-tispan@ietf.org; Fri, 30 Sep 2005 02:33:20 -0400
Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Fri, 30 Sep 2005 08:25:05 +0200
Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id <T6GLG7XF>; Fri, 30 Sep 2005 08:25:05 +0200
Message-Id: <E7666D92C64C2845AEF12636FF94F95202319F9E@S4DE8PSAAGQ.blf.telekom.de>
From: "Jesske, R" <R.Jesske@t-com.net>
To: pkyzivat@cisco.com, Miguel.An.Garcia@nokia.com
Subject: AW: [Sipping-tispan] Requirements -02g
Date: Fri, 30 Sep 2005 08:25:02 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
Content-Transfer-Encoding: quoted-printable
Cc: sipping-tispan@ietf.org, "Alexeitsev, D" <D.Alexeitsev@t-com.net>
X-BeenThere: sipping-tispan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of requirements for SIP introduced by ETSI TISPAN <sipping-tispan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sipping-tispan>
List-Post: <mailto:sipping-tispan@ietf.org>
List-Help: <mailto:sipping-tispan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=subscribe>
Sender: sipping-tispan-bounces@ietf.org
Errors-To: sipping-tispan-bounces@ietf.org

Paul
comments below

Roland

> -----Ursprüngliche Nachricht-----
> Von: sipping-tispan-bounces@ietf.org 
> [mailto:sipping-tispan-bounces@ietf.org] Im Auftrag von Paul Kyzivat
> Gesendet: Mittwoch, 28. September 2005 16:26
> An: Miguel Garcia
> Cc: 'sipping-tispan@ietf.org'.org'; Alexeitsev, Denis
> Betreff: Re: [Sipping-tispan] Requirements -02g
> 
> 
> 
> 
> Miguel Garcia wrote:
> 
> > The changes in this version are:
> > - Grouping of the CCBS/CCNR requirements for better understing
> > - A few clarifications to the CDIV requirements
> > - Addition of the Calling Party Category requirements.
> 
> 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.


> - If the values are extensible, how does one learn of the definitions?
> - Are multiple values permitted?
>    (E.g. the caller is both "police" and "emergency-responder",
>     or both "operator" and "prison".)
The CPC it self is a single value.
The ANSI ISUP knows some additions like the ANI (Automatinc Number Identification.

> 
> Without this information it is impossible to evaluate the use 
> of this to 
> enable services.
I hope this information gives you a better view. As an example we are using a Payphone indication to have special rates for users using the payphone.
> 
> > Now, I have a few questions.
> > 
> > - The Calling Party Category requirements do not constitute 
> a service by 
> >  itself. In my opinion, they should be General requirements 
> listed a 
> > REQ-GEN-4 and REQ-GEN-5. Does anyone oppose to move them to 
> the General 
> > section?
> 
> Seems reasonable to me.
> 
> > - 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.

> 
> As it stands, calling party category seems to be an attribute without 
> semantics, which could be used to do anything. I don't think 
> that is good.
> 
> 	Paul
> 
> > Last, but not least, WE ARE ALMOST DONE with the 
> requirements. So please 
> > take a look at this draft and comment on any pending issue. 
> I would like 
> > to solve issues as soon as possible and submit the draft 
> for publication.
> > 
> > Regards,
> > 
> >         Miguel
> > 
> 
> _______________________________________________
> Sipping-tispan mailing list
> Sipping-tispan@ietf.org
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan