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

 &nbsp; &nbsp; &nbsp; &nbsp;   ; &nbsp; &nbsp; Renamed to user-type as we do not necessarily tie it to originating sideR30;..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

 

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 216;language’ in Accept-Contact. There may be options to use similar techniques to enable all the OLI values to be handled correctly.

I agree with Ian, we should avoid multiple parameters.

The way a lot of stuff is done in tel-uri might be usefulR30;.

 

We would only  need 1 parameter:  i.)  user-type=<cpc/oli-values&gt;

 &nbsp; &nbsp; &nbsp; &nbsp;   ; &nbsp; &nbsp; 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&#8230;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

 

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.