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

[Alan Johnston <[e-mail]>]

Paul Kyzivat wrote:
> Francois Audet wrote:
>   
>> Keith,
>>  
>> Tel URI vs SIP URI is one issue. My guess is Tel URI is OK, and it 
>> will map into a SIP URI fine. If we believe that this concept is 
>> applicable to URIs that are not telephone numbers, then it should be a 
>> SIP URI parameter instead. Don't really care either way.
>>  
>> The other issue is "From:" header versus "P-Asserted-ID". I believe this 
>> parameter is intended to be provided by the "network" and not the UAC. 
>> So it would seem to me that it should be in P-Asserted-ID parameter 
>> header and not From header. Especially if RFC 4474 is used.
>>  
>> I think Paul Kyzivat was even proposing a P-Asserted-ID parameter. That 
>> would work too.
>>     
>
> To be clear, I don't have any particular ax to grind about this 
> proposal. I just find it technically questionable. The semantics are 
> fuzzy, and the means to convey them seems inappropriate.
>
> Ignoring the fuzziness, the semantics are such that they must be 
> asserted by some trusted party, not the UAC. And so they don't make 
> sense in most places that a TEL URI might appear. About the only place 
> they seem to make sense is a PAI. If that is the only place they make 
> sense, then adding them to that header makes more sense. Also, there is 
> no such thing as P- parameters for TEL, but this seems to be something 
> with the applicability characteristics of a P- header, which is another 
> reason to go for PAI.
>   

A long time ago in a galaxy far, far away, I proposed CPC be added to 
the Remote-Party-ID header field (remember that?) which 
P-Asserted-Identity eventually replaced.  It was added to that I-D, but 
I don't recall why this info never made it into P-A-I.

I agree that it makes better sense there than as a tel URI parameter.

Thanks,
Alan

> I can see that the information conveyed by this parameter is indeed 
> useful information to have, if one has a reason to believe it. And it 
> would be equally useful if the request originated at a SIP UAC rather 
> than in the PSTN, and also if the source had a non-numeric sip identity 
> rather than a telephone number identity. (Surely you would like to know 
> if the IM you just received was from somebody in a prison.)
>
> The only reason I can see to exclude SIP originated calls and 
> non-numeric URIs is because we don't know how to accurately determine 
> the information or how to ascertain that it it has been conveyed 
> truthfully. But that is true for telephone numbers too, as well as calls 
> gatewayed from the pstn to sip. Until we know how to do that on the open 
> internet this seems to fall in the realm of closed gardens and P- headers.
>
> 	Paul
>
>   
>>     ------------------------------------------------------------------------
>>     *From:* [e-mail] [mailto:[e-mail]]
>>     *On Behalf Of *DRAGE, Keith (Keith)
>>     *Sent:* Saturday, March 29, 2008 16:26
>>     *To:* DOLLY, MARTIN C, sbcuid; 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]/
>>
>>         ------------------------------------------------------------------------
>>     
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
>
>
>   

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP