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

[Paul Kyzivat <[e-mail]>]

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:[e-mail]] Sent: 08 
>> October 2009 18:40
>> To: Patel, Milan (MOP:EP10)
>> Cc: [e-mail]; [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>   
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>