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

["Sumit Garg" <[e-mail]>]

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

 

                     

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