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