Subject: Re: [dispatch] FW: New Version Notification for draft-patel-dispatch-cpc-oli-parameter-00

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Mar 2010 09:59:24 -0500

I just got around to reading this draft.
I have all of the concerns that Jon does, plus some others:

Many of these properties are in fact properties of the *call*, not 
properties of the *caller*. That is especially true of the oli values:

- some are a function of the called number rather than the caller:
   * 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

- the value can be assigned mid-call, as a result of call handling:
   * 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.
   * 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".

- (this is not an exhaustive list.)

Putting the value in From is problematic if it is a function of 
something other than the caller. Its even more problematic if it can 
change mid-call, since changing it breaks Identity.

Even when the information is a property of the caller, it seems likely 
that it will often be added by something other than the UAC, since the 
UAC is unlikely to be trusted to provide it.

If this is information that is a property of the call rather than 
caller, and it can change along the signaling path, then IMO it belongs 
in some other header, in a field that may be changed along the path.

Also a NIT:

    The "oli" parameter with value 29 indicates that the device that the
    call is initiated from is located within a prison.  An "oli" with
    value "prison" is equally valid.

The ABNF doesn't permit a value of "prison" for the oli parameter - only 
digits.

Jon Peterson wrote:
> 
> In evaluating proposals to add capabilities to SIP via a tel URI, the 
> first question we ask is, "Would this be useful in SIP requests that do 
> NOT use telephone numbers?" If the answer is "yes," then probably the 
> capability should be added to SIP in a way that works with and without 
> the tel URI. (The draft is very slightly unclear  about whether or not 
> you can include this parameter in SIP URIs that do not contain embedded 
> tel URIs but do contain non-tel-URI representations of telephone numbers 
> - but I'm speaking here to the overall intention to couple the use of 
> OLI/CPC information to telephone numbers exclusively.)
> 
> While the draft focuses on the use case where SIP is gatewaying to ISUP, 
> and thus where telephone numbers are likely to be used, I would be 
> hesitant to rule out uses that do not involve telephone numbers - 
> especially when the motivating use case given is REGISTER in an 
> emergency context. Encapsulating the opaque numeric values of OLI into a 
> SIP parameter also more or less restricts the use of this to entities 
> that understand ISUP. This begs the obvious question: should there be a 
> way in SIP (outside of gatewaying)  to express these same concepts? 
> Since you already translate the CPC values into human-readable 
> equivalents ("operator", "payphone", "test"), is there some reason why 
> OLI can't receive the same treatment? The only example of the semantics 
> of OLI that you give ("oli=29" meaning "prison") indeed seems it could 
> admit of that translation. If there is some good reason why CPC should 
> be translated and OLI should be encapsulated, the draft should 
> explicitly motivate it.
> 
> By the by, since the Acks mention that I submitted a version of this 
> proposal prior to Rohan's, just as an historical aside I in fact split 
> that out from the original draft-ietf-sip-privacy-04 by Flemming and 
> Bill Marshall, which for some reason had it tacked into an appendix. The 
> parameter proposed in that document (which can still be found via 
> Google), the Nature of Party ("np") parameter, maps to a set of 
> human-readable literals like "ordinary", "police",  "payphone", 
> "emergency", and so on. The document then proposes a mapping to the ANI 
> II digits; one could just as easily be provided for OLI or CPC in the 
> ISUP variants of interest. The example given in that appendix shows this 
> being used in a URI that doesn't contain a telephone number. In any 
> event, if you want to have a pedigree of the idea in your Acks, you 
> shouldn't leave out that document.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> Milan Patel wrote:
>> Hi,
>>
>> A new version of the Internet Draft for the Calling Party's Category and
>> Originating Line Identity URI Parameters is now available. 
>> http://www.ietf.org/id/draft-patel-dispatch-cpc-oli-parameter-00.txt
>>
>> This is based on Rohan Mahy's draft-mahy-iptel-cpc-06
>>
>> Best regards,
>> Milan
>>
>>
>> -----Original Message-----
>> From: IETF I-D Submission Tool [mailto:[email-masked]] Sent: 08 
>> October 2009 18:40
>> To: Patel, Milan (MOP:EP10)
>> Cc: [email-masked]; [email-masked]
>> Subject: New Version Notification for
>> draft-patel-dispatch-cpc-oli-parameter-00
>>
>> A new version of I-D, draft-patel-dispatch-cpc-oli-parameter-00.txt has
>> been successfuly submitted by Milan Patel and posted to the IETF
>> repository.
>>
>> Filename:     draft-patel-dispatch-cpc-oli-parameter
>> Revision:     00
>> Title:         Uniform Resource Identifier (URI) Parameters for
>> indicating the Calling Party's Catagory and Originating Line Identity
>> Creation_date:     2009-10-08
>> WG ID:         Independent Submission
>> Number_of_pages: 10
>>
>> Abstract:
>> This document defines two new URI parameters to describe the calling
>> party's category and toll class of service originating line
>> information which are parameters also used in SS7 ISUP and other
>> telephony signalling protocols.  The intended use of these URI
>> parameters is for the "tel" URI or equivalent SIP URI representation.
>>  
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>   
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Patel, Milan" <[email-masked]>
Date: Wed, 17 Mar 2010 05:04:43 -0400

Hi Paul,

Thanks for pointing out the NIT. I will address that in the next
revision. 

Your other comments seem to be specific to the semantics of certain OLI
values. That is out of scope of both the internet draft and IETF, since
they were defined elsewhere (ITU-T). 

After receiving Jon's comments, I had extensive discussions with
operators and vendors about the use of CPC and OLI currently in the
field. The current version of the draft reflects such usage and the
syntax of the CPC and OLI as defined in version -02 of the draft has
been scrutinized by operators and vendors attending 3GPP and has
receiving unanimous support. 

The draft defines the CPC and OLI as tel URI parameters. For usage with
SIP URIs, further syntax would need to be defined extending the SIP URI
parameter as defined in RFC 3261. Currently, we see no requirements to
include CPC or OLI for SIP URIs. If this is needed in the future, a
further Internet-Draft can be proposed. 

Regards,
Milan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Wednesday, March 10, 2010 2:59 PM
To: Jon Peterson
Cc: Milan Patel; DISPATCH
Subject: Re: [dispatch] FW: New VersionNotification for
draft-patel-dispatch-cpc-oli-parameter-00

   * 30 Intercept (blank) - for calls to unassigned directory number
(DN)

        billing. The code tells the IC that the BOC has performed
billing
        band(s) on a direct dialed basis for a flat monthly charge or
for

Also a NIT:

digits.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Mar 2010 10:51:41 -0400

> they were defined elsewhere (ITU-T). 

You miss my point. I am not suggesting there is anything wrong with the 
semantics of the values. My point is that values with these semantics do 
not belong in a URI that is being used to describe the originator of a 
call, or in the URI used to describe the destination of the call. They 
are properties of the *call*.

So, these really don't belong in a URI at all. They belong in some other 
header or headers.

> further Internet-Draft can be proposed. 

For those that truly describe properties of a URI (if there are any of 
those), you may be right.

For those that describe properties of a call, if they were carried as 
part of the call rather than as properties of the URI, then it wouldn't 
matter if the URI is sip or tel.

But in reality, even the properties that describe the caller aren't 
properly properties of the caller's URI. For instance, in principle the 
same originating "number" might be used by one phone in a prison and 
another in a police station.

ISTM that piggybacking these on the TEL uri is simply a convenient 
"ploy", because both phone numbers and these properties are managed by 
the ITU.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 17 Mar 2010 19:26:18 -0500

On Mar 17, 2010, at 9:51 AM, Paul Kyzivat wrote:
>>
>
> For those that truly describe properties of a URI (if there are any  
> of those), you may be right.
>
> For those that describe properties of a call, if they were carried  
> as part of the call rather than as properties of the URI, then it  
> wouldn't matter if the URI is sip or tel.
>
> properly properties of the caller's URI. For instance, in principle  
> the same originating "number" might be used by one phone in a prison  
> and another in a police station.
>
> "ploy", because both phone numbers and these properties are managed  
> by the ITU.

Let's run through them:

ordinary: the caller has been identified and has no special features.  
At least not on this call; they might have some on another call, or  
might re-INVITE midstream if they change their mind, so don't count in  
it. Property of "call", not "caller".

Test: This is a test call. If the same guy calls you in 5 minutes, it  
might not be a test. Property of "call", not "caller".

operator: This call was generated by an operator position. Ostensibly,  
the caller is an operator? Probably a property of the "caller". One  
could envision putting this info in RFC 4474.

payphone: The calling station is a payphone. Again, a property of the  
caller.

unknown: I don't know what this means. It's probably got nothing to do  
with the caller.

mobile-hplmn/vplmn: The call was generated by a mobile device  
(property of the calling device, anyhow) in it's home/visited plmn  
(property of this call; doesn't persist if you call it back).

Some of the ANI II digits are things that are properties of a caller.  
Some, like Code 25, are attributes of call and caller. Many seem to  
specify specifc route-handling FOR THIS CALL, like not stripping off a  
leading "63".

So I'm not sure this is a useful categorization.

I'm pretty sure I don't want a "Type 67" modifier attached to A SIP  
URI. I'm also sure that most of these parameters make no sense on a  
TEL URI when that URI is used as a Request-URI; they don't route a  
call. They kindof make sense in a From: URI (or an RFC 4474 Identity  
header field), but they lack reversibility: one couldn't store this  
From: in a phone book, then turn around and call it back 5 minutes  
later. Consequently, the called party MUST understand them, or bad  
things will happen. This calls for an option tag, which is messy.

But I'm at a loss for proposing a better mechanism. Perhaps we could  
follow the SIP-T method and define another extension header field  
carried in the request?

--
Dean

---

From: "Patel, Milan" <[email-masked]>
Date: Thu, 18 Mar 2010 05:59:34 -0400

Hi Dean, Paul,

I now understand your comments about some OLI values characterizing the
call vs caller.

The recommended use of the URI parameter is in the P-Asserted-Identity.
If this is not supported, the OLI can be added in the From header. From
a 3GPP point of view, the OLI would be added to the P-Asserted-Identity
header. The CPC and OLI values are subject to trust domain rules, so
they will not be sent to the called party. It is important they get
interworked at the Media Gateway Control Function to ISUP information
elements.

Regards,
Milan

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Thursday, March 18, 2010 12:26 AM
To: Paul Kyzivat
Cc: Patel, Milan; DISPATCH
Subject: Re: [dispatch] FW: New VersionNotification for

Let's run through them:

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Mar 2010 08:49:50 -0400

inline

Dean Willis wrote:
>> part of the call rather than as properties of the URI, then it 
> ordinary: the caller has been identified and has no special features. At 
> least not on this call; they might have some on another call, or might 
> re-INVITE midstream if they change their mind, so don't count in it. 
> Property of "call", not "caller".
> 

> mobile-hplmn/vplmn: The call was generated by a mobile device (property 
> of the calling device, anyhow) in it's home/visited plmn (property of 
> this call; doesn't persist if you call it back).
> 

I included several others in my earlier post:

Properties of the callee:

The following can be assigned mid-call, as a result of call handling, 
and so are properties of neither the caller nor the callee. I gather 34 
is what Dean is calling "operator". But from the description, the "From" 
will probably still be as supplied by the caller, rather than 
identifying the operator. So again its a (dynamic) property of the call, 
not the caller.

> I'm pretty sure I don't want a "Type 67" modifier attached to A SIP URI. 
> I'm also sure that most of these parameters make no sense on a TEL URI 
> when that URI is used as a Request-URI; they don't route a call. They 
> kindof make sense in a From: URI (or an RFC 4474 Identity header field), 
> but they lack reversibility: one couldn't store this From: in a phone 
> book, then turn around and call it back 5 minutes later. Consequently, 
> the called party MUST understand them, or bad things will happen. This 
> calls for an option tag, which is messy.
> 

Since at least some of this stuff apparently has to change mid-call, I 
think it calls for a new header to carry it.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Mar 2010 09:19:17 -0400

> interworked at the Media Gateway Control Function to ISUP information

Using this in the PAI header does provide a vehicle for mid-call changes.

But it doesn't alter the reality that the PAI also is intended to make 
an assertion about the *caller* while some of this other information is 
about the *call* rather than the caller.

For example, how does it make any sense to include

into the PAI header???

	Thanks,
	Paul

---

From: "WORLEY, DALE R (DALE)" <[email-masked]>
Date: Thu, 18 Mar 2010 14:32:35 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]

   * 31 Intercept (trouble) - for calls to directory numbers (DN) that
        have been manually placed in trouble-busy state by Telco
        personnel
_________________________________________

It's legitimate to add a parameter to the request-URI to modify how the call is routed to its destination, and that covers a number of the CPC cases.  But number 31 above is neither a property of the caller or a modifier of the callee, it's a dynamic (!) attribute of the call itself.  Also, there are data-domain problems, as presumably the "Intercept (trouble)" status can be combined with any caller-type, whereas the value 31 erases any information previously recorded in the CPC.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Mar 2010 15:09:13 -0400

WORLEY, DALE R (DALE) wrote:
> It's legitimate to add a parameter to the request-URI to modify how the call is routed
> to its destination, and that covers a number of the CPC cases. 

It covers those cases *if* the intended use is to insert those 
properties that describe the caller into the PAI, and those that 
describe the callee into the R-URI or To-URI.

But I don't get the impression that is the intent.
Its explicitly stated the the actual content is intended to be opaque.

> But number 31 above is neither a property of the caller or a modifier of the callee,
> it's a dynamic (!) attribute of the call itself.  Also, there are data-domain problems,
> as presumably the "Intercept (trouble)" status can be combined with any caller-type,
> whereas the value 31 erases any information previously recorded in the CPC.

Yeah, even if you try to sort out those parameters that apply to the 
caller vs those that apply to the callee, then the rest don't fit anywhere.

	Thanks,
	Paul