Re: [Sipping] draft-mahy-iptel-cpc

["Ian Elz" <[e-mail]>]

Paul,

My comments are made based upon the content of the latest draft (06).

The introduction begins:

   "SS7 ISUP [4] defines a Calling Party's Category (CPC) parameter that
   characterizes the station used to originate a call and carries other
   important state that can describe the originating party.  When
   telephone numbers are contained in URIs, such as the tel URI [2], it
   may be desirable to communicate any CPC associated with that
   telephone number or, in the context of a call, the party calling from
   it."

Based upon this the current requirement appears to be to support the
ISUP CPC/OLI.

If the requirement is greater than this then that is a discussion that
we should have before the draft is finalized.

The issue with mutual exclusivity exists in the current ISUP
implementations. If that limitation is to be overcome then that
requirement also needs to be discussed. If we are to move from mutual
exclusivity of values then we need to ensure that interworking back to
ISUP is supported. The resolution of the overlapping cases as you have
indicated may have to be at the discretion of the network operator.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: [phone]
[e-mail]

-----Original Message-----
From: Paul Kyzivat [mailto:[e-mail]] 
Sent: 31 March 2008 17:50
To: Ian Elz
Cc: [e-mail]; DOLLY, MARTIN C, sbcuid; [e-mail]
Subject: Re: [Sipping] draft-mahy-iptel-cpc



Ian Elz wrote:
> Paul,
> 
> You are now stretching the requirements for CPC/OLI beyond what is now
> supported in ISUP.

Is CPC just for ISUP?

> In current ISUP it would be possible to have as you correctly describe
a
> police cell phone but only a single value is included.
> 
> If you wish to allow multiple values then we raise an interworking
> problem of which value is used when interworking with ISUP. We may
need
> to define one value as primary and others as secondary to allow
correct
> interworking.

My issue is just to clarify the semantics. The draft as written 
specifies as mutually exclusive alternatives a number of things that on 
the surface don't appear to be mutually exclusive. Nor is it especially 
clear about how these properties are to be determined.

I assume that somehow or other the meaning of these is specified in the 
PSTN. But that isn't of much help to a SIP UA that is trying to 
implement this.

If the semantics can be spelled out in a way that makes it clear how to 
deal with the overlapping cases then so be it. (Does "police" trump 
"cellular" or visa versa? Or is this only to be used in networks where 
there can never be cellular police phones?)

	Paul

> Ian Elz
> 
> System Manager
> DUCI LDC UK
> (Lucid Duck)
> 
> Office: + 44 24 764 35256
> gsm: [phone]
> [e-mail]
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Paul Kyzivat
> Sent: 28 March 2008 21:37
> To: DOLLY, MARTIN C, sbcuid
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Sipping] draft-mahy-iptel-cpc
> 
> As I recall from back when this was a topic of active discussion,
there 
> were significant issues about the semantics of the values.
> 
> I see that Rohan included semantics in the draft. But do they agree
with
> 
> the ones that you are trying to interoperate with?
> 
> One thing I see is that the cpc can have only one value. But the list
of
> 
> values does not seem to be mutually exclusive. For instance, I would 
> think you could have a test call in combination with any of the
others. 
> And you you could have a police call from a cellular phone.
> 
> I suppose none of this is troubling if this is used only for calls 
> sourced from the PSTN, since then the problem of classifying is up to 
> the pstn side. But if a call originates for a sip client, there must
be 
> clear rules for how it is classified.
> 
> Also, how are the classifications authorized? It seems likely that the

> originating device will not be permitted to do it, but rather that
some 
> "trusted" middle box will have to do so.
> 
> And where do you expect this to be put? In P-A-I? If that is the only 
> place where it makes sense, then perhaps a P-A-I header parameter
would 
> make more sense.
> 
> 	Paul
> 
> DOLLY, MARTIN C, sbcuid wrote:
>> Sumit,
>>  
>> For as long as the values are clear, this approach would be
> acceptable.
>>  
>> Martin
>>
>>
>
------------------------------------------------------------------------
>> *From:* [e-mail] [mailto:[e-mail]]
*On
> 
>> Behalf Of *Sumit Garg
>> *Sent:* Friday, March 28, 2008 2:09 PM
>> *To:* [e-mail]; [e-mail]
>> *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
>>
>> I agree with Ian, we should avoid multiple parameters.
>>
>> The way a lot of stuff is done in tel-uri might be useful....
>>
>>  
>>
>> We would only  need 1 parameter:  i.)  user-type=<cpc/oli-values>
>>
>>                 Renamed /to user-type as we do not necessarily tie it
> to 
>> originating side.....we might find other needs in the future./
>>
>>  
>>
>> For the current scenario, the number itself would help the 
>> implementation decide whether it is CPC/OLI.
>>
>> A global number inherently has a country code which would help decide

>> the valid values (cpc/oli)
>>
>> Otherwise the phone-context could be used to decide the same.
>>
>>  
>>
>> For implementations which use neither..i.e. for which context is 
>> implicit...they would implicitly know whether  it is cpc/oli.
>>
>>  
>>
>> -Sumit
>>
>>  
>>
>>  
>>
>> "The reasonable man adapts himself to the world; the unreasonable one

>> persists in trying to adapt the world to himself. Therefore all
> progress 
>> depends on the unreasonable man."
>> -- George Bernard Shaw
>>
>> *From:* Ian Elz [mailto:[e-mail]]
>> *Sent:* Friday, March 28, 2008 12:10 PM
>> *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; [e-mail];
> [e-mail]
>> *Subject:* RE: [Sipping] draft-mahy-iptel-cpc
>>
>>  
>>
>> Martin,
>>
>>  
>>
>> I saw you email with the list of values.
>>
>>  
>>
>> I was not proposing to remove the values but to combine them into an 
>> extended list which encompassed both OLI and CPC. ANSI does not use
> CPC 
>> to any extent while ETSI/CCITT uses CPC for the same purpose as ANSI 
>> uses OLI.
>>
>>  
>>
>> An expanded combined single parameter may be suitable for all the 
>> required values.
>>
>>  
>>
>> If you look at what is proposed by 3GPP you will see that it is
> proposed 
>> to reduce the different CCITT operator CPC values by using 'language'
> in 
>> Accept-Contact. There may be options to use similar techniques to
> enable 
>> all the OLI values to be handled correctly.
>>
>> /Ian Elz/
>>
>> /System Manager/
>> /DUCI LDC UK/
>> /(Lucid Duck)/
>>
>> /Office: + 44 24 764 35256/
>> /gsm: [phone]/
>> /[e-mail]/
>>
>>
>
------------------------------------------------------------------------
>>
>>
>
------------------------------------------------------------------------
>> _______________________________________________
>> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use [e-mail] for questions on current sip
>> Use [e-mail] for new developments of core SIP
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP