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

["Patel, Milan" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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

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
> 
_______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch