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:
> Sumit,
>
> For as long as the values are clear, this approach
would be acceptable.
>
> Martin
>
>
------------------------------------------------------------
------------
> *From
sipping-bounces ietf.org [mailto:sipping-bouncesietf.org]
*On
> Behalf Of *Sumit Garg
> *Sent Friday,
March 28, 2008 2:09 PM
> *To iptelietf.org;
sippingietf.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.elzericsson.com]
> *Sent Friday,
March 28, 2008 12:10 PM
> *To DOLLY,
MARTIN C, sbcuid; Sumit Garg; iptelietf.org; sippingietf.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.elzericsson.com/
>
>
------------------------------------------------------------
------------
>
>
>
------------------------------------------------------------
------------
>
> _______________________________________________
> Sipping mailing list https:/
/www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of
SIP
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sipietf.org for new developments of core SIP
_______________________________________________
Iptel mailing list
Iptelietf.org
https://w
ww.ietf.org/mailman/listinfo/iptel
|