Re: [Iptel] [Sipping] draft-mahy-iptel-cpc
"DOLLY, MARTIN C, ATTLABS" <mdolly@att.com> Wed, 02 April 2008 00:40 UTC
Return-Path: <iptel-bounces@ietf.org>
X-Original-To: iptel-archive@megatron.ietf.org
Delivered-To: ietfarch-iptel-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8453A6882; Tue, 1 Apr 2008 17:40:31 -0700 (PDT)
X-Original-To: iptel@core3.amsl.com
Delivered-To: iptel@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0AF33A6C34; Tue, 1 Apr 2008 17:40:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.863
X-Spam-Level:
X-Spam-Status: No, score=-103.863 tagged_above=-999 required=5 tests=[AWL=2.736, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF0mbNk5c-Xa; Tue, 1 Apr 2008 17:40:29 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id A2D653A6E59; Tue, 1 Apr 2008 17:40:21 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: mdolly@att.com
X-Msg-Ref: server-9.tower-120.messagelabs.com!1207096818!27621381!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 15246 invoked from network); 2 Apr 2008 00:40:20 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-9.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 2 Apr 2008 00:40:20 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m320eIiF014888; Tue, 1 Apr 2008 20:40:18 -0400
Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m320eAQH014861; Tue, 1 Apr 2008 20:40:11 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 01 Apr 2008 19:40:09 -0500
Message-ID: <28F05913385EAC43AF019413F674A0171246EDAE@OCCLUST04EVS1.ugd.att.com>
In-Reply-To: <47F2D186.9060405@sipstation.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sipping] draft-mahy-iptel-cpc
Thread-Index: AciUV4blEJzHUkhCSKS6zRckz96eWgAAmYAg
References: <28F05913385EAC43AF019413F674A0171246ED3F@OCCLUST04EVS1.ugd.att.com><C0E80510684FE94DBDE3A4AF6B968D2D03063D37@esealmw118.eemea.ericsson.se><59184B4E920E854DA8ACF8E44917D49F0212F776@MAIL02.cedarpointcom.com> <28F05913385EAC43AF019413F674A0171246ED45@OCCLUST04EVS1.ugd.att.com> <5D1A7985295922448D5550C94DE2918001D9EE30@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF15DED54E@zrc2hxm0.corp.nortel.com> <47F2C8C1.9090905@cisco.com> <47F2D186.9060405@sipstation.com>
From: "DOLLY, MARTIN C, ATTLABS" <mdolly@att.com>
To: Alan Johnston <alan@sipstation.com>, Paul Kyzivat <pkyzivat@cisco.com>
Cc: iptel@ietf.org, "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, Francois Audet <audet@nortel.com>, sipping@ietf.org
Subject: Re: [Iptel] [Sipping] draft-mahy-iptel-cpc
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IP Telephony <iptel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>, <mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/iptel>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>, <mailto:iptel-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: iptel-bounces@ietf.org
Errors-To: iptel-bounces@ietf.org
I agree cpc and oli should be associated with the PAI. -----Original Message----- From: Alan Johnston [mailto:alan@sipstation.com] Sent: Tuesday, April 01, 2008 8:21 PM To: Paul Kyzivat Cc: Francois Audet; iptel@ietf.org; DOLLY, MARTIN C, ATTLABS; sipping@ietf.org; DRAGE, Keith (Keith) Subject: Re: [Sipping] draft-mahy-iptel-cpc 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:* sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] >> *On Behalf Of *DRAGE, Keith (Keith) >> *Sent:* Saturday, March 29, 2008 16:26 >> *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel@ietf.org; >> sipping@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@ietf.org >> [mailto:sipping-bounces@ietf.org] *On Behalf Of *DOLLY, MARTIN >> C, sbcuid >> *Sent:* Friday, March 28, 2008 6:15 PM >> *To:* Sumit Garg; iptel@ietf.org; sipping@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@ietf.org >> [mailto:sipping-bounces@ietf.org] *On Behalf Of *Sumit Garg >> *Sent:* Friday, March 28, 2008 2:09 PM >> *To:* iptel@ietf.org; sipping@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@ericsson.com] >> *Sent:* Friday, March 28, 2008 12:10 PM >> *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel@ietf.org; >> sipping@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@ericsson.com/ >> >> ------------------------------------------------------------------------ >> > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel
- [Iptel] draft-mahy-iptel-cpc Lee, Yiu
- Re: [Iptel] draft-mahy-iptel-cpc DOLLY, MARTIN C, ATTLABS
- Re: [Iptel] draft-mahy-iptel-cpc Sumit Garg
- Re: [Iptel] draft-mahy-iptel-cpc Sumit Garg
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc DOLLY, MARTIN C, sbcuid
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc Sumit Garg
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc Sumit Garg
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc DOLLY, MARTIN C, sbcuid
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc Paul Kyzivat
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc DOLLY, MARTIN C, ATTLABS
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc Sumit Garg
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc Paul Kyzivat
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc DOLLY, MARTIN C, ATTLABS
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc Francois Audet
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc Paul Kyzivat
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc DOLLY, MARTIN C, ATTLABS
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc Lee, Yiu
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc DOLLY, MARTIN C, ATTLABS
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc Lee, Yiu
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc DOLLY, MARTIN C, ATTLABS
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc Paul Kyzivat