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

From: "Sumit Garg" <[email-masked]>
Date: Thu, 27 Mar 2008 09:46:37 -0400

Over a period of time I have seen various efforts in that direction
which eventually get dropped...to list a few:

draft-schubert-sipping-saml-cpc-02.txt (Expired: jan 2007)

draft-mahy-iptel-cpc-06.txt (Expired:Sep 2007)

draft-ietf-sip-privacy-04.txt , Appendix A (Expired: 2002)

draft-rocky-sipping-calling-party-category-01.txt (Expired : 2006)

I've also seen implementation using parameters  like isup-oli for which
I could not even find a draft.

Based on this I believe conveying CPC/OLI in SIP is a real requirement.

Maybe for pure SIP scenario it could be done with caller-preferences,
but not in interworking scenarios.

From what I understand:

1. CPC in ISUP could be desired by the terminating exchange, however,
the scope of the OLI is only 1 call-leg and could be different from CPC
as it is more closely tied to the billing number.

3. CPC is ISUP only, OLI could be over MF also.

I don't really care what the tag-name in use is (oli/cpc)but, from where
I am looking I would say:

1.       cpc-param in P-Asserted-Id corresponds to cpc in ISUP (Better
than in From header as it is a tel-uri parameter).

2.       cpc-param in
History-Info/Diversion/P-DCS-Billing-Info/Referred-By etc. etc. could
correspond to OLI.

Is there some way of reaching consensus and moving on...rather than have
more aborted attempts in the future?

-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: [email-masked] [mailto:[email-masked]] On Behalf
Of DOLLY, MARTIN C, ATTLABS
Sent: Thursday, March 27, 2008 8:04 AM
To: Lee, Yiu; [email-masked]; [email-masked]
Subject: Re: [Iptel] draft-mahy-iptel-cpc

Yiu,

There is not a standard way to pass CPC or OLI in SIP? Also,
draft-mahy-iptel-cpc-06.txt would not meet Nroth American deployment
needs because it blends CPC and OLI.

Martin

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lee, Yiu
Sent: Thursday, March 27, 2008 3:56 AM
To: [email-masked]; [email-masked]
Subject: [Iptel] draft-mahy-iptel-cpc

Hi, 

This draft (draft-mahy-iptel-cpc-06.txt) is expired. Will this draft
become WG item? If not, is there any other standard way to carry CPC or
OLI parameter in SIP? 

Thanks, 
Yiu 

_______________________________________________
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: "Sumit Garg" <[email-masked]>
Date: Fri, 28 Mar 2008 09:12:43 -0400

I was surprised by the lack of responses.

This is a real need as I believe intermediate exchanges could need
special processing for calls from Prison etc.

The reason I proposed using P-A-I as opposed to From header in the draft
was:

In case of anonymous calls, the From header is generally of the form
anonymous@.......

A derived tel-Uri with cpc would look like anonymous;cpc=payphone

This violates the tel-URI syntax. P-Asserted-Id covers this scenario as
well.

If there is a defined standard mechanism for this requirement, could
somebody please point me to the same?

-Sumit

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sumit Garg
Sent: Thursday, March 27, 2008 9:47 AM
To: [email-masked]; [email-masked]
Subject: Re: [Iptel] draft-mahy-iptel-cpc

From what I understand:

2.       cpc-param in

-Sumit

Yiu,

Martin

Hi, 

Thanks, 
Yiu

---

From: "DOLLY, MARTIN C, sbcuid" <[email-masked]>
Date: Fri, 28 Mar 2008 08:50:02 -0500

Sumit,
 
What is really needed is OLI & CPC for North American deployments.
Prisons is an OLI value, not a CPC value. That is the issue with the cpc
draft it mixes up two different parameters. OLI is what type of line,
where CPC is call type ( for the most part).
 
Martin

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

-Sumit

From what I understand:

2.       cpc-param in

-Sumit

Yiu,

Martin

Hi, 

Thanks, 
Yiu

---

From: "Jesske, R" <[email-masked]>
Date: Fri, 28 Mar 2008 14:58:24 +0100

Hi,
nevertheless what is the status now of cpc? Because cpc is needed in some cases like ieps of payphone.
And we could add the OLI.
 
Thanks and Best Regards
 
Roland

	Von: [email-masked] [mailto:[email-masked]] Im Auftrag von DOLLY, MARTIN C, sbcuid
	Gesendet: Freitag, 28. März 2008 14:50
	An: Sumit Garg; [email-masked]; [email-masked]
	Betreff: Re: [Sipping] draft-mahy-iptel-cpc

	Sumit,
	 
	What is really needed is OLI & CPC for North American deployments. Prisons is an OLI value, not a CPC value. That is the issue with the cpc draft it mixes up two different parameters. OLI is what type of line, where CPC is call type ( for the most part).
	 
	Martin

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

	This is a real need as I believe intermediate exchanges could need special processing for calls from Prison etc.

	The reason I proposed using P-A-I as opposed to From header in the draft was:

	In case of anonymous calls, the From header is generally of the form anonymous@.......

	This violates the tel-URI syntax. P-Asserted-Id covers this scenario as well.

	If there is a defined standard mechanism for this requirement, could somebody please point me to the same?

	-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: [email-masked] [mailto:[email-masked]] On Behalf Of Sumit Garg
	Sent: Thursday, March 27, 2008 9:47 AM
	To: [email-masked]; [email-masked]
	Subject: Re: [Iptel] draft-mahy-iptel-cpc

	Over a period of time I have seen various efforts in that direction which eventually get dropped...to list a few:

	I've also seen implementation using parameters  like isup-oli for which I could not even find a draft.

	Maybe for pure SIP scenario it could be done with caller-preferences, but not in interworking scenarios.

	From what I understand:

	1. CPC in ISUP could be desired by the terminating exchange, however, the scope of the OLI is only 1 call-leg and could be different from CPC as it is more closely tied to the billing number.

	I don't really care what the tag-name in use is (oli/cpc)but, from where I am looking I would say:

	1.       cpc-param in P-Asserted-Id corresponds to cpc in ISUP (Better than in From header as it is a tel-uri parameter).

	2.       cpc-param in History-Info/Diversion/P-DCS-Billing-Info/Referred-By etc. etc. could correspond to OLI.

	Is there some way of reaching consensus and moving on...rather than have more aborted attempts in the future?

	-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: [email-masked] [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C, ATTLABS
	Sent: Thursday, March 27, 2008 8:04 AM
	To: Lee, Yiu; [email-masked]; [email-masked]
	Subject: Re: [Iptel] draft-mahy-iptel-cpc

	Yiu,

	There is not a standard way to pass CPC or OLI in SIP? Also, draft-mahy-iptel-cpc-06.txt would not meet Nroth American deployment needs because it blends CPC and OLI.

	Martin

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Lee, Yiu
	Sent: Thursday, March 27, 2008 3:56 AM
	To: [email-masked]; [email-masked]
	Subject: [Iptel] draft-mahy-iptel-cpc

	Hi, 

	This draft (draft-mahy-iptel-cpc-06.txt) is expired. Will this draft become WG item? If not, is there any other standard way to carry CPC or OLI parameter in SIP? 

	Thanks, 
	Yiu

---

From: "Sumit Garg" <[email-masked]>
Date: Fri, 28 Mar 2008 11:23:51 -0400

If people agree on the need, and mixed usage is the only road-block what is preventing us from having 2 parameters.....maybe in the next version of the draft?

-Sumit

From: Jesske, R [mailto:[email-masked]] 
Sent: Friday, March 28, 2008 9:58 AM
To: [email-masked]; Sumit Garg; [email-masked]; [email-masked]
Subject: AW: [Sipping] draft-mahy-iptel-cpc

Hi,

Thanks and Best Regards

Roland

	Sumit,

	Martin

	-Sumit

	From what I understand:

	-Sumit

	Yiu,

	Martin

	Hi, 

	Thanks, 
	Yiu

---

From: "Ian Elz" <[email-masked]>
Date: Fri, 28 Mar 2008 16:35:57 +0100

Sumit,

If you have two parameters then you start to introduce the same problems which occurred with ANSI and ETSI ISUP - two similar but different protocols. The two similar but different parameters in ISUP should be converted into one in SIP. As long as the capability to support both existing parameters is included then merging the different versions should not be an issue.

The usage when working with the different ISUP versions can then be handled by the interworking function. 

Look at the 3GPP interworking documentation TS 29.163 Appendix C which references this draft to see how the interworking is proposed. This only shows ETSI CPC values but it does include a default handling. The same issues will currently occur in the PSTN/ISDN between ANSI and ETSI ISUP.

Ian Elz 

System Manager 
DUCI LDC UK 
(Lucid Duck) 

Office: + 44 24 764 35256 
gsm: +44 7801723668 
[email-masked] 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sumit Garg
Sent: 28 March 2008 15:24
To: [email-masked]; [email-masked]
Subject: Re: [Sipping] draft-mahy-iptel-cpc

-Sumit

Hi,

Thanks and Best Regards

Roland

	Sumit,

	Martin

	-Sumit

	From what I understand:

	-Sumit

	Yiu,

	Martin

	Hi, 

	Thanks, 
	Yiu

---

From: "DOLLY, MARTIN C, sbcuid" <[email-masked]>
Date: Fri, 28 Mar 2008 10:49:17 -0500

Below is OLI and CPC Values:

OLI - ANSI only

Information sent in the forward direction indicating toll class of service. The format of the originating line information parameter is shown below. 

8

7

6

5

4

3

2

1

1

Originating line information

The codes used in the originating line information parameter field are the binary equivalents of the decimal codes used in the II digits of the ANI sequence for in-band signaling system.  The decimal codes are assigned and administered by the North American Numbering Plan Administrator. 

As new decimal codes are assigned, their binary equivalents will automatically be assigned as codes in the originating line information parameter field

(DEC)

NANPA Term

0000 0000

(00)

POTS

0000 0001

(01)

ONI (multiparty line)

0000 0010

(02)

ANI failure (unavailable)

0000 0110

(06)

hotel/motel (without room identification)

0000 0111

(07)

special operator handling required

0000 1010

(10)

test call

0001 0100

(20)

Automatic Identified Outward Dialing (AIOD) - listed DN sent

0001 0111

(23)

coin or non-coin (identified line)

0001 1000

(24)

toll-free translated to POTS from non-pay station

0001 1001

(25)

toll-free translated to POTS from any pay station

0001 1011

(27)

coin line (Note a)

0001 1101

(29)

prison/inmate service (Note a)

0001 1110

(30)

intercept (blank)

0001 1111

(31)

intercept (trouble)

0010 0000

(32)

intercept (regular)

0010 0010

(34)

telco operator handled call

0010 0100

(36)

CPE

0011 0100

(52)

OUTWATS

0011 1100

(60)

TRS (unrestricted line)

0011 1101

(61)

cellular service (type 1) - cellular carrier identified

0011 1110

(62)

cellular service (type 2) - mobile DN identified

0011 1111

(63)

cellular service (roaming)

0100 0010

(66)

TRS (hotel/ motel)

0100 0011

(67)

TRS (restricted line)

0100 0110

(70)

private paystations (Note a)

0101 1101

(93)

private virtual network

Note a: The North American Numbering Plan Administrator intends to replace codes 27, 29, and 70 with code 25 if the call originates from a pay station.

1.1        Calling Party's Category

(ITU-T/ ANSI)

Information sent in the forward direction indicating the category of the calling party and, in case of semiautomatic calls, the service language to be spoken by the incoming, delay and assistance operators. The format of the calling party's category is shown below.

8

7

6

5

4

3

2

1

1

Calling party's category (gen.1)

The following codes are used in the calling party's category parameter field (gen.1).

CCITT- ITU use

00000000

calling party's category unknown (Note (a)) (national use)

00000001

operator, language French (Note (b))

00000010

operator, language English (Note (b))

00000011

operator, language German (Note (b))

00000100

operator, language Russian (Note (b))

00000101

operator, language Spanish (Note (b))

00000110

reserved for Administrations for selecting a particular language by mutual agreement

00000111

reserved for Administrations for selecting a particular language by mutual agreement

00001000

reserved for Administrations for selecting a particular language by mutual agreement

00001001

reserved (see CCITT Rec. Q.104) (national use)

00001010

ordinary calling subscriber (gen.1)

00001011

calling subscriber with priority (Note (b))

00001100

data call (voice band data) (Note (c))

00001101

test call (gen.1)

00001110

spare

00001111

payphone (Note (b))

00010000

to

CCITT spare

11011111

ANSI use

11100000

emergency service call

11100001

high priority emergency service call

11100010

national security and emergency preparedness (NS/EP) call

11100011

to

ANSI spare

11101111

Network specific use

11110000

to

network specific use

11111000

11111001

AT&T specific

11111010

to

network specific use

11111101

11111110

AT&T specific

11111111

reserved for expansion

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

-Sumit

Hi,

Thanks and Best Regards

Roland

	Sumit,

	Martin

	-Sumit

	From what I understand:

	-Sumit

	Yiu,

	Martin

	Hi, 

	Thanks, 
	Yiu

---

From: "DOLLY, MARTIN C, sbcuid" <[email-masked]>
Date: Fri, 28 Mar 2008 11:00:33 -0500

Ian,
 
We need the OLI values supported in North America.
 
Martin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ian Elz
Sent: Friday, March 28, 2008 11:36 AM
To: Sumit Garg; [email-masked]; [email-masked]
Subject: Re: [Sipping] draft-mahy-iptel-cpc

Sumit,

Ian Elz 

System Manager 
DUCI LDC UK 
(Lucid Duck) 

-Sumit

Hi,

Thanks and Best Regards

Roland

	Sumit,

	Martin

	-Sumit

	From what I understand:

	-Sumit

	Yiu,

	Martin

	Hi, 

	Thanks, 
	Yiu

---

From: "Ian Elz" <[email-masked]>
Date: Fri, 28 Mar 2008 17:09:50 +0100

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) 

From: DOLLY, MARTIN C, sbcuid [mailto:[email-masked]] 
Sent: 28 March 2008 16:01
To: Ian Elz; Sumit Garg; [email-masked]; [email-masked]
Subject: RE: [Sipping] draft-mahy-iptel-cpc

Ian,

Martin

Sumit,

Ian Elz 

System Manager 
DUCI LDC UK 
(Lucid Duck) 

-Sumit

Hi,

Thanks and Best Regards

Roland

	Sumit,

	Martin

	-Sumit

	From what I understand:

	-Sumit

	Yiu,

	Martin

	Hi, 

	Thanks, 
	Yiu

---

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

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 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: "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]/
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 30 Mar 2008 00:25:59 +0100

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

 
 
regards
 
Keith

	Sumit,

	Martin

	-Sumit

	Martin,

	Ian Elz 

	System Manager 
	DUCI LDC UK 
	(Lucid Duck)

---

From: "Ian Elz" <[email-masked]>
Date: Mon, 31 Mar 2008 15:33:03 +0200

Paul,

You are now stretching the requirements for CPC/OLI beyond what is now
supported in 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.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: 28 March 2008 21:37
To: DOLLY, MARTIN C, sbcuid
Cc: [email-masked]; [email-masked]
Subject: Re: [Sipping] draft-mahy-iptel-cpc

	Paul

acceptable.

> originating side.....we might find other needs in the future./
> 
>  
> 
proposed

---

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)

---

From: Ted Hardie <[email-masked]>
Date: Mon, 31 Mar 2008 08:50:01 -0700

At 4:25 PM -0700 3/29/08, DRAGE, Keith (Keith) wrote:
>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.
> 

The draft is at :

http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-05.txt

In the new version of the draft, the registration policy stuff is in 4.2:

4.2.  Registration Policy for tel URI Parameters

   As per the terminology in [6] and actions accorded to such a role,
   the registration policy for tel URI parameters shall be
   "Specification Required, Designated Expert" (the former implicitly
   implies the latter.)

   The Designated Expert when deliberating on whether to include a new
   parameter in the tel URI registry may use the criteria provided below
   to reach a decision (this is not an exhaustive list but
   representative of the issues to consider when rendering an equitable
   decision):

   o  If the tel URI -- with the parameter under consideration -- will
      be converted to a URI used by other signaling protocols such as
      the Session Initiation Protocol (SIP [4]) or H.323 [7], then the
      expert must consider whether this parameter merely encapsulates
      signaling information that is not meaningful to the processing of
      requests in the domain of the converted URI.  For example, certain
      Integrated Services Digital Network (ISDN) User Part (ISUP, [8])
      parameters have no equivalent corollary in SIP; thus their
      presence or absence in a SIP URI will not hinder the normal rules
      for processing that URI.  Other parameters may affect the normal
      processing rules associated with the URI; in such cases, the
      expert must consider carefully the ramifications, if any, of the
      presence of such parameters.

   o  Certain parameters of a tel URI can be optional.  These parameters
      act as metadata about the identifier in the tel URI.  Optional
      parameters should provide additional information to a service for
      which they apply instead of acting as enablers of that service in
      the first place.  The service must continue to be invoked and
      operate normally even in the absence of these parameters.

			regards,
				Ted
>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
>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.
> 
>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)
>For implementations which use neither..i.e. for which context is implicitŠthey would implicitly know whether  it is cpc/oli.
> 
>-Sumit
> 
> 
>To: DOLLY, MARTIN C, sbcuid; Sumit Garg; [email-masked]; [email-masked]
>Content-Type: text/plain; name="ATT00001.txt"
>Content-Description: ATT00001.txt
>Content-Disposition: attachment; filename="ATT00001.txt"; size=358;
>	creation-date="Sat, 29 Mar 2008 16:26:41 GMT";
>	modification-date="Sat, 29 Mar 2008 16:26:41 GMT"
>
>Attachment converted: Macintosh HD:ATT00001 878.txt (TEXT/ttxt) (00728182)

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Mar 2008 12:50:28 -0400

> You are now stretching the requirements for CPC/OLI beyond what is now

Is CPC just for ISUP?

> to define one value as primary and others as secondary to allow correct

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

---

From: "Ian Elz" <[email-masked]>
Date: Tue, 1 Apr 2008 10:58:29 +0200

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)

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

Is CPC just for ISUP?

	Paul

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Tue, 1 Apr 2008 07:16:15 -0500

Ian,

CPC: Information sent in the forward direction indicating the category
of the calling party and, in case of semiautomatic calls, the service
language to be spoken by the incoming, delay and assistance operators.
The format of the calling party's category is shown below.

OLI:  Information sent in the forward direction indicating toll class of
service. Identification of the originating line.

Martin

-----Original Message-----
From: Ian Elz [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2008 4:58 AM
To: Paul Kyzivat
Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS; [email-masked]
Subject: RE: [Sipping] draft-mahy-iptel-cpc

Paul,

The introduction begins:

Ian Elz

---

From: "Ian Elz" <[email-masked]>
Date: Tue, 1 Apr 2008 14:20:35 +0200

Martin,

Sorry my choice of words. 'back to ISUP' was not meant to imply a
backward direction message but where the interworking from SIP -> ISUP.

ISUP -> SIP working is easy as ISUP will only contain one value but if
SIP contains multiple values as Paul has suggested then we need to be
able to map these to a single value in ISUP.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

-----Original Message-----
From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
Sent: 01 April 2008 13:16
To: Ian Elz; [email-masked]; [email-masked]
Subject: RE: [Sipping] draft-mahy-iptel-cpc

Ian,

Martin

-----Original Message-----
From: Ian Elz [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2008 4:58 AM
To: Paul Kyzivat
Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS; [email-masked]
Subject: RE: [Sipping] draft-mahy-iptel-cpc

Paul,

The introduction begins:

Ian Elz