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

[Paul Kyzivat <[e-mail]>]

Patel, Milan wrote:
> 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). 

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.

> 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. 

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

> 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
>