Subject: AW: AW: [Sipping] Re: [Sip] Originating Line Information

From: "Jesske, R" <[email-masked]>
Date: Mon, 16 Sep 2002 08:18:49 +0200

Hi Mike,
the CPC is used as an routing relevant parameter and is also charging/accounting relevant. If you put two CPC in an AIM message the switch doesn't know on which CPC the routing should be done. 

For using the CPC twice you need an kind of additional CPC but that isn't standardised within ITU.  

The CPC (Q.763) is only used to identify the category of the Calling Party Number and it is only used within the IAM (mandatory) and the national used parameters Information Request and Information. Of course you could extend it within SIP (but there will be no mapping to ISUP), and use it for other numbers like the Redirecting or Original Called PN...but the question is for what do you need it, for which kind of services? But you cannot use it with the Called PN.

It is interesting how ANSI has extended the categories. But if the whole ANSI set is mapped it to SIP what is with the other national variants of the CPC? For that kind of purpose you need an additional field that indicates the ISUP (or "SIP") version where the CPC comes from.

Roland

Deutsche Telekom AG
T Com Zentrale
Section T38; Signalling, Gateways and Switching Systems 
Roland Jesske, T38a12
Am Kavalleriesand 3, 64295 Darmstadt, Germany
Phone:  +49 6151 83-5940 
Fax:    +49 6151 83-4577 
mailto: [email-masked] <mailto:[email-masked]> 

> -----Ursprungliche Nachricht-----
> Von: Michael Hammer [mailto:[email-masked]]
> Gesendet: Freitag, 13. September 2002 17:56
> An: Jesske, Roland
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: AW: [Sipping] Re: [Sip] Originating Line Information
> 
> 
> Roland,
> 
> I understand that today a single CPC is used.  Just wondered 
> if it is worth 
> exploring whether multiple values may allow richer functionality and 
> decision-making to occur.
> 
> Generic Address is the same as Generic Number.  The OLI is the ANI 
> information digits (II).  Below is a list of the types of 
> values that may 
> need coverage.
> 
> The CPC is in addition to the identification of the party as calling, 
> called, or redirected, which already has expression as SIP 
> headers.  I 
> don't know that it is necessary to have separate sets 
> (headers/parameters/fields) of values depending on whether it 
> is original 
> calling, calling, called, redirecting, or some other party 
> that the call 
> touched at some point.  One data set of labels of the CPC type may be 
> sufficient.
> 
> Calling Party Category values in various standards:
>       00 - unknown
>       01 - operator, Language French
>       02 - operator, Language English
>       03 - operator, Language German
>       04 - operator, Language Russian
>       05 - operator, Language Spanish
>       06 - admin1
>       07 - admin2
>       08 - admin3
>       09 - ordinary calling subscriber
>       10 - ordinary calling subscriber with customer meter
>       11 - calling subscriber with priority
>       12 - data call (voice band data)
>       13 - test call
>       14 - customer payphone
>       15 - public   payphone
>       16 - emergency service call
>       17 - high priority emergency service call
>       18 - national security and emergency preparedness (NS/EP call)
>       19 - trunk offering
>       20 - mobile customer
>       21 - PBX subscriber
>       22 - operator with forward facility
>       23 - intercept operator
>       24 - cross-border operator
>       25 - long distance payphone
>       26 - international payphone
>       27 - international test equipment
>       28 - check calling party number
>       29 - national operator
> 
> BCI has a Called Party Category
>       0 - no indication
>       o - ordinary
>       p - payphone
> 
> Originating Line Information
>       00 - pots
>       01 - multiparty line
>       02 - ANI failure
>       06 - Station Level Rating
>       07 - special operator handling required
>       08 - inter-LATA restricted
>       10 - test call
>       20 - AIOD-listed DN sent
>       23 - coin or non-coin on calls using database access
>       24 - 800 service call
>       25 - 800 service call from a pay station
>       27 - payphone using coin control signaling
>       29 - prison/inmate service
>       30 - intercept (blank)
>       31 - intercept (trouble)
>       32 - intercept (regular)
>       34 - telco operator handled call
>       36 - CPE
>       52 - OUTWATS
>       60 - TRS call from unrestricted line
>       61 - wireless/cellular PCS (type 1)
>       62 - wireless/cellular PCS (type 2)
>       63 - wireless/cellular PCS (roaming)
>       66 - TRS call from hotel
>       67 - TRS call from restricted line
>       68 - inter-LATA restricted hotel
>       78 - inter-LATA restricted coin-less
>       70 - private pay-stations
>       93 - private virtual network
> 
> Also, Opt. BCI also includes an indication of MLPP user.  
> There may be 
> other fields I overlooked.
> 
>Mike
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Sep 2002 03:19:13 -0400

Jesske, R wrote:

 > The CPC (Q.763) is only used to identify the category of the Calling
 > Party Number and it is only used within the IAM (mandatory) and the
 > national used parameters Information Request and Information. Of
 > course you could extend it within SIP (but there will be no mapping
 > to ISUP), and use it for other numbers like the Redirecting or
 > Original Called PN...but the question is for what do you need it, for
 > which kind of services? But you cannot use it with the Called PN.

SIP is not bound by what can be mapped into ISUP.

We already have a way of describing the UA associated with the caller or 
callee - the caller prefs spec. Some of the things, like language 
support, already exist in the caller prefs spec. If something seems 
useful to people, we can register more.

 >
 > It is interesting how ANSI has extended the categories. But if the
 > whole ANSI set is mapped it to SIP what is with the other national
 > variants of the CPC? For that kind of purpose you need an additional
 > field that indicates the ISUP (or "SIP") version where the CPC comes
 > from.

No way.

We are not doing national variants in SIP.

If you want to register a new descriptive type for a UA, do so through 
caller prefs (i.e., prison="TRUE"). These registrations are independent 
of any ISUP variant. It would be the responsibility of the gateways to 
either map or discard them.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Michael Hammer <[email-masked]>
Date: Tue, 17 Sep 2002 11:03:24 -0400

Jonathon,

To be perfectly clear, I in no way want to promote any national variants in 
SIP.  The examples I provided were simply a snapshot of various CPC values 
in use today.  As you rightly point out there is overlap, as in the case of 
indication of language support, with other header/parameter values.  I 
would recommend that anyone attempting to register CPC values (a la 
Peterson's draft) be cognizant of these overlaps, and choose only 
characteristics that are not covered by other SIP values already.

I never thought of a prison or hotel phone as a feature, but if that is 
where this type of stuff is already partially defined, then we could look 
at what got left out and what might be of value.

Does this mean that this approach should be pursued instead of the CPC draft?

Mike

At 03:19 AM 9/17/2002 -0400, Jonathan Rosenberg wrote:

>callee - the caller prefs spec. Some of the things, like language support, 
>already exist in the caller prefs spec. If something seems useful to 
>people, we can register more.
>
> >
>caller prefs (i.e., prison="TRUE"). These registrations are independent of 
>any ISUP variant. It would be the responsibility of the gateways to either 
>map or discard them.
>
>-Jonathan R.
>
>--

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Sep 2002 14:30:39 -0400

Michael Hammer wrote:
> Jonathon,
> 
> To be perfectly clear, I in no way want to promote any national variants 
> in SIP.  The examples I provided were simply a snapshot of various CPC 
> values in use today.  As you rightly point out there is overlap, as in 
> the case of indication of language support, with other header/parameter 
> values.  I would recommend that anyone attempting to register CPC values 
> (a la Peterson's draft) be cognizant of these overlaps, and choose only 
> where this type of stuff is already partially defined, then we could 
> look at what got left out and what might be of value.
> 

I think it depends on what problems people are trying to solve. Behind 
CPC/OLI are specific capabilities that folks were trying to address - 
routing the call based on some kind of characteristic of the caller or 
line, or presentation of information to the called party. Its much 
easier to figure out how to do something in SIP when we distill CPC/OLI 
to speific functions that are desired, and then we can figure out how 
these are provided in SIP. I do not advocate a blind copy-paste 
approach, whereby we simply add headers continuously to SIP to match 
equivalent information in ISUP.

-Jonathan R.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 17 Sep 2002 15:33:05 -0400

Agreed.  Need to munch on the possible features in a SIP model.

Mike

At 02:30 PM 9/17/2002 -0400, Jonathan Rosenberg wrote:

>line, or presentation of information to the called party. Its much easier 
>to figure out how to do something in SIP when we distill CPC/OLI to 
>speific functions that are desired, and then we can figure out how these 
>are provided in SIP. I do not advocate a blind copy-paste approach, 
>whereby we simply add headers continuously to SIP to match equivalent 
>information in ISUP.
>
>-Jonathan R.
>
>--