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

From: [email-masked]
Date: Mon, 16 Sep 2002 08:38:24 -0400

With this sort of discussion, isn't there a danger that SIP will evolve
into a newer version of ISUP? What should be in a base SIP specification
and what should be left as extensions for the various application
architectures that will utilise SIP?

Tom Gray

Henning Schulzrinne <[email-masked]>@ietf.org on 09/13/2002 01:18:59
PM

Sent by:  [email-masked]

To:   Michael Hammer <[email-masked]>
cc:   "Jesske, R" <[email-masked]>, [email-masked],
      [email-masked], [email-masked], [email-masked]
Subject:  Re: AW: [Sipping] Re: [Sip] Originating Line Information

This seems like another version of the *-Info header field, as it
describes a particular request.

Michael Hammer wrote:
> 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

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Sep 2002 08:57:30 -0400

That's why I was trying to abstract the problem. So, rather than 
creating a direct mapping from ISUP CPC to some SIP element, I'd prefer 
to look at the more generic question of how to convey properties of the 
call and caller. There seem to be at least four approaches:

- The SIP URI in the From field. I believe we agreed that URIs are 
*identifiers*, not descriptors, so they should contain only enough 
information to uniquely identify the resource. (Unless 
[email-masked];type=motel and [email-masked];type=prison are distinct 
individuals, rather than the same person before and after the G-men 
knocked on the door, this shouldn't be part of the URI.)

- Caller preferences. Advantage is that this can be part of the 
registration, can be used in call routing and we already have means to 
test for this in CPL scripts.

- Some kind of *-Info header. Seems mostly useful for values, such as 
URIs, rather than flags.

---

From: [email-masked]
Date: Mon, 16 Sep 2002 16:17:54 +0300

[email-masked] writes:

 > into a newer version of ISUP? 

tom,

we have already lost the battle.  sip has already evolved with the
blessing of ietf into a building block (brick) of a new version of the
closed mobile network.

-- juha

---

From: Michael Hammer <[email-masked]>
Date: Mon, 16 Sep 2002 11:20:41 -0400

Heaven forbid that past experience should guide us.

Even in an end-to-end model, I would still like to know if a call is coming 
from a prison.  It would be even better if it were regulated to be tagged 
as "telemarketer" so I could filter that out!  :)

Mike

---

From: Al Varney <[email-masked]>
Date: Tue, 17 Sep 2002 11:17:27 -0500

At 11:20 AM 9/16/02 -0400, Michael Hammer wrote:
>Even in an end-to-end model, I would still like to know if a call is 
>coming from a prison.  It would be even better if it were regulated to be 
>tagged as "telemarketer" so I could filter that out!  :)

Mike,

    Just a few comments on OLI and CPC.  I'm sure you are aware of some of 
this.

1) ISUP OLI is the SS7 encoding of the ANI Information codes ("II digits") 
from the ANSI/Telcordia Equal Access MF signaling protocol.  These are 
primarily used for call records and to block or alter handling of calls for 
alternative billing purposes.  It seldom affects call routing, except to 
redirect to an Operator or announcement.  OLI is often dropped when the 
call leaves the exchange or network responsible for billing; it is seldom 
delivered to the terminating exchange.

2) Unlike CPC (associated with the calling party), OLI is associated with 
the billing number and a particular "leg" of the call.  When calls are 
redirected (call forwarding, for example), the CPC/Calling Party is 
unchanged but the OLI and billing number will be updated to the redirecting 
party (who typically pays for the redirected "leg" of the call).  So the 
CPC and OLI can represent different parties.  Also, call treatment can 
alter the OLI/II digits in mid-call -- for example, OLI/II=24 represents a 
Toll-free call after the toll-free number is translated to the real 
destination number.

3) CPC is transported only over ISUP, while OLI/II digits can also be 
transported over some MF facilities.

4) The "prison" tag doesn't apply to all calls from a prison, only to lines 
used for prisoner-placed calls.  The primary reason for such a tag is to 
allow long-distance companies (and local Operators) to deny various billing 
options to such calls (no third-party or calling card calls, for example).

    A related tale:  My father-in-law told me that he received a call from 
a prisoner last week.  He was asked to dial a special call as a "favor" to 
the prisoner -- a number beginning with "*62...".  This sequence requests 
call forwarding to the remaining digits.  Folks activating this capability 
will allow the prisoner to make subsequent calls to the original number, 
redirecting to their desired destination, but with the "prison" II digits 
replaced with those of the forwarding telephone line.  Thus the "prison" 
OLI is not fool-proof.

Al Varney

---

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

Al,

Thanks for the review.

Now, how would this type of decision making occur in a distributed model 
where many proxies along with the endpoints may share in these decisions as 
opposed to a single originating or terminating exchange?  Where is the 
exchange?  Where is the billing information generated?

What happens when my billing and control is in a SIP-to-ISUP GW that is 
acting as a SIP endpoint and may be the first node in the signaling path 
that cares about such information?

Is there some 3pcc application in the middle of the SIP network that needs 
this information to decide whether and how to route the prison call?

I'm not sure my crystal ball is as clear as others, but I would bet that 
some of this information might be useful.

However, some drilling down on what is really needed would be useful.  Some 
of your examples point out that the information is used to identify 
indirectly the bill-to party.  There are perhaps better parameters that 
could be used to explicitly identify such parties directly.

Mike

At 11:17 AM 9/17/2002 -0500, Al Varney wrote:
>primarily used for call records and to block or alter handling of calls 
>for alternative billing purposes.  It seldom affects call routing, except 
>to redirect to an Operator or announcement.  OLI is often dropped when the 
>unchanged but the OLI and billing number will be updated to the 
>redirecting party (who typically pays for the redirected "leg" of the 
>call).  So the CPC and OLI can represent different parties.  Also, call 
>treatment can alter the OLI/II digits in mid-call -- for example, 
>OLI/II=24 represents a Toll-free call after the toll-free number is 
>translated to the real destination number.
>
>4) The "prison" tag doesn't apply to all calls from a prison, only to 
>lines used for prisoner-placed calls.  The primary reason for such a tag 
>is to allow long-distance companies (and local Operators) to deny various 
>billing options to such calls (no third-party or calling card calls, for 
>example).
>
> a prisoner last week.  He was asked to dial a special call as a "favor" 
> to the prisoner -- a number beginning with "*62...".  This sequence 
> requests call forwarding to the remaining digits.  Folks activating this 
> capability will allow the prisoner to make subsequent calls to the 
> original number, redirecting to their desired destination, but with the 
> "prison" II digits replaced with those of the forwarding telephone 
> line.  Thus the "prison" OLI is not fool-proof.
>
>Al Varney
>
>

---

From: Al Varney <[email-masked]>
Date: Tue, 17 Sep 2002 15:52:53 -0500

At 03:49 PM 9/17/02 -0400, Michael Hammer wrote:
>where many proxies along with the endpoints may share in these decisions 
>as opposed to a single originating or terminating exchange?  Where is the 

    Good questions.  In most old-fashioned telephone networks, those 
questions were answered (or the architecture and interfaces agreed) before 
any protocol was invented.  Billing information is generated in multiple 
exchanges, and feature-based decisions can be made at intermediate 
exchanges as well as in the originating and terminating exchanges.  (So in 
that sense, the PSTN itself is a distributed model.)

    Designing a new all-purpose protocol for a not-yet-defined distributed 
model, when there may be billing and application logic inside the model 
(not just at the edges) is a tough exercise.  Using the same protocol rules 
for edge-access devices and for internal node-to-node communication 
probably complicates things further.  When you also try to use this new 
protocol to interact with existing PSTN interfaces, you add other issues 
regarding reliability, cost and information sharing, legal and tariff 
requirements and cross-border differences.

>that cares about such information?

    Don't know.  Who is the customer, and what service are they 
purchasing?  At the other end, what information and assurances are you 
giving down-stream ISUP networks regarding the reliability of the 
information you are passing them?  Obviously, if you are willing to pay 
(and pass along to the caller) any and all costs incurred by downstream 
networks, they might not care about these things.  If you want to restrict 
what some of your callers can do inside the PSTN (including via Operators), 
then you need to provide information on which the PSTN can depend.

>However, some drilling down on what is really needed would be 
>useful.  Some of your examples point out that the information is used to 
>identify indirectly the bill-to party.  There are perhaps better 
>parameters that could be used to explicitly identify such parties directly.

    Certainly it makes sense to define what information you want to share, 
and with whom, before you start throwing parameters into the protocol.  I 
think Jon and Jonathan consider OLI and CPC to be too tied to ISUP to be 
directly incorporated in SIP, as do I.

    SIP needs to provide information that would allow an 
originating-SIP-to-ISUP gateway to derive that information when it needs 
it.  In many cases, a default value for CPC and for OLI (if needed at all) 
would be sufficient.  Perhaps a "special case" TEL flag, and a look-up in a 
database based on calling party, would handle all the other cases.  The 
terminating SIP endpoint probably doesn't need OLI or CPC, so retaining the 
values in encapsulated ISUP would be sufficient for both the bridged 
ISUP-to-SIP-to-ISUP case and in the ISUP-to-SIP-endpoint case -- no 
ISUP-to-SIP mapping needed.

Al Varney

>>>coming from a prison.  It would be even better if it were regulated to 
>>>be tagged as "telemarketer" so I could filter that out!  :)
>>
>>Mike,
>>
>>    Just a few comments on OLI and CPC.  I'm sure you are aware of some 
>> of this.
>>
>>1) ISUP OLI is the SS7 encoding of the ANI Information codes ("II 
>>digits") from the ANSI/Telcordia Equal Access MF signaling 
>>protocol.  These are primarily used for call records and to block or 
>>alter handling of calls for alternative billing purposes.  It seldom 
>>affects call routing, except to redirect to an Operator or 
>>announcement.  OLI is often dropped when the call leaves the exchange or 
>>network responsible for billing; it is seldom delivered to the 
>>terminating exchange.
>>
>>    A related tale:  My father-in-law told me that he received a call 
>> from a prisoner last week.  He was asked to dial a special call as a 
>> "favor" to the prisoner -- a number beginning with "*62...".  This 
>> sequence requests call forwarding to the remaining digits.  Folks 
>> activating this capability will allow the prisoner to make subsequent 
>> calls to the original number, redirecting to their desired destination, 
>> but with the "prison" II digits replaced with those of the forwarding 
>> telephone line.  Thus the "prison" OLI is not fool-proof.
>>
>>Al Varney
>>
>>

---

From: Michael Hammer <[email-masked]>
Date: Tue, 17 Sep 2002 17:59:31 -0400

Al,

The problem I see here is the question of whether the design is bottom-up 
or top-down.  Following the top-down design you specify the services and 
what devices do what functions where with what protocol elements and 
values.  From what I have observed with SIP, there could be some headers 
that are not understood by all elements in the path, but may be of use to 
some that are.  These are ignored and passed on by some proxies, usually 
for forwards compatibility reasons.

At the moment, some people appear to characterize this as "that's a PSTN 
feature", "SIP can't/doesn't need to do that", or even "it's dumbed-down 
functionality/protocol capability for SIP".  The question is whether the 
end-user/network need has gone away or whether that need is satisfied 
another way.  All I ask is whether losing a data point in the data set 
provided by signaling results in lost functionality satisfying a long-range 
need.  If the answer is no, then we don't need it.

You seem to be suggesting that we don't really know right now and that for 
the moment encapsulated ISUP may be sufficient, while we see how services 
and networks will evolve.

Mike

At 03:52 PM 9/17/2002 -0500, Al Varney wrote:
> questions were answered (or the architecture and interfaces agreed) 
> before any protocol was invented.  Billing information is generated in 
> multiple exchanges, and feature-based decisions can be made at 
> intermediate exchanges as well as in the originating and terminating 
> exchanges.  (So in that sense, the PSTN itself is a distributed model.)
>
> (not just at the edges) is a tough exercise.  Using the same protocol 
> rules for edge-access devices and for internal node-to-node communication 
> networks, they might not care about these things.  If you want to 
> restrict what some of your callers can do inside the PSTN (including via 
> Operators), then you need to provide information on which the PSTN can depend.
>
>>Is there some 3pcc application in the middle of the SIP network that 
>>needs this information to decide whether and how to route the prison call?
>>
> it.  In many cases, a default value for CPC and for OLI (if needed at 
> all) would be sufficient.  Perhaps a "special case" TEL flag, and a 
> look-up in a database based on calling party, would handle all the other 
> cases.  The terminating SIP endpoint probably doesn't need OLI or CPC, so 
> retaining the values in encapsulated ISUP would be sufficient for both 
> the bridged ISUP-to-SIP-to-ISUP case and in the ISUP-to-SIP-endpoint case 
> -- no ISUP-to-SIP mapping needed.
>
>Al Varney
>
>>>2) Unlike CPC (associated with the calling party), OLI is associated 
>>>with the billing number and a particular "leg" of the call.  When calls 
>>>are redirected (call forwarding, for example), the CPC/Calling Party is 
>>>is to allow long-distance companies (and local Operators) to deny 
>>>various billing options to such calls (no third-party or calling card 
>>>calls, for example).
>>>

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 30 Sep 2002 12:09:07 -0700

On Tuesday, September 17, 2002, at 09:17 AM, Al Varney wrote:

>> coming from a prison.  It would be even better if it were regulated 
>> to be tagged as "telemarketer" so I could filter that out!  :)
>
> Mike,
>
> digits") from the ANSI/Telcordia Equal Access MF signaling protocol.  
> These are primarily used for call records and to block or alter 
> handling of calls for alternative billing purposes.  It seldom affects 
> call routing, except to redirect to an Operator or announcement.  OLI 
> is often dropped when the call leaves the exchange or network 
> responsible for billing; it is seldom delivered to the terminating 
> exchange.
>
> with the billing number and a particular "leg" of the call.  When 
> calls are redirected (call forwarding, for example), the CPC/Calling 
> Party is unchanged but the OLI and billing number will be updated to 
> the redirecting party (who typically pays for the redirected "leg" of 
> the call).  So the CPC and OLI can represent different parties.  Also, 
> call treatment can alter the OLI/II digits in mid-call -- for example, 
> lines used for prisoner-placed calls.  The primary reason for such a 
> tag is to allow long-distance companies (and local Operators) to deny 

Actually if you make a call from the (non-prisoner) waiting area of a 
prison the prison tag is frequently marked as well.  We need to be 
clear on what semantic we really want with these.  Same goes with 
"hotel"  or "mental hospital".

thanks,
-rohan

> calls to the original number, redirecting to their desired 
> destination, but with the "prison" II digits replaced with those of 
> the forwarding telephone line.  Thus the "prison" OLI is not 
> fool-proof.
>
> Al Varney
>
>