From iptel-bounces@ietf.org Tue Apr 1 15:10:39 2008 Return-Path: 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 E9E7E3A6AB4; Tue, 1 Apr 2008 15:10:39 -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 386CA3A6B0D; Tue, 1 Apr 2008 15:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.292 X-Spam-Level: X-Spam-Status: No, score=-5.292 tagged_above=-999 required=5 tests=[AWL=1.306, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 T8QULvewozSR; Tue, 1 Apr 2008 15:10:25 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B5F7F3A6E9C; Tue, 1 Apr 2008 15:10:07 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m31MA1T23702; Tue, 1 Apr 2008 22:10:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 17:09:57 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF15DED54E@zrc2hxm0.corp.nortel.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001D9EE30@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-mahy-iptel-cpc Thread-Index: AciP4AyvKryZizHZQY6C6ocMt54MXQAIlJywAAK4S+AAMbwRkAABXNtAAAB7UjAAAviUEAAANmtwAAEbLZAAACdBYAAEWukAAAAuGPAAL1JxYACh5kEw References: <28F05913385EAC43AF019413F674A0171246ED3F@OCCLUST04EVS1.ugd.att.com><59184B4E920E854DA8ACF8E44917D49F0212F776@MAIL02.cedarpointcom.com> <28F05913385EAC43AF019413F674A0171246ED45@OCCLUST04EVS1.ugd.att.com> <5D1A7985295922448D5550C94DE2918001D9EE30@DEEXC1U01.de.lucent.com> From: "Francois Audet" To: "DRAGE, Keith (Keith)" , "DOLLY, MARTIN C, sbcuid" , "Sumit Garg" , , , "Paul Kyzivat" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2136293670==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============2136293670== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89445.1FB7315C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89445.1FB7315C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Keith, =20 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. =20 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. =20 I think Paul Kyzivat was even proposing a P-Asserted-ID parameter. That = would work too. ________________________________ 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 =09 =09 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. =20 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. =20 Is this so? Are there any indications which we want to be able to use = with SIP URIs as well as tel URIs. =20 regards =20 Keith =20 =20 ________________________________ 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 =09 =09 Sumit, =20 For as long as the values are clear, this approach would be = acceptable. =20 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 =09 =09 I agree with Ian, we should avoid multiple parameters.=20 The way a lot of stuff is done in tel-uri might be useful.... =20 We would only need 1 parameter: i.) user-type=3D=20 Renamed to user-type as we do not necessarily tie it = to originating side.....we might find other needs in the future. =20 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. =20 For implementations which use neither..i.e. for which context is = implicit...they would implicitly know whether it is cpc/oli. =20 -Sumit =20 =20 "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]=20 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 =20 Martin, =20 I saw you email with the list of values. =20 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. =20 An expanded combined single parameter may be suitable for all the = required values. =20 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=20 System Manager=20 DUCI LDC UK=20 (Lucid Duck)=20 Office: + 44 24 764 35256=20 gsm: +44 7801723668=20 ian.elz@ericsson.com=20 ________________________________ ------_=_NextPart_001_01C89445.1FB7315C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-mahy-iptel-cpc
Keith,
 
Tel URI vs SIP URI is one issue. My guess = is Tel URI=20 is OK, and it will map into a SIP URI fine. If we believe that = this=20 concept is applicable to URIs that are not telephone numbers, then it = should be=20 a SIP URI parameter instead. Don't really care either = way.
 
The other issue is "From:" header versus = "P-Asserted-ID". I=20 believe this parameter is intended to be provided by the "network" and = not the=20 UAC. So it would seem to me that it should be in P-Asserted-ID = parameter=20 header and not From header. Especially if RFC 4474 is = used.
 
I think Paul Kyzivat was even proposing a = P-Asserted-ID=20 parameter. That would work too.

From: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] On Behalf Of DRAGE, Keith=20 (Keith)
Sent: Saturday, March 29, 2008 16:26
To: = DOLLY,=20 MARTIN C, sbcuid; Sumit Garg; iptel@ietf.org;=20 sipping@ietf.org
Subject: Re: [Sipping]=20 draft-mahy-iptel-cpc

My understanding of the cpc work in iptel is = that is=20 currently held pending the approval of the internet draft defining the = approval regime for tel URI parameters. I believe the current status = of this=20 is to make the approval of tel URI parameters standards track = required,=20 although that could have altered - not in a position to look it up=20 currently.
 
Which brings us to the next issue in that I = understand=20 that at least some of the TISPAN people want to use this as a SIP URI=20 parameter as well as a tel URI parameter. These are two distinct sets = of=20 parameters and therefore a tel URI parameter does not automatically = become a=20 SIP URI parameter.
 
Is this so? Are there any indications which = we want to be=20 able to use with SIP URIs as well as tel URIs.
 
regards
 
Keith
 
 

From: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] On Behalf Of DOLLY, MARTIN = C,=20 sbcuid
Sent: Friday, March 28, 2008 6:15 PM
To: = Sumit=20 Garg; iptel@ietf.org; sipping@ietf.org
Subject: Re: = [Sipping]=20 draft-mahy-iptel-cpc

Sumit,
 
For as long as the values are clear, this = approach=20 would be acceptable.
 
Martin

From: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] On Behalf Of Sumit=20 Garg
Sent: Friday, March 28, 2008 2:09 PM
To:=20 iptel@ietf.org; sipping@ietf.org
Subject: Re: [Sipping]=20 draft-mahy-iptel-cpc

I=20 agree with Ian, we should avoid multiple parameters. =

The=20 way a lot of stuff is done in tel-uri might be=20 useful=85.

 

We=20 would only  need 1 parameter:  i.) =20 user-type=3D<cpc/oli-values>

        &= nbsp;      =20 Renamed to user-type as we do not necessarily tie it to = originating=20 side=85..we might find other needs in the = future.

 

For=20 the current scenario, the number itself would help the = implementation decide=20 whether it is CPC/OLI.

A=20 global number inherently has a country code which would help decide = the=20 valid values (cpc/oli)

Otherwise=20 the phone-context could be used to decide the = same.

 

For=20 implementations which use neither..i.e. for which context is = implicit=85they=20 would implicitly know whether  it is = cpc/oli.

 

-Sumit

 

 

"The reasonable = man adapts=20 himself to the world; the unreasonable one persists in trying to = adapt the=20 world to himself. Therefore all progress depends on the unreasonable = man."
-- George Bernard Shaw

From: Ian = Elz=20 [mailto:ian.elz@ericsson.com]
Sent: Friday, March 28, = 2008 12:10=20 PM
To: DOLLY, MARTIN C, sbcuid; Sumit Garg; = iptel@ietf.org;=20 sipping@ietf.org
Subject: RE: [Sipping]=20 draft-mahy-iptel-cpc

 

Martin,

 

I=20 saw you email with the list of values.

 

I=20 was not proposing to remove the values but to combine them into an = extended=20 list which encompassed both OLI and CPC. ANSI does not use CPC to = any extent=20 while ETSI/CCITT uses CPC for the same purpose as ANSI uses=20 OLI.

 

An=20 expanded combined single parameter may be suitable for all the = required=20 values.

 

If=20 you look at what is proposed by 3GPP you will see that it is = proposed to=20 reduce the different CCITT operator CPC values by using = =91language=92 in=20 Accept-Contact. There may be options to use similar techniques to = enable all=20 the OLI values to be handled correctly.

Ian=20 Elz

System=20 Manager
DUCI=20 LDC UK
(Lucid=20 Duck) =

Office:=20 + 44 24 764 35256 =
gsm:=20 +44 7801723668 =
ian.elz@ericsson.com

------_=_NextPart_001_01C89445.1FB7315C-- --===============2136293670== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel --===============2136293670==-- From iptel-bounces@ietf.org Tue Apr 1 16:15:30 2008 Return-Path: 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 0E44928C2AC; Tue, 1 Apr 2008 16:15:30 -0700 (PDT) X-Original-To: iptel@ietf.org Delivered-To: iptel@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8A8F83A6DBE; Tue, 1 Apr 2008 16:15:27 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080401231527.8A8F83A6DBE@core3.amsl.com> Date: Tue, 1 Apr 2008 16:15:27 -0700 (PDT) Cc: iptel@ietf.org Subject: [Iptel] Last Call: draft-ietf-iptel-tel-reg (The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry) to Proposed Standard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org The IESG has received a request from the IP Telephony WG (iptel) to consider the following document: - 'The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-04-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14101&rfc_flag=0 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Apr 1 16:43:42 2008 Return-Path: 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 E4A2B28C34F; Tue, 1 Apr 2008 16:43:42 -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 93C453A6E92; Tue, 1 Apr 2008 16:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.167 X-Spam-Level: X-Spam-Status: No, score=-4.167 tagged_above=-999 required=5 tests=[AWL=2.432, BAYES_00=-2.599, 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 0Ik9PUQ6MwDt; Tue, 1 Apr 2008 16:43:39 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0A86A3A6828; Tue, 1 Apr 2008 16:43:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,589,1199692800"; d="scan'208";a="10018044" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 01 Apr 2008 16:43:38 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m31Nhcmr002542; Tue, 1 Apr 2008 16:43:38 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m31Nhb5N016197; Tue, 1 Apr 2008 23:43:38 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 19:43:37 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 19:43:36 -0400 Message-ID: <47F2C8C1.9090905@cisco.com> Date: Tue, 01 Apr 2008 19:44:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francois Audet References: <28F05913385EAC43AF019413F674A0171246ED3F@OCCLUST04EVS1.ugd.att.com><59184B4E920E854DA8ACF8E44917D49F0212F776@MAIL02.cedarpointcom.com> <28F05913385EAC43AF019413F674A0171246ED45@OCCLUST04EVS1.ugd.att.com> <5D1A7985295922448D5550C94DE2918001D9EE30@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF15DED54E@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF15DED54E@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 01 Apr 2008 23:43:36.0802 (UTC) FILETIME=[346FA420:01C89452] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7132; t=1207093418; x=1207957418; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20draft-mahy-iptel-cpc |Sender:=20; bh=HzGztHGsWLMVpU41WNK2SSfBzzdTNnSpw95lJYbQXj0=; b=rdkscpl01Rx2+5sUYFSsBnwA5zzaAuU3rkdrkhhKAqU2CCKWGmZ/c43sNr nkO2S9jwAm6OZ7hCxEe6tcLarICThdjaIUI+XZ6i0+TUyWw2eItxrH+pBED8 6ShmviSWU7; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: iptel@ietf.org, "DOLLY, MARTIN C, sbcuid" , sipping@ietf.org, "DRAGE, Keith \(Keith\)" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org 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. 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=85. > = > = > = > We would only need 1 parameter: i.) user-type=3D > = > Renamed /to user-type as we do not necessarily > tie it to originating side=85..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=85they 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 =91language=92 in Accept-Contact. There may be options to u= se > 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/ > = > -----------------------------------------------------------------= ------- _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Apr 1 17:40:31 2008 Return-Path: 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, 1 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><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" To: "Alan Johnston" , "Paul Kyzivat" Cc: iptel@ietf.org, "DRAGE, Keith \(Keith\)" , Francois Audet , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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= >> >> 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 From iptel-bounces@ietf.org Tue Apr 1 17:41:08 2008 Return-Path: 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 38C333A6BE5; Tue, 1 Apr 2008 17:41:08 -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 531D13A67E1; Tue, 1 Apr 2008 17:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 ITel3X1zdslq; Tue, 1 Apr 2008 17:41:06 -0700 (PDT) Received: from pacdcimo02.cable.comcast.com (PacdcIMO02.cable.comcast.com [24.40.8.146]) by core3.amsl.com (Postfix) with ESMTP id 282553A6DF0; Tue, 1 Apr 2008 17:41:06 -0700 (PDT) Received: from ([24.40.15.118]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.18451391; Tue, 01 Apr 2008 20:40:46 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 20:40:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 20:39:37 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602043FD674@PACDCEXCMB04.cable.comcast.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-mahy-iptel-cpc Thread-Index: AciTT0huJkK+FBR7RpWeyPG2fMdD0gAhlBHQAAUtSrAAAg5WcAAZKxkA From: "Lee, Yiu" To: "Ian Elz" , "DOLLY, MARTIN C, ATTLABS" , , X-OriginalArrivalTime: 02 Apr 2008 00:40:46.0196 (UTC) FILETIME=[3083A340:01C8945A] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org After reading all the mails in the list, I think we agree: 1. OLI-CPC should be carried in one parameter. Exact syntax yet to be defined. 2. This parameter should be inserted by originating network but not the UAC (From vs. PAI). 3. This parameter is useful for both SIP-URI and TEL-URI. We haven't agreed if we allow the parameter carries multiple values (due to SIP->ISUP interop) Now my question is what is next step? -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Ian Elz Sent: Tuesday, April 01, 2008 8:21 AM To: DOLLY, MARTIN C, ATTLABS; iptel@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-iptel-cpc Martin, Sorry my choice of words. 'back to ISUP' was not meant to imply a backward direction message but where the interworking from SIP -> ISUP. ISUP -> SIP working is easy as ISUP will only contain one value but if SIP contains multiple values as Paul has suggested then we need to be able to map these to a single value in ISUP. Ian Elz System Manager DUCI LDC UK (Lucid Duck) Office: + 44 24 764 35256 gsm: +44 7801723668 ian.elz@ericsson.com -----Original Message----- From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] Sent: 01 April 2008 13:16 To: Ian Elz; iptel@ietf.org; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc Ian, CPC: Information sent in the forward direction indicating the category of the calling party and, in case of semiautomatic calls, the service language to be spoken by the incoming, delay and assistance operators. The format of the calling party's category is shown below. OLI: Information sent in the forward direction indicating toll class of service. Identification of the originating line. Martin -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Tuesday, April 01, 2008 4:58 AM To: Paul Kyzivat Cc: iptel@ietf.org; DOLLY, MARTIN C, ATTLABS; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc Paul, My comments are made based upon the content of the latest draft (06). The introduction begins: "SS7 ISUP [4] defines a Calling Party's Category (CPC) parameter that characterizes the station used to originate a call and carries other important state that can describe the originating party. When telephone numbers are contained in URIs, such as the tel URI [2], it may be desirable to communicate any CPC associated with that telephone number or, in the context of a call, the party calling from it." Based upon this the current requirement appears to be to support the ISUP CPC/OLI. If the requirement is greater than this then that is a discussion that we should have before the draft is finalized. The issue with mutual exclusivity exists in the current ISUP implementations. If that limitation is to be overcome then that requirement also needs to be discussed. If we are to move from mutual exclusivity of values then we need to ensure that interworking back to ISUP is supported. The resolution of the overlapping cases as you have indicated may have to be at the discretion of the network operator. Ian Elz _______________________________________________ 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 From iptel-bounces@ietf.org Tue Apr 1 17:53:52 2008 Return-Path: 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 62B163A6B3E; Tue, 1 Apr 2008 17:53:52 -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 95CB83A686B; Tue, 1 Apr 2008 17:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.891 X-Spam-Level: X-Spam-Status: No, score=-103.891 tagged_above=-999 required=5 tests=[AWL=2.708, 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 dmpbUI3vKogg; Tue, 1 Apr 2008 17:53:45 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id 820623A6A99; Tue, 1 Apr 2008 17:53:45 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-13.tower-203.messagelabs.com!1207097618!11826442!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 19306 invoked from network); 2 Apr 2008 00:53:38 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-13.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 2 Apr 2008 00:53:38 -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 m320rh6T017887; Tue, 1 Apr 2008 20:53:43 -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 m320reKv017877; Tue, 1 Apr 2008 20:53:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 19:53:40 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246EDB0@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602043FD674@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-mahy-iptel-cpc Thread-Index: AciTT0huJkK+FBR7RpWeyPG2fMdD0gAhlBHQAAUtSrAAAg5WcAAZKxkAAADr3EA= References: <45AEC6EF95942140888406588E1A6602043FD674@PACDCEXCMB04.cable.comcast.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Lee, Yiu" , "Ian Elz" , , , "Jean-Francois Mule" , "Daryl Malas" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org How could you come to that conclusion for a North American deployment? CPC and OLI have separate meanings. CPC: Information sent in the forward direction indicating the category of the calling party and, in case of semiautomatic calls, the service language to be spoken by the incoming, delay and assistance operators. The format of the calling party's category is shown below. OLI: Information sent in the forward direction indicating toll class of service. Identification of the originating line. Agreed, they are never seen by an end point (walled garden only), as they both will be asserted, therefore needed to be associated with the PAI. -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com] Sent: Tuesday, April 01, 2008 8:40 PM To: Ian Elz; DOLLY, MARTIN C, ATTLABS; iptel@ietf.org; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc After reading all the mails in the list, I think we agree: 1. OLI-CPC should be carried in one parameter. Exact syntax yet to be defined. 2. This parameter should be inserted by originating network but not the UAC (From vs. PAI). 3. This parameter is useful for both SIP-URI and TEL-URI. We haven't agreed if we allow the parameter carries multiple values (due to SIP->ISUP interop) Now my question is what is next step? -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Ian Elz Sent: Tuesday, April 01, 2008 8:21 AM To: DOLLY, MARTIN C, ATTLABS; iptel@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-iptel-cpc Martin, Sorry my choice of words. 'back to ISUP' was not meant to imply a backward direction message but where the interworking from SIP -> ISUP. ISUP -> SIP working is easy as ISUP will only contain one value but if SIP contains multiple values as Paul has suggested then we need to be able to map these to a single value in ISUP. Ian Elz System Manager DUCI LDC UK (Lucid Duck) Office: + 44 24 764 35256 gsm: +44 7801723668 ian.elz@ericsson.com -----Original Message----- From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] Sent: 01 April 2008 13:16 To: Ian Elz; iptel@ietf.org; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc Ian, CPC: Information sent in the forward direction indicating the category of the calling party and, in case of semiautomatic calls, the service language to be spoken by the incoming, delay and assistance operators. The format of the calling party's category is shown below. OLI: Information sent in the forward direction indicating toll class of service. Identification of the originating line. Martin -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Tuesday, April 01, 2008 4:58 AM To: Paul Kyzivat Cc: iptel@ietf.org; DOLLY, MARTIN C, ATTLABS; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc Paul, My comments are made based upon the content of the latest draft (06). The introduction begins: "SS7 ISUP [4] defines a Calling Party's Category (CPC) parameter that characterizes the station used to originate a call and carries other important state that can describe the originating party. When telephone numbers are contained in URIs, such as the tel URI [2], it may be desirable to communicate any CPC associated with that telephone number or, in the context of a call, the party calling from it." Based upon this the current requirement appears to be to support the ISUP CPC/OLI. If the requirement is greater than this then that is a discussion that we should have before the draft is finalized. The issue with mutual exclusivity exists in the current ISUP implementations. If that limitation is to be overcome then that requirement also needs to be discussed. If we are to move from mutual exclusivity of values then we need to ensure that interworking back to ISUP is supported. The resolution of the overlapping cases as you have indicated may have to be at the discretion of the network operator. Ian Elz _______________________________________________ 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 From iptel-bounces@ietf.org Tue Apr 1 18:03:22 2008 Return-Path: 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 BDE563A6E44; Tue, 1 Apr 2008 18:03:22 -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 26F833A68DE; Tue, 1 Apr 2008 18:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 xKpOp1YTV5ZW; Tue, 1 Apr 2008 18:03:14 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 50F5E3A67F8; Tue, 1 Apr 2008 18:03:08 -0700 (PDT) Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.53703193; Tue, 01 Apr 2008 21:02:52 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 21:02:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 21:01:16 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602043FD676@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <28F05913385EAC43AF019413F674A0171246EDB0@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-mahy-iptel-cpc Thread-Index: AciTT0huJkK+FBR7RpWeyPG2fMdD0gAhlBHQAAUtSrAAAg5WcAAZKxkAAADr3EAAAGL9EA== From: "Lee, Yiu" To: "DOLLY, MARTIN C, ATTLABS" , "Ian Elz" , , , "Jean-Francois Mule" , "Daryl Malas" X-OriginalArrivalTime: 02 Apr 2008 01:02:52.0948 (UTC) FILETIME=[4751ED40:01C8945D] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Hi Martin, Forgive me that I am not an expert for SS7. So, you support to separate OLI and CPC into two parameters. I have no objection for it, I just want to see how we move forward. Thanks, Yiu -----Original Message----- From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] Sent: Tuesday, April 01, 2008 8:54 PM To: Lee, Yiu; Ian Elz; iptel@ietf.org; sipping@ietf.org; Jean-Francois Mule; Daryl Malas Subject: RE: [Sipping] draft-mahy-iptel-cpc How could you come to that conclusion for a North American deployment? CPC and OLI have separate meanings. CPC: Information sent in the forward direction indicating the category of the calling party and, in case of semiautomatic calls, the service language to be spoken by the incoming, delay and assistance operators. The format of the calling party's category is shown below. OLI: Information sent in the forward direction indicating toll class of service. Identification of the originating line. Agreed, they are never seen by an end point (walled garden only), as they both will be asserted, therefore needed to be associated with the PAI. -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com] Sent: Tuesday, April 01, 2008 8:40 PM To: Ian Elz; DOLLY, MARTIN C, ATTLABS; iptel@ietf.org; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc After reading all the mails in the list, I think we agree: 1. OLI-CPC should be carried in one parameter. Exact syntax yet to be defined. 2. This parameter should be inserted by originating network but not the UAC (From vs. PAI). 3. This parameter is useful for both SIP-URI and TEL-URI. We haven't agreed if we allow the parameter carries multiple values (due to SIP->ISUP interop) Now my question is what is next step? -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Ian Elz Sent: Tuesday, April 01, 2008 8:21 AM To: DOLLY, MARTIN C, ATTLABS; iptel@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-iptel-cpc Martin, Sorry my choice of words. 'back to ISUP' was not meant to imply a backward direction message but where the interworking from SIP -> ISUP. ISUP -> SIP working is easy as ISUP will only contain one value but if SIP contains multiple values as Paul has suggested then we need to be able to map these to a single value in ISUP. Ian Elz System Manager DUCI LDC UK (Lucid Duck) Office: + 44 24 764 35256 gsm: +44 7801723668 ian.elz@ericsson.com -----Original Message----- From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] Sent: 01 April 2008 13:16 To: Ian Elz; iptel@ietf.org; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc Ian, CPC: Information sent in the forward direction indicating the category of the calling party and, in case of semiautomatic calls, the service language to be spoken by the incoming, delay and assistance operators. The format of the calling party's category is shown below. OLI: Information sent in the forward direction indicating toll class of service. Identification of the originating line. Martin -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Tuesday, April 01, 2008 4:58 AM To: Paul Kyzivat Cc: iptel@ietf.org; DOLLY, MARTIN C, ATTLABS; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc Paul, My comments are made based upon the content of the latest draft (06). The introduction begins: "SS7 ISUP [4] defines a Calling Party's Category (CPC) parameter that characterizes the station used to originate a call and carries other important state that can describe the originating party. When telephone numbers are contained in URIs, such as the tel URI [2], it may be desirable to communicate any CPC associated with that telephone number or, in the context of a call, the party calling from it." Based upon this the current requirement appears to be to support the ISUP CPC/OLI. If the requirement is greater than this then that is a discussion that we should have before the draft is finalized. The issue with mutual exclusivity exists in the current ISUP implementations. If that limitation is to be overcome then that requirement also needs to be discussed. If we are to move from mutual exclusivity of values then we need to ensure that interworking back to ISUP is supported. The resolution of the overlapping cases as you have indicated may have to be at the discretion of the network operator. Ian Elz _______________________________________________ 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 From iptel-bounces@ietf.org Tue Apr 1 18:07:58 2008 Return-Path: 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 14CEA28C101; Tue, 1 Apr 2008 18:07:58 -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 68CC33A67F8; Tue, 1 Apr 2008 18:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.918 X-Spam-Level: X-Spam-Status: No, score=-103.918 tagged_above=-999 required=5 tests=[AWL=2.681, 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 ZY7WbjttuMT1; Tue, 1 Apr 2008 18:07:55 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 495A23A6828; Tue, 1 Apr 2008 18:07:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1207098473!19041524!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 3855 invoked from network); 2 Apr 2008 01:07:54 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-8.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 2 Apr 2008 01:07:54 -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 m3217qKA022162; Tue, 1 Apr 2008 21:07:53 -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 m3217oXE022137; Tue, 1 Apr 2008 21:07:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 20:07:49 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246EDB5@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602043FD676@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-mahy-iptel-cpc Thread-Index: AciTT0huJkK+FBR7RpWeyPG2fMdD0gAhlBHQAAUtSrAAAg5WcAAZKxkAAADr3EAAAGL9EAAAULxA References: <28F05913385EAC43AF019413F674A0171246EDB0@OCCLUST04EVS1.ugd.att.com> <45AEC6EF95942140888406588E1A6602043FD676@PACDCEXCMB04.cable.comcast.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Lee, Yiu" , "Ian Elz" , , , "Jean-Francois Mule" , "Daryl Malas" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org I think 2 separate PAI parameters. -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com] Sent: Tuesday, April 01, 2008 9:01 PM To: DOLLY, MARTIN C, ATTLABS; Ian Elz; iptel@ietf.org; sipping@ietf.org; Jean-Francois Mule; Daryl Malas Subject: RE: [Sipping] draft-mahy-iptel-cpc Hi Martin, Forgive me that I am not an expert for SS7. So, you support to separate OLI and CPC into two parameters. I have no objection for it, I just want to see how we move forward. Thanks, Yiu -----Original Message----- From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] Sent: Tuesday, April 01, 2008 8:54 PM To: Lee, Yiu; Ian Elz; iptel@ietf.org; sipping@ietf.org; Jean-Francois Mule; Daryl Malas Subject: RE: [Sipping] draft-mahy-iptel-cpc How could you come to that conclusion for a North American deployment? CPC and OLI have separate meanings. CPC: Information sent in the forward direction indicating the category of the calling party and, in case of semiautomatic calls, the service language to be spoken by the incoming, delay and assistance operators. The format of the calling party's category is shown below. OLI: Information sent in the forward direction indicating toll class of service. Identification of the originating line. Agreed, they are never seen by an end point (walled garden only), as they both will be asserted, therefore needed to be associated with the PAI. -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com] Sent: Tuesday, April 01, 2008 8:40 PM To: Ian Elz; DOLLY, MARTIN C, ATTLABS; iptel@ietf.org; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc After reading all the mails in the list, I think we agree: 1. OLI-CPC should be carried in one parameter. Exact syntax yet to be defined. 2. This parameter should be inserted by originating network but not the UAC (From vs. PAI). 3. This parameter is useful for both SIP-URI and TEL-URI. We haven't agreed if we allow the parameter carries multiple values (due to SIP->ISUP interop) Now my question is what is next step? -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Ian Elz Sent: Tuesday, April 01, 2008 8:21 AM To: DOLLY, MARTIN C, ATTLABS; iptel@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-iptel-cpc Martin, Sorry my choice of words. 'back to ISUP' was not meant to imply a backward direction message but where the interworking from SIP -> ISUP. ISUP -> SIP working is easy as ISUP will only contain one value but if SIP contains multiple values as Paul has suggested then we need to be able to map these to a single value in ISUP. Ian Elz System Manager DUCI LDC UK (Lucid Duck) Office: + 44 24 764 35256 gsm: +44 7801723668 ian.elz@ericsson.com -----Original Message----- From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] Sent: 01 April 2008 13:16 To: Ian Elz; iptel@ietf.org; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc Ian, CPC: Information sent in the forward direction indicating the category of the calling party and, in case of semiautomatic calls, the service language to be spoken by the incoming, delay and assistance operators. The format of the calling party's category is shown below. OLI: Information sent in the forward direction indicating toll class of service. Identification of the originating line. Martin -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Tuesday, April 01, 2008 4:58 AM To: Paul Kyzivat Cc: iptel@ietf.org; DOLLY, MARTIN C, ATTLABS; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc Paul, My comments are made based upon the content of the latest draft (06). The introduction begins: "SS7 ISUP [4] defines a Calling Party's Category (CPC) parameter that characterizes the station used to originate a call and carries other important state that can describe the originating party. When telephone numbers are contained in URIs, such as the tel URI [2], it may be desirable to communicate any CPC associated with that telephone number or, in the context of a call, the party calling from it." Based upon this the current requirement appears to be to support the ISUP CPC/OLI. If the requirement is greater than this then that is a discussion that we should have before the draft is finalized. The issue with mutual exclusivity exists in the current ISUP implementations. If that limitation is to be overcome then that requirement also needs to be discussed. If we are to move from mutual exclusivity of values then we need to ensure that interworking back to ISUP is supported. The resolution of the overlapping cases as you have indicated may have to be at the discretion of the network operator. Ian Elz _______________________________________________ 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 From iptel-bounces@ietf.org Tue Apr 1 18:53:59 2008 Return-Path: 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 7EF8128C286; Tue, 1 Apr 2008 18:53:59 -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 9200428C1AA; Tue, 1 Apr 2008 18:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 b2dIQfYpWjwC; Tue, 1 Apr 2008 18:53:56 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 934FB28C147; Tue, 1 Apr 2008 18:53:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,590,1199660400"; d="scan'208";a="5100279" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2008 03:53:54 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m321rrTf009039; Wed, 2 Apr 2008 03:53:53 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m321rsqP007568; Wed, 2 Apr 2008 01:53:54 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 03:53:53 +0200 Received: from [10.61.64.81] ([10.61.64.81]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 03:53:52 +0200 Message-ID: <47F2E744.4050600@cisco.com> Date: Tue, 01 Apr 2008 21:54:12 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "DOLLY, MARTIN C, ATTLABS" References: <28F05913385EAC43AF019413F674A0171246EDB0@OCCLUST04EVS1.ugd.att.com> <45AEC6EF95942140888406588E1A6602043FD676@PACDCEXCMB04.cable.comcast.com> <28F05913385EAC43AF019413F674A0171246EDB5@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <28F05913385EAC43AF019413F674A0171246EDB5@OCCLUST04EVS1.ugd.att.com> X-OriginalArrivalTime: 02 Apr 2008 01:53:53.0000 (UTC) FILETIME=[6740CE80:01C89464] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6476; t=1207101234; x=1207965234; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20draft-mahy-iptel-cpc |Sender:=20; bh=NbMMGUM9L2z7zTO8GbruAyIvzGa6KPRGfRdh/FpxNCU=; b=lUCWfjGcS2phDzfDsI6+B4URhD2MPd0wemIrXWSg8E1/8laQ+Vh74CXRyy QQEwZ6ILfF07jKs78gsrewvoMQseroFi6NGayYh7iCLbK3g3bzkDdYAhhkZs mGs76PIu0l; Authentication-Results: ams-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: iptel@ietf.org, Jean-Francois Mule , Ian Elz , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org If the semantics are to be defined by SS7 then it makes sense to have the same two parameters that it has. But is that the right thing? If you dig thru the stuff in there, some of the values indeed fall into mutually exclusive sets. Others seem to be orthogonal. (E.g. police vs celular, or test vs lots of things.) Why not decompose these things into orthogonal dimensions and have a parameter for each? If not all combinations are conveyable in SS7 it won't be a problem going from SS7 to SIP, and when going the other way it can simply be a policy about which attributes trump which other attributes. Paul DOLLY, MARTIN C, ATTLABS wrote: > I think 2 separate PAI parameters. > > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com] > Sent: Tuesday, April 01, 2008 9:01 PM > To: DOLLY, MARTIN C, ATTLABS; Ian Elz; iptel@ietf.org; sipping@ietf.org; > Jean-Francois Mule; Daryl Malas > Subject: RE: [Sipping] draft-mahy-iptel-cpc > > Hi Martin, > > Forgive me that I am not an expert for SS7. So, you support to separate > OLI and CPC into two parameters. I have no objection for it, I just want > to see how we move forward. > > Thanks, > Yiu > > -----Original Message----- > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > Sent: Tuesday, April 01, 2008 8:54 PM > To: Lee, Yiu; Ian Elz; iptel@ietf.org; sipping@ietf.org; Jean-Francois > Mule; Daryl Malas > Subject: RE: [Sipping] draft-mahy-iptel-cpc > > How could you come to that conclusion for a North American deployment? > > CPC and OLI have separate meanings. > > CPC: Information sent in the forward direction indicating the category > of the calling party and, in case of semiautomatic calls, the service > language to be spoken by the incoming, delay and assistance operators. > The format of the calling party's category is shown below. > > OLI: Information sent in the forward direction indicating toll class of > service. Identification of the originating line. > > Agreed, they are never seen by an end point (walled garden only), as > they both will be asserted, therefore needed to be associated with the > PAI. > > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com] > Sent: Tuesday, April 01, 2008 8:40 PM > To: Ian Elz; DOLLY, MARTIN C, ATTLABS; iptel@ietf.org; sipping@ietf.org > Subject: RE: [Sipping] draft-mahy-iptel-cpc > > After reading all the mails in the list, I think we agree: > > 1. OLI-CPC should be carried in one parameter. Exact syntax yet to be > defined. > 2. This parameter should be inserted by originating network but not the > UAC (From vs. PAI). > 3. This parameter is useful for both SIP-URI and TEL-URI. > > We haven't agreed if we allow the parameter carries multiple values (due > to SIP->ISUP interop) > > Now my question is what is next step? > > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On > Behalf Of Ian Elz > Sent: Tuesday, April 01, 2008 8:21 AM > To: DOLLY, MARTIN C, ATTLABS; iptel@ietf.org; sipping@ietf.org > Subject: Re: [Sipping] draft-mahy-iptel-cpc > > Martin, > > Sorry my choice of words. 'back to ISUP' was not meant to imply a > backward direction message but where the interworking from SIP -> ISUP. > > ISUP -> SIP working is easy as ISUP will only contain one value but if > SIP contains multiple values as Paul has suggested then we need to be > able to map these to a single value in ISUP. > > Ian Elz > > System Manager > DUCI LDC UK > (Lucid Duck) > > Office: + 44 24 764 35256 > gsm: +44 7801723668 > ian.elz@ericsson.com > > > -----Original Message----- > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > Sent: 01 April 2008 13:16 > To: Ian Elz; iptel@ietf.org; sipping@ietf.org > Subject: RE: [Sipping] draft-mahy-iptel-cpc > > Ian, > > CPC: Information sent in the forward direction indicating the category > of the calling party and, in case of semiautomatic calls, the service > language to be spoken by the incoming, delay and assistance operators. > The format of the calling party's category is shown below. > > OLI: Information sent in the forward direction indicating toll class of > service. Identification of the originating line. > > Martin > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Tuesday, April 01, 2008 4:58 AM > To: Paul Kyzivat > Cc: iptel@ietf.org; DOLLY, MARTIN C, ATTLABS; sipping@ietf.org > Subject: RE: [Sipping] draft-mahy-iptel-cpc > > Paul, > > My comments are made based upon the content of the latest draft (06). > > The introduction begins: > > "SS7 ISUP [4] defines a Calling Party's Category (CPC) parameter that > characterizes the station used to originate a call and carries other > important state that can describe the originating party. When > telephone numbers are contained in URIs, such as the tel URI [2], it > may be desirable to communicate any CPC associated with that > telephone number or, in the context of a call, the party calling from > it." > > Based upon this the current requirement appears to be to support the > ISUP CPC/OLI. > > If the requirement is greater than this then that is a discussion that > we should have before the draft is finalized. > > The issue with mutual exclusivity exists in the current ISUP > implementations. If that limitation is to be overcome then that > requirement also needs to be discussed. If we are to move from mutual > exclusivity of values then we need to ensure that interworking back to > ISUP is supported. The resolution of the overlapping cases as you have > indicated may have to be at the discretion of the network operator. > > Ian Elz > > _______________________________________________ > 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 > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From c6fdf0a6@konferenz.com Fri Apr 11 02:53:49 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5595628C28E; Fri, 11 Apr 2008 02:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -62.626 X-Spam-Level: X-Spam-Status: No, score=-62.626 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_DOLLAR_BONUS=10.357, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 XP2wv5Jw07W1; Fri, 11 Apr 2008 02:53:43 -0700 (PDT) Received: from 84.123.86.95.dyn.user.ono.com (84.123.86.95.dyn.user.ono.com [84.123.86.95]) by core3.amsl.com (Postfix) with SMTP id 7205828C2B1; Fri, 11 Apr 2008 02:53:35 -0700 (PDT) X-Originating-IP: 220.186.51.168 by smtp.84.123.86.95; Fri, 11 Apr 2008 05:54:03 -0500 Message-ID: From: "Jay Patel" Reply-To: "Jay Patel" To: ipr-wg-bounces@ietf.org Subject: Come and get your MASSIVE $2400 BONUS NOW! Date: Fri, 11 Apr 2008 05:54:03 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit It's your lucky day...... and it's your turn to win HUGE............ Enjoy our MASSIVE $2400 bonus......... Join tens of thousands of LUCKY winners today........ We promise: Fair Gaming, Amazingly fast payouts.... and the best in live customer support... Enter here http://muhofuby24203.blogspot.com/ to download the world's leading online casino NOW... From c_kido@pearl-kg.co.jp Fri Apr 11 15:32:25 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09973A6863; Fri, 11 Apr 2008 15:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -87.302 X-Spam-Level: X-Spam-Status: No, score=-87.302 tagged_above=-999 required=5 tests=[BANG_GUAR=0.939, BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, 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 sRVbYg3tlELm; Fri, 11 Apr 2008 15:32:25 -0700 (PDT) Received: from client-201.240.161.96.speedy.net.pe (unknown [201.240.161.96]) by core3.amsl.com (Postfix) with SMTP id BFE003A683D; Fri, 11 Apr 2008 15:32:13 -0700 (PDT) X-Originating-IP: 152.107.174.62 by smtp.201.240.161.96; Fri, 11 Apr 2008 18:32:41 -0500 Message-ID: From: "Arturo Cox" Reply-To: "Arturo Cox" To: ipr-wg-bounces@ietf.org Subject: Play at the world's leading online casino..... Date: Fri, 11 Apr 2008 18:32:41 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Amazing $2400 bonuses..... Amazing Customer Support...... Amazing games..... Play at the world's most prestigious online casino..... Come and get your MASSIVE $2400 BONUS NOW! Fair Gaming, Fast Payouts unrivalled customer support: GUARANTEED!!! Join the superstars and some of the world’s BIGGEST winners........ ENTER HERE http://fiwapywi71020.blogspot.com/ TO DOWNLOAD NOW! From c5.65ec8dcc@metroform.com Sat Apr 12 02:48:48 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 266A228C19B; Sat, 12 Apr 2008 02:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -82.003 X-Spam-Level: X-Spam-Status: No, score=-82.003 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_VIRTUACOMBR=1.193, 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 z3a9ATy9v-69; Sat, 12 Apr 2008 02:48:47 -0700 (PDT) Received: from bd079458.virtua.com.br (unknown [189.7.148.88]) by core3.amsl.com (Postfix) with SMTP id 8B6EF3A6D8C; Sat, 12 Apr 2008 02:48:37 -0700 (PDT) X-Originating-IP: 42.98.25.142 by smtp.189.7.148.88; Sat, 12 Apr 2008 05:49:05 -0500 Message-ID: From: "Kory Vela" Reply-To: "Kory Vela" To: ipr-wg-bounces@ietf.org Subject: The safest and most secure Online casino in the world....... Date: Sat, 12 Apr 2008 05:49:05 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Play at the world's leading online casino..... Play NOW and get a HUGE $2400 Match Bonus!!!!!!!!!!!!!!! The safest and most secure Online casino in the world....... Play our COLLOSAL progressive slots... our amazing "Shopping Spree" Jackpot is now a MASSIVE $857,798.00..... It must payout soon!!!!!!!!!!! ........ GOOD LUCK!!!! Enter here http://nolocogu44830.blogspot.com to download the world's leading online casino NOW... From Marinos-gbonjour@FCM.FCL.FUJITSU.COM Sat Apr 12 22:53:11 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 943873A6784 for ; Sat, 12 Apr 2008 22:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.777 X-Spam-Level: X-Spam-Status: No, score=-26.777 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_ADLTSUB2=1.23, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, 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 qhUU8xAKJCT2 for ; Sat, 12 Apr 2008 22:53:11 -0700 (PDT) Received: from 201009002147.user.veloxzone.com.br (201009002147.user.veloxzone.com.br [201.9.2.147]) by core3.amsl.com (Postfix) with ESMTP id 2445A3A6867 for ; Sat, 12 Apr 2008 22:53:09 -0700 (PDT) User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Sun, 13 Apr 2008 02:53:41 -0300 Subject: Blow her mind away From: Marinos To: "iptel-archive@lists.ietf.org" Message-ID: <3D65AE0E.9%Marinos-gbonjour@FCM.FCL.FUJITSU.COM> Thread-Topic: Blow her mind away Thread-Index: AcidEZSiiJoiefGrR2mF9XdqqaHZVw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_9542411369_50180" --B_9542411369_50180 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Your big tool will give them the best pleasure ever http://www.polaetna.com/ --B_9542411369_50180 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Blow her mind away Your big tool will give = them the best pleasure ever http://www.polaetna.com/
 --B_9542411369_50180-- From primmis_@gmx.com Sun Apr 13 19:34:32 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D32928C14F for ; Sun, 13 Apr 2008 19:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.998 X-Spam-Level: **** X-Spam-Status: No, score=4.998 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_60=1, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, SUBJ_ALL_CAPS=2.077, UPPERCASE_50_75=0.001] 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 vOyReM3C4Tr9 for ; Sun, 13 Apr 2008 19:34:31 -0700 (PDT) Received: from avas-mr18.fibertel.com.ar (avas-mr18.fibertel.com.ar [24.232.0.121]) by core3.amsl.com (Postfix) with ESMTP id A2D4B3A6AF5 for ; Sun, 13 Apr 2008 19:34:30 -0700 (PDT) Received: from 217-184-19-190.fibertel.com.ar ([190.19.184.217]:63891 "EHLO desktop" smtp-auth: "zoolander@fibertel.com.ar" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr18.fibertel.com.ar with ESMTPA id S65204AbYDNCeh; Sun, 13 Apr 2008 23:34:37 -0300 Organization: PRIMMIS Reply-To: primmis@gmx.com Message-ID: <2aed868e9998ecf3535b001b0017491f@gmx.com> From: "PRIMMIS" To: "primmis" Subject: EQUIPA TU CASA EN 36 CUOTAS FIJAS EN PESOS! Date: Sun, 13 Apr 2008 23:25:43 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=SPLITOR00A_001_49743875D" X-Fib-Al-Info: Al X-Fib-Al-MRId: 3912e2a2acc99758e9bdc85b3403cbfb X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: primmis_@gmx.com This is a multi-part message in MIME format. ------=SPLITOR00A_001_49743875D Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable EQUIPA TU CASA EN 36 CUOTAS FIJA EQUIPA TU CASA EN 36 CUOTAS FIJAS EN PESOS! TODO CON CREDITO PERSONAL! MINIMOS REQUISITOS, con RECIBO DE SUELDO o MONOTRIBUTO! PRECIOS FINALES IVA INCLUIDO FACTURA A o B PROMOCION APERTURA CON TARJETAS VISA, MASTERCARD, AMERICAN EXPRESS, CABAL = O=20 TARJETA SHOPPING 6 cuotas SIN INTERES! PRIMMIS Email: primmis@gmx.com MSN: primmis@gmx.comSANYOLCD32XH4 Televisor de LCD de 32" High Definition = $4199=20 o 36 cuotas de $226SANYO LCD37XH4 Televisor de LCD de 37" High Definition = $5999=20 o 36 cuotas de $323 LG PLASMA TV con Disco Rigido 42PB2RR Plasma 42" con Disco Rigido de 80GB = Incorporado=20 $7799 o 36 cuotas de $419SANYOEX-2170 Increible Sistema 2.1 de Audio y = Video=20 de Alta Definici=F3n con reproducci=F3n DVD$1899 o 36 cuotas de $106=A0 NOBLEX TV 29" 29TC675=A0 NOBLEX $1199 o 36 cuotas de $65 PHILCO TV 21" PF21127 FTLA $860 o 36 cuotas de $47 CONSULTE EL PLAN DE CUOTAS QUE MAS LE CONVENGA PRIMMIS Email: primmis@gmx.com MSN: primmis@gmx.com=A0 ------=SPLITOR00A_001_49743875D Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable EQUIPA TU CASA EN 36 CUOTAS FIJA

EQUIPA TU CASA EN = 36=20 CUOTAS FIJAS EN PESOS!

TODO CON CREDITO=20 PERSONAL!
MINIMOS REQUISITOS, con RECIBO DE SUELDO o MONOTRIBUTO!

PRECIOS FINALES = IVA=20 INCLUIDO

FACTURA A o = B

PROMOCION APERTURA=20 CON TARJETAS VISA, MASTERCARD, AMERICAN EXPRESS, CABAL O TARJETA=20 SHOPPING 6 cuotas SIN INTERES!

PRIMMIS
Email: primmis@gmx.com
MSN: primmis@gmx.com

SANYO=20 LCD32XH4 Televisor de LCD de 32" High Definition $4199 o 36 cuotas de=20 $226

3D"LCD32XH4

SANYO LCD37XH4 Televisor de=20 LCD de 37" High Definition $5999 o 36 cuotas de $323

LG PLASMA TV con Disco=20 Rigido 42PB2RR Plasma 42" con Disco Rigido de 80GB=20 Incorporado $7799 o 36=20 cuotas de $419

SANYO=20 EX-2170 Increible Sistema 2.1 de Audio y Video de=20 Alta Definici=F3n con reproducci=F3n DVD=20 $1899 o 36 cuotas de $106

 
3D"EX-2170=20

NOBLEX TV 29" 29TC675 =20 NOBLEX $1199 o 36 cuotas de=20 $65

PHILCO TV 21" PF21127=20 FTLA $860 o 36 cuotas de=20 $47

CONSULTE EL PLAN DE CUOTAS QUE=20 MAS LE CONVENGA

PRIMMIS
Email: primmis@gmx.com
MSN: primmis@gmx.com

 
------=SPLITOR00A_001_49743875D-- From iptel-bounces@ietf.org Tue Apr 22 10:42:19 2008 Return-Path: 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 33B703A68BE; Tue, 22 Apr 2008 10:42:19 -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 81B1F3A68BE for ; Tue, 22 Apr 2008 10:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 1I1USev6eWLq for ; Tue, 22 Apr 2008 10:42:14 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8A2A03A67FB for ; Tue, 22 Apr 2008 10:42:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,695,1199682000"; d="scan'208";a="6008301" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Apr 2008 13:42:20 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3MHgK5V029907 for ; Tue, 22 Apr 2008 13:42:20 -0400 Received: from [192.168.1.73] (rtp-vpn2-433.cisco.com [10.82.241.177]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3MHgJXn025334 for ; Tue, 22 Apr 2008 17:42:20 GMT Message-Id: From: Cullen Jennings To: iptel@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 22 Apr 2008 13:46:15 -0400 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=32; t=1208886140; x=1209750140; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20test=20to=20iptel |Sender:=20 |To:=20iptel@ietf.org; bh=AJtjymkFblDFzLvlbNJCJOMgKNH9Gm+d8d3crueHY8I=; b=AC30Dyr5sbZzYWaUTIZUIdi4cm2KRpgwNj1sk/P00X2DeAjWB6iyA3tC+5 9pT7/pOPezDzbOs2vDOD8Rq1IePXqog8c7YlylojAC3wupCdbC2/h+V7rnBU qVLAYk2GLV; Authentication-Results: rtp-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Iptel] test to iptel X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Just a test - please ignore. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel