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:drage at alcatel-lucent.com]
Sent: Saturday, March 29, 2008 7:26 PM
To: DOLLY, MARTIN C, ATTLABS; Sumit Garg; iptel at ietf.org;
sipping at ietf.org
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: sipping-bounces at ietf.org
[mailto:sipping-bounces at ietf.org] On Behalf Of DOLLY, MARTIN C, sbcuid
Sent: Friday, March 28, 2008 6:15 PM
To: Sumit Garg; iptel at ietf.org; sipping at ietf.org
Subject: Re: [Sipping] draft-mahy-iptel-cpc
Sumit,
For as long as the values are clear, this approach would be
acceptable.
Martin
From: sipping-bounces at ietf.org
[mailto:sipping-bounces at ietf.org] On Behalf Of Sumit Garg
Sent: Friday, March 28, 2008 2:09 PM
To: iptel at ietf.org; sipping at ietf.org
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:ian.elz at ericsson.com]
Sent: Friday, March 28, 2008 12:10 PM
To: DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel at ietf.org;
sipping at ietf.org
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
ian.elz at ericsson.com