Re: [Sipping] draft-mahy-iptel-cpc
"Ian Elz" <ian.elz@ericsson.com> Mon, 31 March 2008 13:36 UTC
Return-Path: <sipping-bounces@ietf.org>
X-Original-To: sipping-archive@optimus.ietf.org
Delivered-To: ietfarch-sipping-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB08028C266; Mon, 31 Mar 2008 06:36:43 -0700 (PDT)
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD89128C156; Mon, 31 Mar 2008 06:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.757
X-Spam-Level:
X-Spam-Status: No, score=-3.757 tagged_above=-999 required=5 tests=[AWL=2.492, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 OUznTMn8Y+6u; Mon, 31 Mar 2008 06:36:34 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 43F703A6A64; Mon, 31 Mar 2008 06:36:25 -0700 (PDT)
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 14E7020D20; Mon, 31 Mar 2008 15:32:02 +0200 (CEST)
X-AuditID: c1b4fb3c-ae09bbb00000193b-f8-47f0e7d11610
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E7A3120D1C; Mon, 31 Mar 2008 15:32:01 +0200 (CEST)
Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 15:32:01 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 31 Mar 2008 15:33:03 +0200
Message-ID: <C0E80510684FE94DBDE3A4AF6B968D2D030646AD@esealmw118.eemea.ericsson.se>
In-Reply-To: <47ED64FA.7020904@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sipping] draft-mahy-iptel-cpc
Thread-Index: AciRG9I7OPlefz0BRk+WhbSL6gYwqQCF0GZQ
From: Ian Elz <ian.elz@ericsson.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
X-OriginalArrivalTime: 31 Mar 2008 13:32:01.0580 (UTC) FILETIME=[99F75EC0:01C89333]
X-Brightmail-Tracker: AAAAAA==
Cc: iptel@ietf.org, "DOLLY, MARTIN C, sbcuid" <mdolly@att.com>, sipping@ietf.org
Subject: Re: [Sipping] draft-mahy-iptel-cpc
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org
Paul, You are now stretching the requirements for CPC/OLI beyond what is now supported in ISUP. In current ISUP it would be possible to have as you correctly describe a police cell phone but only a single value is included. If you wish to allow multiple values then we raise an interworking problem of which value is used when interworking with ISUP. We may need to define one value as primary and others as secondary to allow correct interworking. Ian Elz System Manager DUCI LDC UK (Lucid Duck) Office: + 44 24 764 35256 gsm: +44 7801723668 ian.elz@ericsson.com -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 28 March 2008 21:37 To: DOLLY, MARTIN C, sbcuid Cc: iptel@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-iptel-cpc 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-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 _______________________________________________ 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 _______________________________________________ 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
- Re: [Sipping] draft-mahy-iptel-cpc Sumit Garg
- Re: [Sipping] draft-mahy-iptel-cpc Ian Elz
- Re: [Sipping] draft-mahy-iptel-cpc Ian Elz
- Re: [Sipping] [Iptel] draft-mahy-iptel-cpc Sumit Garg
- Re: [Sipping] draft-mahy-iptel-cpc Sumit Garg
- Re: [Sipping] draft-mahy-iptel-cpc DOLLY, MARTIN C, sbcuid
- Re: [Sipping] draft-mahy-iptel-cpc Jesske, R
- Re: [Sipping] [Iptel] draft-mahy-iptel-cpc DOLLY, MARTIN C, sbcuid
- Re: [Sipping] draft-mahy-iptel-cpc DOLLY, MARTIN C, sbcuid
- Re: [Sipping] draft-mahy-iptel-cpc Ian Elz
- Re: [Sipping] draft-mahy-iptel-cpc Sumit Garg
- Re: [Sipping] draft-mahy-iptel-cpc DOLLY, MARTIN C, sbcuid
- Re: [Sipping] draft-mahy-iptel-cpc Paul Kyzivat
- Re: [Sipping] draft-mahy-iptel-cpc DRAGE, Keith (Keith)
- Re: [Sipping] draft-mahy-iptel-cpc DOLLY, MARTIN C, ATTLABS
- Re: [Sipping] draft-mahy-iptel-cpc Sumit Garg
- Re: [Sipping] draft-mahy-iptel-cpc Ted Hardie
- Re: [Sipping] draft-mahy-iptel-cpc Paul Kyzivat
- Re: [Sipping] draft-mahy-iptel-cpc Ian Elz
- Re: [Sipping] draft-mahy-iptel-cpc DOLLY, MARTIN C, ATTLABS
- Re: [Sipping] draft-mahy-iptel-cpc Ian Elz
- Re: [Sipping] draft-mahy-iptel-cpc Francois Audet
- Re: [Sipping] draft-mahy-iptel-cpc Paul Kyzivat
- Re: [Sipping] draft-mahy-iptel-cpc Alan Johnston
- Re: [Sipping] draft-mahy-iptel-cpc DOLLY, MARTIN C, ATTLABS
- Re: [Sipping] draft-mahy-iptel-cpc Lee, Yiu
- Re: [Sipping] draft-mahy-iptel-cpc DOLLY, MARTIN C, ATTLABS
- Re: [Sipping] draft-mahy-iptel-cpc Lee, Yiu
- Re: [Sipping] draft-mahy-iptel-cpc DOLLY, MARTIN C, ATTLABS
- Re: [Sipping] draft-mahy-iptel-cpc Paul Kyzivat