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

From: "Sumit Garg" <[email-masked]>
Date: Fri, 28 Mar 2008 14:09:10 -0400

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:[email-masked]] 
Sent: Friday, March 28, 2008 12:10 PM
To: DOLLY, MARTIN C, sbcuid; Sumit Garg; [email-masked];
[email-masked]
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: +44 7801723668 
[email-masked] 

________________________________

_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: "DOLLY, MARTIN C, sbcuid" <[email-masked]>
Date: Fri, 28 Mar 2008 13:14:43 -0500

Sumit,
 
For as long as the values are clear, this approach would be acceptable.
 
Martin

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sumit Garg
Sent: Friday, March 28, 2008 2:09 PM
To: [email-masked]; [email-masked]
Subject: Re: [Sipping] draft-mahy-iptel-cpc

-Sumit

Martin,

Ian Elz 

System Manager 
DUCI LDC UK 
(Lucid Duck)

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Mar 2008 17:36:58 -0400

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:
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Sumit Garg
> *Sent:* Friday, March 28, 2008 2:09 PM
> *To:* [email-masked]; [email-masked]
> *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
> 
> The way a lot of stuff is done in tel-uri might be useful….
> 
>  
> 
>                 Renamed /to user-type as we do not necessarily tie it to 
> originating side…..we might find other needs in the future./
> 
>  
> 
> implicit…they would implicitly know whether  it is cpc/oli.
> 
>  
> 
> -Sumit
> 
>  
> 
>  
> 
> *From:* Ian Elz [mailto:[email-masked]]
> *Sent:* Friday, March 28, 2008 12:10 PM
> *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; [email-masked]; [email-masked]
> *Subject:* RE: [Sipping] draft-mahy-iptel-cpc
> 
>  
> 
> Martin,
> 
>  
> 
> to reduce the different CCITT operator CPC values by using ‘language’ in 
> /Ian Elz/
> /System Manager/
> /DUCI LDC UK/
> /(Lucid Duck)/
> /Office: + 44 24 764 35256/
> /gsm: +44 7801723668/
> /[email-masked]/
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Sat, 29 Mar 2008 19:38:29 -0500

It does NOT meet the USA needs, if the ITEF says f''you, then we ......

From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Saturday, March 29, 2008 7:26 PM
To: DOLLY, MARTIN C, ATTLABS; Sumit Garg; [email-masked];
[email-masked]
Subject: RE: [Sipping] draft-mahy-iptel-cpc

My understanding of the cpc work in iptel is that is currently held
pending the approval of the internet draft defining the approval regime
for tel URI parameters. I believe the current status of this is to make
the approval of tel URI parameters standards track required, although
that could have altered - not in a position to look it up currently.
 
Which brings us to the next issue in that I understand that at least
some of the TISPAN people want to use this as a SIP URI parameter as
well as a tel URI parameter. These are two distinct sets of parameters
and therefore a tel URI parameter does not automatically become a SIP
URI parameter.
 
Is this so? Are there any indications which we want to be able to use
with SIP URIs as well as tel URIs.
 
regards
 
Keith

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of DOLLY, MARTIN C, sbcuid
	Sent: Friday, March 28, 2008 6:15 PM
	To: Sumit Garg; [email-masked]; [email-masked]
	Subject: Re: [Sipping] draft-mahy-iptel-cpc

	Sumit,
	 
	For as long as the values are clear, this approach would be
acceptable.
	 
	Martin

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sumit Garg
	Sent: Friday, March 28, 2008 2:09 PM
	To: [email-masked]; [email-masked]
	Subject: Re: [Sipping] draft-mahy-iptel-cpc

	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.

	A global number inherently has a country code which would help
decide the valid values (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

	Martin,

	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)

---

From: "Sumit Garg" <[email-masked]>
Date: Mon, 31 Mar 2008 10:34:27 -0400

I see the following areas of concern:

i.)                  cpc/oli and overlap in values:

        I do not really see a major issue, I see the problem if the
values were being conveyed in number format, in text format I do not see
any reason

        why a value would be misinterpreted...a value which is not
understood would automatically be inferred as default as per the policy
at the receiver.

       I do not see a major concern in PSTN-SIP direction. In the SIP to
PSTN direction, there can never be any concern for non-overlapped
values...for the 

      Overlapped values..it is a matter of implementation, local
predefined policy at the UAS or it making a decision based on
country-code (in the   

      E.164) /phone-context.

i.)                  Should it be part of P-A-I??

                I believe what we intend to define is the URI
parameter....which particular header to use is more of an implementation
guideline, the CPC would generally

                be in P-A-I....but the implementation could pick another
Header if it likes. For e.g. in PacketCable world, P-DCS-Billing-Info
could also be used as it carrier 

                info about not only the charge party, but also the
calling party.  From Header would generally be a bad idea, but, again it
depends on the trust-relationship 

               UAS has with the UAC.  When OLI is being conveyed there
are lots of extra options (Referred-By, Billing-Info, History-Info and
even the P-A-I). SIP as opposed to ISUP provides us the freedom to carry
this information derived from every leg if need be.

ii.)                 SIP URI parameter Vs. tel-URI parameter:

 This is the most interesting case. Do we expect the information
conveyed to be useful only in interworking scenarios or could it prove
to be useful in pure SIP scenarios too?   If  the thinking is that such
information would be useful in pure SIP environments...then it would
probably make sense to have it as a SIP URI parameter. The interworking
case would still work without issues....as a telephony information can
always be conveyed in a SIP URI, but the reverse is not true.

I would prefer having 1 mapping parameter either SIP/TEL rather than
whetever TISPAN is trying to do.

-Sumit

regards

Keith

	Sumit,

	Martin

	-Sumit

	Martin,

	Ian Elz 

	System Manager 
	DUCI LDC UK 
	(Lucid Duck)