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

["DOLLY, MARTIN C, ATTLABS" <[e-mail]>]

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

________________________________

From: DRAGE, Keith (Keith) [mailto:[e-mail]] 
Sent: Saturday, March 29, 2008 7:26 PM
To: DOLLY, MARTIN C, ATTLABS; Sumit Garg; [e-mail];
[e-mail]
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: [e-mail] [mailto:[e-mail]]
On Behalf Of DOLLY, MARTIN C, sbcuid
	Sent: Friday, March 28, 2008 6:15 PM
	To: Sumit Garg; [e-mail]; [e-mail]
	Subject: Re: [Sipping] draft-mahy-iptel-cpc
	
	
	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] 

________________________________

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