Subject: Re: [Sip] What is the mapping of ANI II digits to rpi-np?

From: Flemming Andreasen <[email-masked]>
Date: Tue, 02 Oct 2001 20:08:37 -0400

[email-masked] wrote:

> To all,
>
> In a message dated 9/28/01 5:11:08 PM Eastern Daylight Time, [email-masked]
> writes:
>
> << Hi guys,
>
>  I had initially sent out a question on this issue and received no
>  responses; so I'm trying again... :^)
>
>  I'm trying to understand the appropriate translation of ANI II digits to
>  their SIP equivalent.  However, when
>  I try to match the currently defined ANI II digits from
>  http://www.nanpa.com/number_resource_info/ani_ii_assignments.html
>  against the keywords defined in
>  Appendix A of draft-ietf-sip-privacy-02.txt, it appears to be a sparse,
>  non-invertible mapping.
>
>  So, I have a few questions:
>  1) Is there a more recent version of this syntax?
>  2) Could someone define a less sparse, invertible mapping as a best
>  current practice?
>  3) Should we instead just define a new tag such as, ";ani-ii=number" ?
>  4) Other ideas? >>
>
> <<My comment:
> It seems best to use your suggestion 3 - simply define a tag for
> "ani-ii=number" and use the currently defined numbers, not some newly
> invented list of keywords that have unknown meanings. Let's not reinvent the
> wheel!

Yes and no. As Alan indicated, we already have SIP-T to handle the "good old
wheel case" and we shouldn't just blindly copy existing PSTN parameters to SIP
headers. Some issues to consider here:
- do we really want to get into to coin control signalling ?
- is there a need for indicating toll free services via ANI II when we have
tel-URL ?
- perhaps most importantly, what kind of SIP-relevant information above and
beyond ANI II would we actually like to convey (generalize it) ?

-- Flemming

>
>
> Mike Pierce
>
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

--
Flemming Andreasen
Cisco Systems

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Tue, 2 Oct 2001 22:57:16 EDT

In a message dated 10/2/01 4:00:17 PM Eastern Daylight Time, 
[email-masked] writes:

<< How about do something like:
 From: <sip:13082536367;oli=[email-masked];user=phone>
 where oli = originating line information = ani-ii
 
 This encloses the II information within telephone URL consistent with
 RFC2806 and makes it independent of SIP. 

It doesn't make any difference to me how it is coded (nor do I completely 
understand the coding being used). My only point is that SIP should use the 
set of numeric values already defined in the telephone industry (through a 
multi-decade evolutionary process), not invent a new list of values. If there 
are additional values needed to support the SIP application for the type of 
"telephones" that will originate calls, then a simple request to the NANPA 
would likely get new codes asigned. It is their job, just like IANA assigns 
codes in the Internet.

If there are values that are not needed, like "coin control", then they 
simply won't be used in SIP. However, why wouldn't "coin control" be 
possible. Won't someone want to build coin phones that run on SIP? Seems like 
a good business to me.

Mike Pierce

---

From: Alan Johnston <[email-masked]>
Date: Wed, 03 Oct 2001 11:32:58 -0500

Bryan,

We have gone over the mapping issue - see the notes below by Sharma.  Note
that this set includes identifiers from both North America and the rest of
the world, so not every token has meaning in a given environment.  Also,
note that since ANI has such strong billing/charging implications, mapping
directly from a SIP header to the PSTN is not a good idea.

As I have said in another post, using tokens instead of numbers is necessary
to eliminate the regional variants on II digits.

Thanks to your comments, we propose three new tokens: not-applicable,
cellular-ordinary, and cellular-roaming to cover some of the cases you
outlined.

Thanks,
Alan Johnston
sip:[email-masked]

-------- Original Message --------
Subject: II digits to SIP REMOTE-PARTY-ID  NP MAPPING
Date: Wed, 03 Oct 2001 11:03:27 -0500
From: Sharma Kanchinadham <[email-masked]>
To: [email-masked]

Hi Alan,

I suggest that 3 new values be added to the existing Nature of Party. The 3
values are:

1. not-applicable
2. cellular-ordinary
3. cellular-roaming

Here is the mapping from II digits to rpi-np

00                             ordinary
01                             not-applicable
02                             failure
06                             not-applicable
07                             not-applicable
20                             not-applicable
23                             not-applicable
24                             trans-freephone
25                             trans-freephone and payphone
27                             payphone
29                             prison
30-32                         not-applicable
34                             operator
40-49                        depends on the carrier's implementation
52                            not-applicable
60                            not-applicable
61                            cellular-ordinary
62                            cellular-ordinary
63                            cellular-roaming
66                            not-applicable
67                            not-applicable
70                            payphone
80-89                        reserved
93                            not-applicable

Also the following points are to be noted:

1.  The nature of party  rpi-np is meant to be primary used in the PSTN to
SIP direction. It is not intended to be used in the SIP to PSTN direction.
Mapping to II digits towards the PSTN might invoke unintended results in the

PSTN.

2. A particular II value could map to 2 values to the rpi-np. For example,
II value of 25 can map to rpi-np=trans-freephone and rpi-np=payphone.

Thanks ,
Sharma Kanchinadham
IP Call Processing & Standards
Worldcom

[email-masked]

Bryan Byerly wrote:

> Hi guys,
> 4) Other ideas?
> Here's the sparse, non-invertible mapping that I came up with:
>
> ordinary                  00
> residential
> business
> priority
> hotel                     06
> failure                   02
> hospital
> prison                    29
> police
> test
> payphone                  70
> coin                      27
> payphone-public
> payphone-private
> coinless
> restrict
> coin-restrict
> coinless-restrict
> reserved                  80-89
> operator                  34, 07?
> trans-freephone
> isdn-res
> isdn-bus
> unknown
> emergency
>
> I was specifically unable to identify a mapping for the following ANI II
> digits:
> 01, 20, 23, 24, 25, 30, 31, 32, 52, 60, 61, 62, 63, 66, 67, 80-89, 93
>
> Here's the lists of digits as defined by www.nanpa.com:
>
>          ANI II DIGITS: ASSIGNMENTS AS OF FEBRUARY 2, 1999
>
>     DIGIT PAIR
>                  DESCRIPTION
>     00         Plain Old Telephone Service (POTS) -
>                  non-coin service requiring no special
>                  treatment
>     01         Multiparty line (more than 2) - ANI cannot be
>                  provided on 4 or 8 party lines. The presence of
>                  this "01" code will cause an Operator Number
>                  Identification (ONI) function to be performed at
>                  the distant location. The ONI feature routes the
>                  call to a CAMA operator or to an Operator
>                  Services System (OSS) for determination of the
>                  calling number.
>     02         ANI Failure - the originating switching system
>                  indicates (by the "02" code), to the receiving
>                  office that the calling station has not been
>                  identified. If the receiving switching system
>                  routes the call to a CAMA or Operator
>                  Services System, the calling number may be
>                  verbally obtained and manually recorded. If
>                  manual operator identification is not available,
>                  the receiving switching system (e.g., an
>                  interLATA carrier without operator capabilities)
>                  may reject the call.
>     03-05  Unassigned
>     06         Station Level Rating - The "06" digit pair is
>                  used when the customer has subscribed to a
>                  class of service in order to be provided with
>                  real time billing information. For example,
>                  hotel/motels, served by PBXs, receive detailed
>                  billing information, including the calling party?s
>                  room number. When the originating switching
>                  system does not receive the detailed billing
>                  information, e.g., room number, this "06" code
>                  allows the call to be routed to an operator or
>                  operator services system to obtain complete
>                  billing information. The rating and/or billing
>                  information is then provided to the service
>                  subscriber. This code is used only when the
>                  directory number (DN) is not accompanied by
>                  an automatic room/account identification.
>     07          Special Operator Handling Required - calls
>                  generated from stations that require further
>                  operator or Operator Services System
>                  screening are accompanied by the "07" code.
>                  The code is used to route the call to an
>                  operator or Operator Services System for
>                  further screening and to determine if the station
>                  has a denied-originating class of service or
>                  special routing/billing procedures. If the call is
>                  unauthorized, the calling party will be routed to
>                  a standard intercept message.
>     08-09   Unassigned
>     10         Not assignable - conflict with 10X test code
>     11         Unassigned
>     12-19   Not assignable - conflict with international
>                  outpulsing code
>     20         Automatic Identified Outward Dialing (AIOD) -
>                  without AIOD, the billing number for a PBX is
>                  the same as the PBX Directory Number (DN).
>                  With the AIOD feature, the originating line
>                  number within the PBX is provided for charging
>                  purposes. If the AIOD number is available
>                  when ANI is transmitted, code "00" is sent. If
>                  not, the PBX DN is sent with ANI code "20". In
>                  either case, the AIOD number is included in
>                  the AMA record.
>     21-22   Unassigned
>     23          Coin or Non-Coin - on calls using database
>                  access, e.g., 800, ANI II 23 is used to indicate
>                  that the coin/non-coin status of the originating
>                  line cannot be positively distinguished for ANI
>                  purposes by the SSP. The ANI II pair 23 is
>                  substituted for the II pairs which would
>                  otherwise indicate that the non-coin status is
>                  known, i.e., 00, or when there is ANI failure.
>
>                  ANI II 23 may be substituted for a valid 2-digit
>                  ANI pair on 0-800 calls. In all other cases, ANI
>                  II 23 should not be substituted for a valid
>                  2-digit ANI II pair which is forward to an SSP
>                  from an EAEO.
>
>                  Some of the situations in which the ANI II 23
>                  may be sent:
>
>                        Calls from non-conforming end offices
>                        (CAMA or LAMA types) with combined
>                        coin/non-coin trunk groups.
>                        0-800 Calls
>                        Type 1 Cellular Calls
>                        Calls from PBX Trunks
>                        Calls from Centrex Tie Lines
>     24         Code 24 identifies a toll free service call that
>                  has been translated to a Plain Old Telephone
>                  Service (POTS) routable number via the toll
>                  free database that originated for any non-pay
>                  station. If the received toll free number is not
>                  converted to a POTS number, the database
>                  returns the received ANI code along with the
>                  received toll free number. Thus, Code 24
>                  indicates that this is a toll free service call
>                  since that fact can no longer be recognized
>                  simply by examining the called address.
>     25         Code 25 identifies a toll free service call that
>                  has been translated to a Plain Old Telephone
>                  Service (POTS) routable number via the toll
>                  free database that originated from any pay
>                  station, including inmate telephone service.
>                  Specifically, ANI II digits 27, 29, and 70 will be
>                  replaced with Code 25 under the above stated
>                  condition.
>     26         Unassigned
>     27         Code 27 identifies a line connected to a pay
>                  station which uses network provided coin
>                  control signaling. II 27 is used to identify this
>                  type of pay station line irrespective of whether
>                  the pay station is provided by a LEC or a
>                  non-LEC. II 27 is transmitted from the
>                  originating end office on all calls made from
>                  these lines.
>     28         Unassigned
>     29         Prison/Inmate Service - the ANI II digit pair 29
>                  is used to designate lines within a
>                  confinement/detention facility that are intended
>                  for inmate/detainee use and require outward
>                  call screening and restriction (e.g., 0+ collect
>                  only service). A confinement/detention facility
>                  may be defined as including, but not limited to,
>                  Federal, State and/or Local prisons, juvenile
>                  facilities, immigration and naturalization
>                  confinement/detention facilities, etc., which are
>                  under the administration of Federal, State, City,
>                  County, or other Governmental agencies.
>                  Prison/Inmate Service lines will be identified by
>                  the customer requesting such call screening
>                  and restriction. In those cases where private
>                  paystations are located in
>                  confinement/detention facilities, and the same
>                  call restrictions applicable to Prison/Inmate
>                  Service required, the ANI II digit for
>                  Prison/Inmate Service will apply if the line is
>                  identified for Prison/Inmate Service by the
>                  customer.
>     30-32   Intercept - where the capability is provide to
>                  route intercept calls (either directly or after an
>                  announcement recycle) to an access tandem
>                  with an associated Telco Operator Services
>                  System, the following ANI codes should be
>                  used:
>
>                        30 Intercept (blank) - for calls to
>                        unassigned directory number (DN)
>                        31 Intercept (trouble) - for calls to
>                        directory numbers (DN) that have been
>                        manually placed in trouble-busy state
>                        by Telco personnel
>                        32 Intercept (regular) - for calls to
>                        recently changed or disconnected
>                        numbers
>     33        Unassigned
>     34         Telco Operator Handled Call - after the Telco
>                  Operator Services System has handled a call
>                  for an IC, it may change the standard ANI digits
>                  to "34", before outpulsing the sequence to the
>                  IC, when the Telco performs all call handling
>                  functions, e.g., billing. The code tells the IC that
>                  the BOC has performed billing on the call and
>                  the IC only has to complete the call.
>     35-39   Unassigned
>     40-49  Unrestricted Use - locally determined by
>                  carrier
>     50-51   Unassigned
>     52         Outward Wide Area Telecommunications
>                  Service (OUTWATS) - this service allows
>                  customers to make calls to a certain zone(s) or
>                  band(s) on a direct dialed basis for a flat
>                  monthly charge or for a charge based on
>                  accumulated usage. OUTWATS lines can dial
>                  station-to-station calls directly to points within
>                  the selected band(s) or zone(s). The LEC
>                  performs a screening function to determine the
>                  correct charging and routing for OUTWATS
>                  calls based on the customer?s class of service
>                  and the service area of the call party. When
>                  these calls are routed to the interexchange
>                  carrier via a combined WATS-POTS trunk
>                  group, it is necessary to identify the WATS
>                  calls with the ANI code "52".
>     53-59   Unassigned
>     60         TRS - ANI II digit pair 60 indicates that the
>                  associated call is a TRS call delivered to a
>                  transport carrier from a TRS Provider and that
>                  the call originated from an unrestricted line (i.e.,
>                  a line for which there are no billing restrictions).
>                  Accordingly, if no request for alternate billing is
>                  made, the call will be billed to the calling line.
>     61         Cellular/Wireless PCS (Type 1) - The "61" digit
>                  pair is to be forwarded to the interexchange
>                  carrier by the local exchange carrier for traffic
>                  originating from a cellular/wireless PCS carrier
>                  over type 1 trunks. (Note: ANI information
>                  accompanying digit pair "61" identifies only the
>                  originating cellular/wireless PCS system, not
>                  the mobile directory placing the call.
>     62         Cellular/Wireless PCS (Type 2) - The "62" digit
>                  pair is to be forwarded to the interexchange
>                  carrier by the cellular/wireless PCS carrier
>                  when routing traffic over type 2 trunks through
>                  the local exchange carrier access tandem for
>                  delivery to the interexchange carrier. (Note:
>                  ANI information accompanying digit pair "62"
>                  identifies the mobile directory number placing
>                  the call but does not necessarily identify the
>                  true call point of origin.)
>     63         Cellular/Wireless PCS (Roaming) - The "63"
>                  digit pair is to be forwarded to the
>                  interexchange carrier by the cellular/wireless
>                  PCS subscriber "roaming" in another
>                  cellular/wireless PCS network, over type 2
>                  trunks through the local exchange carrier
>                  access tandem for delivery to the
>                  interexchange carrier. (Note: Use of "63"
>                  signifies that the "called number" is used only
>                  for network routing and should not be disclosed
>                  to the cellular/wireless PCS subscriber. Also,
>                  ANI information accompanying digit pair "63"
>                  identifies the mobile directory number
>                  forwarding the call but does not necessarily
>                  identify the true forwarded-call point of origin.)
>     64-65  Unassigned
>     66         TRS - ANI II digit pair 66 indicates that the
>                  associated call is a TRS call delivered to a
>                  transport carrier from a TRS Provider, and that
>                  the call originates from a hotel/motel. The
>                  transport carrier can use this indication, along
>                  with other information (e.g., whether the call
>                  was dialed 1+ or 0+) to determine the
>                  appropriate billing arrangement (i.e., bill to room
>                  or alternate bill).
>     67         TRS - ANI II digit pair 67 indicates that the
>                  associated call is a TRS call delivered to a
>                  transport carrier from a TRS Provider and that
>                  the call originated from a restricted line.
>                  Accordingly, sent paid calls should not be
>                  allowed and additional screening, if available,
>                  should be performed to determine the specific
>                  restrictions and type of alternate billing
>                  permitted.
>     68-69  Unassigned
>     70         Code 70 identifies a line connected to a pay
>                  station (including both coin and coinless
>                  stations) which does not use network provided
>                  coin control signaling. II 70 is used to identify
>                  this type pay station line irrespective of
>                  whether the pay station is provided by a LEC
>                  or a non-LEC. II 70 is transmitted from the
>                  originating end office on all calls made from
>                  these lines.
>     71-79  Unassigned
>     80-89   Reserved for Future Expansion "to" 3-digit
>                  Code
>     90-92  Unassigned
>     93         Access for private virtual network types of
>                  service: the ANI code "93" indicates, to the IC,
>                  that the originating call is a private virtual
>                  network type of service call.
>     94         Unassigned
>     95         Unassigned - conflict with Test Codes 958 and
>                  959
>     96-99  Unassigned
>
> thanks for your help,
> Bryan
>
> Bryan J. Byerly
> [email-masked]
>