From iptel-bounces@ietf.org Wed Dec 1 00:35:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03266 for ; Wed, 1 Dec 2004 00:35:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZNEb-0006p3-Vt for iptel-web-archive@ietf.org; Wed, 01 Dec 2004 00:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZN14-0005Ge-TY; Wed, 01 Dec 2004 00:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDfr-0001Vc-2P; Tue, 30 Nov 2004 14:28:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23257; Tue, 30 Nov 2004 14:28:29 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDl0-0004p7-G2; Tue, 30 Nov 2004 14:33:52 -0500 Received: from [10.1.11.198] (inetgate.teknekron.com [192.138.162.245] (may be forged)) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iAUJRJtw030247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Nov 2004 13:27:20 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <41ACC997.40206@nostrum.com> Date: Tue, 30 Nov 2004 13:27:19 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David R Oran Subject: Re: [Sip] RE: [Iptel] Calling Party's Category References: <49E7012A614B024B80A7D175CB9A64ECB0491A@ftrdmel1.rd.francetelecom.fr> <23EA088E-42EC-11D9-8CD3-000A95C73842@cisco.com> In-Reply-To: <23EA088E-42EC-11D9-8CD3-000A95C73842@cisco.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 01 Dec 2004 00:27:00 -0500 Cc: "Jesske, R" , iptel@ietf.org, Tom Taylor , sip@ietf.org, GARCIN Sebastien RD-CORE-ISS X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit David R Oran wrote: > > On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: > >> As an fixed line operator we also are interested in this feature and >> would be happy that the IETF finally moves forward with this draft. >> This type of parameter is widely signalled in ISDN/PSTN networks. In >> SIP (for example) it is required in context of both: >> >> - pure SIP networks (e.g. in case of a SIP payphone), and >> - interworking with legacy networks >> >> I think the uses case for this parameter will depend on the operator >> service portfolio. For example, in France, the calling party's >> category parameter is used for the Call Return service. >> > Could you explain a bit about how this is used? I, for one would find > it helpful and possibly a motivating use case. I'm equally confused. I'm familiar with the calling party category in ISUP, which works only because of the walled-garden nature of the SS7 network. Without that, there are really two major factors around this which need to be characterized: 1. Who is authorized to assert a particular calling party category? This is much trickier than the identity problem; with identity, we can trust that a domain is the authority for the use of user names in that domain. For calling party category, there is no such relationship. For example, it would probably not be valid for a domain of "adamroach.com" to assert a calling party category of "priority," "operator," or "police." 2. Under which circumstances is the calling party category required to be present? Is there some architectural mechanism that can be used to enforce this? (We don't need to define it, but there should at least be some idea about whether it's possible). If not, then there is no purpose in coming up with a protocol mechanism for conveying such information. /a _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Dec 1 00:36:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03376 for ; Wed, 1 Dec 2004 00:36:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZNFG-0006qC-5X for iptel-web-archive@ietf.org; Wed, 01 Dec 2004 00:41:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZN3b-0005mc-VS; Wed, 01 Dec 2004 00:29:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBGW-0002tC-Kq; Tue, 30 Nov 2004 11:54:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06403; Tue, 30 Nov 2004 11:54:09 -0500 (EST) Received: from sand2.gxn.net ([195.147.249.208]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZBLc-0000Az-FY; Tue, 30 Nov 2004 11:59:31 -0500 Received: from ip02.corenetltd.adsl.gxn.net ([195.147.83.74] helo=gblons002.Streamdoor.local) by sand2.gxn.net with esmtp (Exim 4.33) id 1CZBH2-0007Q5-3A; Tue, 30 Nov 2004 16:54:45 +0000 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RE: [Iptel] Calling Party's Category Date: Tue, 30 Nov 2004 16:47:00 -0000 Message-ID: Thread-Topic: [Sip] RE: [Iptel] Calling Party's Category Thread-Index: AcTW+ukGCjEsBDmhRFaneh+gjU+kpgAAFGsj From: "Ben Gatewood" To: "David R Oran" , "GARCIN Sebastien RD-CORE-ISS" X-Spam-Score: 0.2 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f X-Mailman-Approved-At: Wed, 01 Dec 2004 00:29:34 -0500 Cc: "Jesske, R" , iptel@ietf.org, Tom Taylor , sip@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1195672707==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 This is a multi-part message in MIME format. --===============1195672707== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D6FC.361BFF68" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D6FC.361BFF68 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable His name is Kevin. Other than that I agree with you. I'm interested in this area as well as I might be able to make use of thi= s type of functionality in a hospitality industry scenario.=20 Regards, B http://www.freekevin.com/ Ben Gatewood Streamdoor Ltd 114b Power Rd London W4 5PY +44 20 7422 0439 +44 7835 136 187 bgatewood@streamdoor.net -----Original Message----- From: sip-bounces@ietf.org on behalf of David R Oran Sent: Tue 11/30/2004 4:23 PM To: GARCIN Sebastien RD-CORE-ISS Cc: Jesske, R; iptel@ietf.org; Tom Taylor; sip@ietf.org Subject: Re: [Sip] RE: [Iptel] Calling Party's Category =20 On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: > Hi, > > As an fixed line operator we also are interested in this feature and=20= > would be happy that the IETF finally moves forward with this draft.=20 > This type of parameter is widely signalled in ISDN/PSTN networks. In=20= > SIP (for example) it is required in context of both: > > - pure SIP networks (e.g. in case of a SIP payphone), and > - interworking with legacy networks > > I think the uses case for this parameter will depend on the operator=20= > service portfolio. For example, in France, the calling party's=20 > category parameter is used for the Call Return service. > Could you explain a bit about how this is used? I, for one would find=20 it helpful and possibly a motivating use case. Also note that if this information is used for any security or=20 billing-sensitive operations, we have to deal with the issue of how to=20= secure it against spoofing (SIP UAs are generally not trusted). Would=20 you believe a call made by Robert Mitnick from a prison phone would=20 actually have a prison CPC in it's SIP headers :-) ? (Mitnick is a widely known phone freak and network hacker who served a=20= number of years in US prisons). > Best regards, > sebastien > > -----Message d'origine----- > De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] De la part=20= > de Tom Taylor > Envoy=E9 : mardi 30 novembre 2004 16:07 > =C0 : Jesske, R > Cc : iptel@ietf.org; sip@ietf.org > Objet : Re: [Iptel] Calling Party's Category > > The question was what the requirement is for this sort of indication. =20= > How is it used? > > Jesske, R wrote: >> Dear all, >> in the past there was a discussion regarding the specification of a >> Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) What=20= >> is the actual status of this activity. >> We are still interested in such kind of originating indication if the=20= >> call/communication is coming from a normal SIP user or a SIP=20 >> -Payphone or SIP-Hotelphone. >> Is there a interest from other parties in this issue? >> >> Best Regards >> >> Roland >> >> Deutsche Telekom AG >> T-Com Zentrale >> Roland Jesske, TE332-2 >> Section TE33; Signalling, Gateways and Switching Systems Am >> Kavalleriesand 3, 64295 Darmstadt, Germany >> Phone: +49 6151 83-5940 >> Fax: +49 6151 83-4577 >> email: r.jesske@t-com.net >> >> >> >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> >> > > -- > Tom Taylor > Carrier VoIP Standards Development > Nortel Networks > Phone +1 613 763 1496 (ESN 393-1496) > E-mail: taylor@nortelnetworks.com > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip *************************************************************************= ************* Disclaimer: This electronic message may contain privileged or confidential informatio= n. If you are not the intended recipient, be advised that any disclosure,= copying, distribution or use of this information is strictly prohibited.= If you are not the intended recipient, please notify the sender and dele= te this message. Views expressed in this message are those of the individ= ual sender, and are not necessarily the views of the Streamdoor Limited, = unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no= viruses are present in this email, the company cannot accept responsibil= ity for any loss or damage arising from the use of this email or attachem= ent Employees of Streamdoor Limited and its affiliates are expressly required= not to make defamatory statements and not to infringe or authorise any i= nfringements of copyrights or any other legal right by email communicatio= ns. Any such communication is contrary to company policy and outside the = scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this emai= l in error, please contact Streamdoor Group IT&C Helpdesk by email at it= &c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Dep= artment , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com *************************************************************************= ************* *************************************************************************= ************* Disclaimer: This electronic message may contain privileged or confidential informatio= n. If you are not the intended recipient, be advised that any disclosure,= copying, distribution or use of this information is strictly prohibited.= If you are not the intended recipient, please notify the sender and dele= te this message. Views expressed in this message are those of the individ= ual sender, and are not necessarily the views of the Streamdoor Limited, = unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no= viruses are present in this email, the company cannot accept responsibil= ity for any loss or damage arising from the use of this email or attachem= ent Employees of Streamdoor Limited and its affiliates are expressly required= not to make defamatory statements and not to infringe or authorise any i= nfringements of copyrights or any other legal right by email communicatio= ns. Any such communication is contrary to company policy and outside the = scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this emai= l in error, please contact Streamdoor Group IT&C Helpdesk by email at it= &c_helpdesk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Dep= artment , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com *************************************************************************= ************* ------_=_NextPart_001_01C4D6FC.361BFF68 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.freekevin.com/

Ben Gatewood
Streamdoor Ltd
114b Power Rd
London
W4 5PY
+44 20 7422 0439
+44 7835 136 187
bgatewood@streamdoor.net



-----Original Message-----
From: sip-bounces@ietf.org on behalf of David R Oran
Sent: Tue 11/30/2004 4:23 PM
To: GARCIN Sebastien RD-CORE-ISS
Cc: Jesske, R; iptel@ietf.org; Tom Taylor; sip@ietf.org
Subject: Re: [Sip] RE: [Iptel] Calling Party's Category


On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote:

> Hi,
>
> As an fixed line operator we also are interested in this feature and=
> would be happy that the IETF finally moves forward with this draft.<= BR> > This type of parameter is widely signalled in ISDN/PSTN networks. In=
> SIP (for example) it is required in context of both:
>
> - pure SIP networks (e.g. in case of a SIP payphone), and
> - interworking with legacy networks
>
> I think the uses case for this parameter will depend on the operator=
> service portfolio. For example, in France, the calling party's
> category parameter is used for the Call Return service.
>
Could you explain a bit about how this is used? I, for one would find
= it helpful and possibly a motivating use case.

Also note that if this information is used for any security or
billing-sensitive operations, we have to deal with the issue of how to secure it against spoofing (SIP UAs are generally not trusted). Would
= you believe a call made by Robert Mitnick from a prison phone would
actually have a prison CPC in it's SIP headers :-) ?

(Mitnick is a widely known phone freak and network hacker who served a number of years in US prisons).

> Best regards,
> sebastien
>
> -----Message d'origine-----
> De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] De la part
> de Tom Taylor
> Envoy=E9 : mardi 30 novembre 2004 16:07
> =C0 : Jesske, R
> Cc : iptel@ietf.org; sip@ietf.org
> Objet : Re: [Iptel] Calling Party's Category
>
> The question was what the requirement is for this sort of indication= =2E 
> How is it used?
>
> Jesske, R wrote:
>> Dear all,
>> in the past there was a discussion regarding the specification o= f a
>> Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) = What
>> is the actual status of this activity.
>> We are still interested in such kind of originating indication i= f the
>> call/communication is coming from a normal SIP user or a SIP
= >> -Payphone or SIP-Hotelphone.
>> Is there a interest from other parties in this issue?
>>
>> Best Regards
>>
>> Roland
>>
>> Deutsche Telekom AG
>> T-Com Zentrale
>> Roland Jesske, TE332-2
>> Section TE33; Signalling, Gateways and Switching Systems Am
>> Kavalleriesand 3, 64295 Darmstadt, Germany
>> Phone:  +49 6151 83-5940
>> Fax:      +49 6151 83-4577
>> email:   r.jesske@t-com.net
>>
>>
>>
>>
>> _______________________________________________
>> Iptel mailing list
>> Iptel@ietf.org
>> https:/= /www1.ietf.org/mailman/listinfo/iptel
>>
>>
>
> --
> Tom Taylor
> Carrier VoIP Standards Development
> Nortel Networks
> Phone +1 613 763 1496  (ESN 393-1496)
> E-mail: taylor@nortelnetworks.com
>
> _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www= 1.ietf.org/mailman/listinfo/iptel
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip<= BR> >
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: oran@cisco.com


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
*************************************************************************= *************
Disclaimer:

This electronic message may contain privileged or confidential informatio= n. If you are not the intended recipient, be advised that any disclosure,= copying, distribution or use of this information is strictly prohibited.= If you are not the intended recipient, please notify the sender and dele= te this message. Views expressed in this message are those of the individ= ual sender, and are not necessarily the views of the Streamdoor Limited, = unless otherwise stated.

Although Streamdoor Limited has taken reasonable precautions to ensure no= viruses are present in this email, the company cannot accept responsibil= ity for any loss or damage arising from the use of this email or attachem= ent

Employees of Streamdoor Limited and its affiliates are expressly required= not to make defamatory statements and not to infringe or authorise any i= nfringements of copyrights or any other legal right by email communicatio= ns. Any such communication is contrary to company policy and outside the = scope of the employment of the individual concerned.

For further assistance on email policy, or if you have received this emai= l in error, please contact  Streamdoor Group IT&C Helpdesk by em= ail at it&c_helpdesk@streamdoor.net or write to  Streamdoor Ltd = , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5P= Y.

www.streamdoor.com
*************************************************************************= *************

*************************************************************************= *************
Disclaimer:

This electronic message may contain p= rivileged or confidential information. If you are not the intended recipi= ent, be advised that any disclosure, copying, distribution or use of this= information is strictly prohibited. If you are not the intended recipien= t, please notify the sender and delete this message. Views expressed in t= his message are those of the individual sender, and are not necessarily t= he views of the Streamdoor Limited, unless otherwise stated.

Altho= ugh Streamdoor Limited has taken reasonable precautions to ensure no viru= ses are present in this email, the company cannot accept responsibility f= or any loss or damage arising from the use of this email or attachement
Employees of Streamdoor Limited and its affiliates are expressly re= quired not to make defamatory statements and not to infringe or authorise= any infringements of copyrights or any other legal right by email commun= ications. Any such communication is contrary to company policy and outsid= e the scope of the employment of the individual concerned.

For fur= ther assistance on email policy, or if you have received this email in er= ror, please contact Streamdoor Group IT&C Helpdesk by email at it&c_helpd= esk@streamdoor.net or write to Streamdoor Ltd , Head of IT&C Department ,= 114 Power Road , Chiswick, London , W4 5PY.

www.streamdoor.com************************************************************************= ************** = ------_=_NextPart_001_01C4D6FC.361BFF68-- --===============1195672707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============1195672707==-- From iptel-bounces@ietf.org Wed Dec 1 00:37:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03561 for ; Wed, 1 Dec 2004 00:37:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZNGD-0006sA-Pw for iptel-web-archive@ietf.org; Wed, 01 Dec 2004 00:42:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZN3c-0005ml-CE; Wed, 01 Dec 2004 00:29:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCHo-0006He-KN; Tue, 30 Nov 2004 12:59:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14401; Tue, 30 Nov 2004 12:59:33 -0500 (EST) Received: from mtassp3.ncr.disa.mil ([164.117.82.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZCMy-0002Bo-7W; Tue, 30 Nov 2004 13:04:56 -0500 Received: from mtassp3.ncr.disa.mil by mtassp3.ncr.disa.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Tue, 30 Nov 2004 12:56:44 -0500 Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2657.72) id ; Tue, 30 Nov 2004 12:57:32 -0500 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D0765166C@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'Tom Taylor'" Subject: RE: [Iptel] Calling Party's Category Date: Tue, 30 Nov 2004 12:59:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Wed, 01 Dec 2004 00:29:34 -0500 Cc: iptel@ietf.org, sip@ietf.org, "Jesske, R" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Mr. Taylor; I am just curious ... What is the status of the Internet Draft? An -----Original Message----- From: Tom Taylor [mailto:taylor@nortelnetworks.com] Sent: Tuesday, November 30, 2004 10:07 AM To: Jesske, R Cc: iptel@ietf.org; sip@ietf.org Subject: Re: [Iptel] Calling Party's Category The question was what the requirement is for this sort of indication. How is it used? Jesske, R wrote: > Dear all, > in the past there was a discussion regarding the specification of a Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) > What is the actual status of this activity. > We are still interested in such kind of originating indication if the call/communication is coming from a normal SIP user or a SIP -Payphone or SIP-Hotelphone. > Is there a interest from other parties in this issue? > > Best Regards > > Roland > > Deutsche Telekom AG > T-Com Zentrale > Roland Jesske, TE332-2 > Section TE33; Signalling, Gateways and Switching Systems > Am Kavalleriesand 3, 64295 Darmstadt, Germany > Phone: +49 6151 83-5940 > Fax: +49 6151 83-4577 > email: r.jesske@t-com.net > > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > > -- Tom Taylor Carrier VoIP Standards Development Nortel Networks Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Dec 1 01:57:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10788 for ; Wed, 1 Dec 2004 01:57:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZOVc-00008v-AZ for iptel-web-archive@ietf.org; Wed, 01 Dec 2004 02:02:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZONt-0001qt-MT; Wed, 01 Dec 2004 01:54:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZOIu-00080L-Qh; Wed, 01 Dec 2004 01:49:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10004; Wed, 1 Dec 2004 01:49:31 -0500 (EST) Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZOOB-0008NW-7y; Wed, 01 Dec 2004 01:54:59 -0500 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 1 Dec 2004 07:48:54 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Dec 2004 07:27:57 +0100 Message-Id: From: "Jesske, R" To: taylor@nortelnetworks.com Date: Wed, 1 Dec 2004 07:27:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: An.Nguyen@ncs.gov, sip@ietf.org, sebastien.garcin@francetelecom.com, iptel@ietf.org, oran@cisco.com, Mpierce1@aol.com Subject: [Iptel] AW: Calling Party's Category X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Dear Tom, all, I see there are several questions with regard to the CPC. Our approach = is to use it for billing, charge info and routing purposes. Payphone: 1. Payphone Calls are routed in an other manner than normal calls 2. Payphone Calls are billed differently compared with normal calls 3. The charge information shown to the user of the payphone is an other = than for normal once 4. Based on the CPC a blocking of numbers (e.G premium rate or special = destinations) can be performed 5. Special accounting mechanisms for free phone numbers are possible A question was how to perform security and trust. Using the CPC within = the P-Asserted-ID makes this information trusted. The UA can advice = with the P-Preferred-ID that the SIP Proxy should use the proposed URI = as P-Asserted-ID. But Proxy verifies this information. If the = Information in the Hint is not correct the dialog will be candled or = the stored ID will be provided by the network. Best Regards Roland =20 -----Urspr=FCngliche Nachricht----- Von: Tom Taylor [mailto:taylor@nortelnetworks.com] Gesendet: Dienstag, 30. November 2004 19:51 An: Nguyen, An Cc: iptel@ietf.org; sipping@ietf.org; Jesske, Roland Betreff: Re: [Iptel] Calling Party's Category Jonathan, I hope I am stating this correctly. The Chair's proposal at the meeting was that this draft be dropped, = because with=20 SIP-T defined, there is no need to define other means in SIP to carry = signalling=20 destined specifically to the PSTN. However, if use cases can be = provided which=20 demonstrate a requirement to be met in the pure SIP environment, work = can be done=20 (probably in SIPPING) to meet those requirements. Nguyen, An wrote: > Mr. Taylor; >=20 > I am just curious ... What is the status of the Internet Draft? >=20 > An >=20 >=20 [snip] --=20 Tom Taylor Carrier VoIP Standards Development Nortel Networks Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From mailman-bounces@ietf.org Wed Dec 1 07:45:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23569 for ; Wed, 1 Dec 2004 07:45:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZTwZ-0007ZA-GZ for iptel-web-archive@ietf.org; Wed, 01 Dec 2004 07:50:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZSM5-0001nj-Ni for iptel-web-archive@ietf.org; Wed, 01 Dec 2004 06:09:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: iptel-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Dec 2004 05:40:47 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for iptel-web-archive@ietf.org: List Password // URL ---- -------- iptel@ietf.org aroxgu https://www1.ietf.org/mailman/options/iptel/iptel-web-archive%40ietf.org From iptel-bounces@ietf.org Wed Dec 1 12:32:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00795 for ; Wed, 1 Dec 2004 12:32:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZYQH-0005pZ-6w for iptel-web-archive@ietf.org; Wed, 01 Dec 2004 12:37:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZXSb-0005bK-8g; Wed, 01 Dec 2004 11:36:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZVkZ-0001ew-Jy; Wed, 01 Dec 2004 09:46:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04734; Wed, 1 Dec 2004 09:46:34 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZVpt-0001WC-5d; Wed, 01 Dec 2004 09:52:06 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Dec 2004 07:53:19 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB1EjxPr019514; Wed, 1 Dec 2004 06:46:00 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iB1EjRbI009035; Wed, 1 Dec 2004 06:45:27 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: David R Oran Date: Wed, 1 Dec 2004 09:45:55 -0500 To: R Jesske X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1101912328.473237"; x:"432200"; a:"rsa-sha1"; b:"nofws:4226"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"X9YGOMPn5Yu/li9CqnRQhXpd86H2OFRRa60/YOY7mfXDR1lKvXrYKdg1lIFqi" "CifaZA/I3wT2QqJoOOrQhKrxK2rDoJdbMlimkyhV1TsXAJ7I8K+5JTgzE71pz" "W3/9Pg9FelHD//iveGUgTWYMCIJPtUJK/6BKPn3ptutE1stNc="; c:"From: David R Oran "; c:"Subject: Re: [Sip] AW: Calling Party's Category"; c:"Date: Wed, 1 Dec 2004 09:45:55 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable Cc: list iptel , "'sip@ietf.org'" Subject: [Iptel] Re: [Sip] AW: Calling Party's Category X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Just curious - what does it take to get a CPC code point allocated? If=20= the IETF is to put this into SIP somehow, this issue will undoubtedly=20 come up (as it did in spades for ENUM). So, let's assume I want to have a CPC called "Bordello", with the=20 following characteristics - Calls to normal destinations are allowed and billed to the associated=20= subscriber account - Calls to the police are blocked - Incoming calls are diverted to a sexy autoattendant. - Calls to residences of known customers (provisioned by bordello=20 owner) are anonymized, or alternatively obfuscated with a location=20 header showing the origin is elsewhere. The following questions obtain: a) who allocates the "Bordello" codepoint? b) what is the scope of the allocation? c) where are the semantics documented (e.g. RFC, part of registration,=20= etc.) d) how does it interact with other call handling related functions? this is beginning to look suspiciously like the "Namespace" discussion=20= with respect to resource-priority, isn't it? After thinking about this some more, I feel even more strongly along=20 the lines Jon Peterson suggested - don't put this into SIP; instead=20 deal with it as a role assertion through a SAML document provided as=20 part of the (enhanced) identity work when we get around to it. This comprises yet another use case for SAML (besides delegation) which=20= may argue for our being more aggressive about moving this forward right=20= on the heels of the identity work. Anyone want to tackle this with an=20 i.d.? Dave. On Dec 1, 2004, at 1:27 AM, Jesske, R wrote: > Dear Tom, all, > I see there are several questions with regard to the CPC. Our approach=20= > is to use it for billing, charge info and routing purposes. > > Payphone: > 1. Payphone Calls are routed in an other manner than normal calls > 2. Payphone Calls are billed differently compared with normal calls > 3. The charge information shown to the user of the payphone is an=20 > other than for normal once > 4. Based on the CPC a blocking of numbers (e.G premium rate or special=20= > destinations) can be performed > 5. Special accounting mechanisms for free phone numbers are possible > > A question was how to perform security and trust. Using the CPC within=20= > the P-Asserted-ID makes this information trusted. The UA can advice=20 > with the P-Preferred-ID that the SIP Proxy should use the proposed URI=20= > as P-Asserted-ID. But Proxy verifies this information. If the=20 > Information in the Hint is not correct the dialog will be candled or=20= > the stored ID will be provided by the network. > > Best Regards > > Roland > > > > > -----Urspr=FCngliche Nachricht----- > Von: Tom Taylor [mailto:taylor@nortelnetworks.com] > Gesendet: Dienstag, 30. November 2004 19:51 > An: Nguyen, An > Cc: iptel@ietf.org; sipping@ietf.org; Jesske, Roland > Betreff: Re: [Iptel] Calling Party's Category > > > Jonathan, I hope I am stating this correctly. > > The Chair's proposal at the meeting was that this draft be dropped,=20 > because with > SIP-T defined, there is no need to define other means in SIP to carry=20= > signalling > destined specifically to the PSTN. However, if use cases can be=20 > provided which > demonstrate a requirement to be met in the pure SIP environment, work=20= > can be done > (probably in SIPPING) to meet those requirements. > > Nguyen, An wrote: >> Mr. Taylor; >> >> I am just curious ... What is the status of the Internet Draft? >> >> An >> >> > [snip] > > --=20 > Tom Taylor > Carrier VoIP Standards Development > Nortel Networks > Phone +1 613 763 1496 (ESN 393-1496) > E-mail: taylor@nortelnetworks.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Dec 1 12:45:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03322 for ; Wed, 1 Dec 2004 12:45:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZYdA-0006ZR-UD for iptel-web-archive@ietf.org; Wed, 01 Dec 2004 12:51:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZXob-0007UJ-B1; Wed, 01 Dec 2004 11:58:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZWqb-0002lY-1c for iptel@megatron.ietf.org; Wed, 01 Dec 2004 10:56:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15978 for ; Wed, 1 Dec 2004 10:56:51 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZWvv-00036F-Ct for iptel@ietf.org; Wed, 01 Dec 2004 11:02:24 -0500 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iB1FuCV03998 for ; Wed, 1 Dec 2004 10:56:12 -0500 (EST) Received: from [47.130.17.25] (acart128.ca.nortel.com [47.130.17.25]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W14FSSFS; Wed, 1 Dec 2004 10:56:13 -0500 Message-ID: <41ADE99B.7000506@nortelnetworks.com> Date: Wed, 01 Dec 2004 10:56:11 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: iptel@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Iptel] Calling Party's Category X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Summarizing the discussion to date: 1. It appears that a case has been made for work in the area of transmitting characteristics of the calling party in a call, as a basis both for decisions on what services to provide and to support charging policies. 2. An architectural framework is required to address the trust issues associated with the user's potential control over signalling content. 3. Suggestions have been made about the actual mechanisms that might be applied within such a framework. This seems like a fruitful area of cooperation between the IETF and the ITU-T, with the latter defining the framework and requirements and describing the application of the mechanisms provided by the IETF. -- Tom Taylor Carrier VoIP Standards Development Nortel Networks Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Dec 1 13:25:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06221 for ; Wed, 1 Dec 2004 13:25:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZZFa-0007T9-Dp for iptel-web-archive@ietf.org; Wed, 01 Dec 2004 13:30:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZYD4-0000vb-QA; Wed, 01 Dec 2004 12:24:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZXGC-0007WH-8L; Wed, 01 Dec 2004 11:23:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20306; Wed, 1 Dec 2004 11:23:18 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZXLT-0003mT-Px; Wed, 01 Dec 2004 11:28:52 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 01 Dec 2004 11:31:12 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB1GMfgl012748; Wed, 1 Dec 2004 11:22:42 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-112.cisco.com [64.100.229.112]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BDS08047; Wed, 1 Dec 2004 08:22:40 -0800 (PST) Message-Id: <4.3.2.7.2.20041201104828.00c20590@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Dec 2004 11:22:39 -0500 To: Adam Roach , David R Oran From: Mike Hammer Subject: Re: [Sip] RE: [Iptel] Calling Party's Category In-Reply-To: <41ACC997.40206@nostrum.com> References: <23EA088E-42EC-11D9-8CD3-000A95C73842@cisco.com> <49E7012A614B024B80A7D175CB9A64ECB0491A@ftrdmel1.rd.francetelecom.fr> <23EA088E-42EC-11D9-8CD3-000A95C73842@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: "Jesske, R" , iptel@ietf.org, Tom Taylor , sip@ietf.org, GARCIN Sebastien RD-CORE-ISS X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 At 01:27 PM 11/30/2004 -0600, Adam Roach wrote: >David R Oran wrote: > >> >>On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: >> >>>As an fixed line operator we also are interested in this feature and >>>would be happy that the IETF finally moves forward with this draft. This >>>type of parameter is widely signalled in ISDN/PSTN networks. In SIP (for >>>example) it is required in context of both: >>> >>>- pure SIP networks (e.g. in case of a SIP payphone), and >>>- interworking with legacy networks >>> >>>I think the uses case for this parameter will depend on the operator >>>service portfolio. For example, in France, the calling party's category >>>parameter is used for the Call Return service. >>Could you explain a bit about how this is used? I, for one would find it >>helpful and possibly a motivating use case. > > >I'm equally confused. I'm familiar with the calling party category in >ISUP, which works only because of the walled-garden nature of the SS7 >network. Without that, there are really two major factors around this >which need to be characterized: > > 1. Who is authorized to assert a particular calling party category? > This is much trickier than the identity problem; with identity, we > can trust that a domain is the authority for the use of user names > in that domain. For calling party category, there is no such > relationship. For example, it would probably not be valid for a > domain of "adamroach.com" to assert a calling party category of > "priority," "operator," or "police." > 2. Under which circumstances is the calling party category required > to be present? Is there some architectural mechanism that can be > used to enforce this? (We don't need to define it, but there > should at least be some idea about whether it's possible). If not, > then there is no purpose in coming up with a protocol mechanism > for conveying such information. > >/a > >_______________________________________________ >Iptel mailing list >Iptel@ietf.org >https://www1.ietf.org/mailman/listinfo/iptel The underlying assumption of the base peer-peer architectural model is that the peers have a mechanism to do end-end security and can establish direct trust between the ends. But, this does not hold much water when one end is intentionally betraying trust. That begs for middleman enforcement. What happens when: the calling endpoint can not be trusted, a middle point proxy can be trusted to know the calling endpoint, the called endpoint could trust the middle device? The issue seems to be that we have an end to middle security requirements (draft-ietf-sipping-e2m-sec-reqs-04), but not a middle to end security requirements, whereby the called end does not trust the caller, but could establish trust of the middle with appropriate mechanisms. Granted this leads back to a walled garden sort of approach to things, but walls may serve a purpose. But, instead of thinking of this as an impedance to traffic, better to consider this as a truthful attribution of traffic as it is allowed to traverse domain boundaries. Trust comes from authenticity of information and in some cases middlemen are needed to enforce that. Otherwise, expect spam, spit, wormy, virus-sick networks. Mike _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Dec 1 16:52:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29867 for ; Wed, 1 Dec 2004 16:52:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZcTz-0005m2-0p for iptel-web-archive@ietf.org; Wed, 01 Dec 2004 16:57:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZbgj-0004a2-OM; Wed, 01 Dec 2004 16:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZbML-0006lO-8i; Wed, 01 Dec 2004 15:45:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22234; Wed, 1 Dec 2004 15:45:55 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZbRi-0003a7-EB; Wed, 01 Dec 2004 15:51:31 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 01 Dec 2004 12:45:05 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iB1KjIRR020606; Wed, 1 Dec 2004 12:45:19 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iB1KihPJ012348; Wed, 1 Dec 2004 12:44:45 -0800 In-Reply-To: <4.3.2.7.2.20041201141520.0309f258@localhost> References: <4.3.2.7.2.20041201141520.0309f258@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Date: Wed, 1 Dec 2004 15:45:11 -0500 To: "James M. Polk" X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1101933889.334612"; x:"432200"; a:"rsa-sha1"; b:"nofws:1477"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"VLMbMoUhLy5jmQYzzfJPKmBwXZE5MvXOuCnZPyFAOXLfpCHUmpb48oAbC9LLK" "SaWlsxMjXTlKopHOnYAy7MeHPjzHCn3xgXtPLHXczM0A+e9UQN4+tzHKNWEx4" "rDAxgERlYHFTF+aYjfOUJ1YLzWiSR4scKiO0OepZ3lnh22GuI="; c:"From: David R Oran "; c:"Subject: Re: [Sip] AW: Calling Party's Category"; c:"Date: Wed, 1 Dec 2004 15:45:11 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" , list iptel , R Jesske Subject: [Iptel] Re: [Sip] AW: Calling Party's Category X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit On Dec 1, 2004, at 3:21 PM, James M. Polk wrote: > At 09:45 AM 12/1/2004 -0500, David R Oran wrote: >> ....this is beginning to look suspiciously like the "Namespace" >> discussion with respect to resource-priority, isn't it? >> >> After thinking about this some more, I feel even more strongly along >> the lines Jon Peterson suggested - don't put this into SIP; instead >> deal with it as a role assertion through a SAML document provided as >> part of the (enhanced) identity work when we get around to it. >> >> This comprises yet another use case for SAML (besides delegation) >> which may argue for our being more aggressive about moving this >> forward right on the heels of the identity work. Anyone want to >> tackle this with an i.d.? > > How would this new ID idea be different than: > http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-01.txt ? > > The above is the answer doc to the requirements ID we authors have > been kinda dragging out feet about revving at: > http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-trait-authz > -00.txt > but we think is essentially done once revved. > I agree. > >> Dave. > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Dec 1 21:47:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26420 for ; Wed, 1 Dec 2004 21:47:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZh5z-0004cX-LU for iptel-web-archive@ietf.org; Wed, 01 Dec 2004 21:53:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZgjA-0004S4-Sd; Wed, 01 Dec 2004 21:29:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZgPs-00040u-Nt; Wed, 01 Dec 2004 21:09:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22478; Wed, 1 Dec 2004 21:09:53 -0500 (EST) Received: from [211.239.157.46] (helo=nt37.direct.co.kr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZgVI-0003jX-Hu; Wed, 01 Dec 2004 21:15:34 -0500 Received: from mail pickup service by nt37.direct.co.kr with Microsoft SMTPSVC; Thu, 2 Dec 2004 11:09:51 +0900 Received: from megatron.ietf.org [132.151.6.71] by mail4.direct.co.kr with ESMTP (SMTPD32-7.15) id AD902D000F8; Thu, 02 Dec 2004 06:54:24 +0900 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZbgl-0004az-06; Wed, 01 Dec 2004 16:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZbML-0006lO-8i; Wed, 01 Dec 2004 15:45:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22234; Wed, 1 Dec 2004 15:45:55 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZbRi-0003a7-EB; Wed, 01 Dec 2004 15:51:31 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 01 Dec 2004 12:45:05 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iB1KjIRR020606; Wed, 1 Dec 2004 12:45:19 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iB1KihPJ012348; Wed, 1 Dec 2004 12:44:45 -0800 In-Reply-To: <4.3.2.7.2.20041201141520.0309f258@localhost> References: <4.3.2.7.2.20041201141520.0309f258@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Date: Wed, 1 Dec 2004 15:45:11 -0500 To: "James M. Polk" X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1101933889.334612"; x:"432200"; a:"rsa-sha1"; b:"nofws:1477"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"VLMbMoUhLy5jmQYzzfJPKmBwXZE5MvXOuCnZPyFAOXLfpCHUmpb48oAbC9LLK" "SaWlsxMjXTlKopHOnYAy7MeHPjzHCn3xgXtPLHXczM0A+e9UQN4+tzHKNWEx4" "rDAxgERlYHFTF+aYjfOUJ1YLzWiSR4scKiO0OepZ3lnh22GuI="; c:"From: David R Oran "; c:"Subject: Re: [Sip] AW: Calling Party's Category"; c:"Date: Wed, 1 Dec 2004 15:45:11 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 02 Dec 2004 02:09:51.0885 (UTC) FILETIME=[02114BD0:01C4D814] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" , list iptel , R Jesske Subject: [Iptel] Re: [Sip] AW: Calling Party's Category X-BeenThere: iptel@ietf.org List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit On Dec 1, 2004, at 3:21 PM, James M. Polk wrote: > At 09:45 AM 12/1/2004 -0500, David R Oran wrote: >> ....this is beginning to look suspiciously like the "Namespace" >> discussion with respect to resource-priority, isn't it? >> >> After thinking about this some more, I feel even more strongly along >> the lines Jon Peterson suggested - don't put this into SIP; instead >> deal with it as a role assertion through a SAML document provided as >> part of the (enhanced) identity work when we get around to it. >> >> This comprises yet another use case for SAML (besides delegation) >> which may argue for our being more aggressive about moving this >> forward right on the heels of the identity work. Anyone want to >> tackle this with an i.d.? > > How would this new ID idea be different than: > http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-01.txt ? > > The above is the answer doc to the requirements ID we authors have > been kinda dragging out feet about revving at: > http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-trait-authz > -00.txt > but we think is essentially done once revved. > I agree. > >> Dave. > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Dec 2 02:57:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17048 for ; Thu, 2 Dec 2004 02:57:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZlvH-0002v8-RQ for iptel-web-archive@ietf.org; Thu, 02 Dec 2004 03:02:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZlYJ-0008KG-UP; Thu, 02 Dec 2004 02:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZktq-0000uQ-UI; Thu, 02 Dec 2004 01:57:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27082; Thu, 2 Dec 2004 01:57:09 -0500 (EST) Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZkzK-0001ZN-5B; Thu, 02 Dec 2004 02:02:50 -0500 Received: from g8pbq.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Thu, 2 Dec 2004 07:56:19 +0100 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Dec 2004 07:56:35 +0100 Message-Id: From: "Jesske, R" To: oran@cisco.com Date: Thu, 2 Dec 2004 07:56:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org, sip@ietf.org Subject: [Iptel] AW: [Sip] AW: Calling Party's Category X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: quoted-printable The CPC in ITU-T/ETSI and the OLI in ANSI (Originating Line = Identification) are well defined code points. I think IETF is also able = to restrict definitions of code points used for routing aspects (Or Im = Wrong?) more comments in the text Roland > -----Urspr=FCngliche Nachricht----- > Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]Im Auftrag von > David R Oran > Gesendet: Mittwoch, 1. Dezember 2004 15:46 > An: Jesske, Roland > Cc: list iptel; 'sip@ietf.org' > Betreff: Re: [Sip] AW: Calling Party's Category >=20 >=20 > Just curious - what does it take to get a CPC code point=20 > allocated? If=20 > the IETF is to put this into SIP somehow, this issue will undoubtedly = > come up (as it did in spades for ENUM). >=20 > So, let's assume I want to have a CPC called "Bordello", with the=20 > following characteristics > - Calls to normal destinations are allowed and billed to the=20 > associated=20 > subscriber account > - Calls to the police are blocked > - Incoming calls are diverted to a sexy autoattendant. > - Calls to residences of known customers (provisioned by bordello=20 > owner) are anonymized, or alternatively obfuscated with a location=20 > header showing the origin is elsewhere. If I use a P-Asserted-ID (with regard to 3323+3323 a trust model is = defined) the CPC will be provided by the network and should be secure = and as I said this element is also used for routing purposes so the = definition of new code points should be restricted.=20 The concept described within draft-mahy-iptel-cpc-00 is to add the CPC = as an element within the URI. From my point of view it could be also a = normal header or P-header. We see the need of such kind of mechanism and others too. >=20 > The following questions obtain: > a) who allocates the "Bordello" codepoint? > b) what is the scope of the allocation? > c) where are the semantics documented (e.g. RFC, part of=20 > registration,=20 > etc.) > d) how does it interact with other call handling related functions? >=20 > this is beginning to look suspiciously like the "Namespace"=20 > discussion=20 > with respect to resource-priority, isn't it? No. draft-ietf-sip-resource-priority-05 is addressing priority = services. CPC is addressing other issues. >=20 > After thinking about this some more, I feel even more strongly along=20 > the lines Jon Peterson suggested - don't put this into SIP; instead=20 > deal with it as a role assertion through a SAML document provided as=20 > part of the (enhanced) identity work when we get around to it. This could be used for billing services but not for routing from my = understanding. >=20 > This comprises yet another use case for SAML (besides=20 > delegation) which=20 > may argue for our being more aggressive about moving this=20 > forward right=20 > on the heels of the identity work. Anyone want to tackle this with an = > i.d.? >=20 > Dave. >=20 > On Dec 1, 2004, at 1:27 AM, Jesske, R wrote: >=20 > > Dear Tom, all, > > I see there are several questions with regard to the CPC.=20 > Our approach=20 > > is to use it for billing, charge info and routing purposes. > > > > Payphone: > > 1. Payphone Calls are routed in an other manner than normal calls > > 2. Payphone Calls are billed differently compared with normal calls > > 3. The charge information shown to the user of the payphone is an=20 > > other than for normal once > > 4. Based on the CPC a blocking of numbers (e.G premium rate=20 > or special=20 > > destinations) can be performed > > 5. Special accounting mechanisms for free phone numbers are = possible > > > > A question was how to perform security and trust. Using the=20 > CPC within=20 > > the P-Asserted-ID makes this information trusted. The UA can advice = > > with the P-Preferred-ID that the SIP Proxy should use the=20 > proposed URI=20 > > as P-Asserted-ID. But Proxy verifies this information. If the > > Information in the Hint is not correct the dialog will be=20 > candled or=20 > > the stored ID will be provided by the network. > > > > Best Regards > > > > Roland > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > Von: Tom Taylor [mailto:taylor@nortelnetworks.com] > > Gesendet: Dienstag, 30. November 2004 19:51 > > An: Nguyen, An > > Cc: iptel@ietf.org; sipping@ietf.org; Jesske, Roland > > Betreff: Re: [Iptel] Calling Party's Category > > > > > > Jonathan, I hope I am stating this correctly. > > > > The Chair's proposal at the meeting was that this draft be dropped, = > > because with > > SIP-T defined, there is no need to define other means in=20 > SIP to carry=20 > > signalling > > destined specifically to the PSTN. However, if use cases can be=20 > > provided which > > demonstrate a requirement to be met in the pure SIP=20 > environment, work=20 > > can be done > > (probably in SIPPING) to meet those requirements. > > > > Nguyen, An wrote: > >> Mr. Taylor; > >> > >> I am just curious ... What is the status of the Internet Draft? > >> > >> An > >> > >> > > [snip] > > > > --=20 > > Tom Taylor > > Carrier VoIP Standards Development > > Nortel Networks > > Phone +1 613 763 1496 (ESN 393-1496) > > E-mail: taylor@nortelnetworks.com > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > David R. Oran > Cisco Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > Email: oran@cisco.com >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Dec 2 22:15:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03210 for ; Thu, 2 Dec 2004 22:15:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca403-0007nK-IG for iptel-web-archive@ietf.org; Thu, 02 Dec 2004 22:20:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca1dR-00051C-OT; Thu, 02 Dec 2004 19:49:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZazW-0003jW-0v; Wed, 01 Dec 2004 15:22:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20509; Wed, 1 Dec 2004 15:22:18 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZb4s-0002r0-N0; Wed, 01 Dec 2004 15:27:56 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 01 Dec 2004 12:28:11 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB1KLdAO025157; Wed, 1 Dec 2004 12:21:40 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA11511; Wed, 1 Dec 2004 12:21:45 -0800 (PST) Message-Id: <4.3.2.7.2.20041201141520.0309f258@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Dec 2004 14:21:56 -0600 To: David R Oran , R Jesske From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Thu, 02 Dec 2004 19:49:20 -0500 Cc: list iptel , "'sip@ietf.org'" Subject: [Iptel] Re: [Sip] AW: Calling Party's Category X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 At 09:45 AM 12/1/2004 -0500, David R Oran wrote: >....this is beginning to look suspiciously like the "Namespace" discussion >with respect to resource-priority, isn't it? > >After thinking about this some more, I feel even more strongly along the >lines Jon Peterson suggested - don't put this into SIP; instead deal with >it as a role assertion through a SAML document provided as part of the >(enhanced) identity work when we get around to it. > >This comprises yet another use case for SAML (besides delegation) which >may argue for our being more aggressive about moving this forward right on >the heels of the identity work. Anyone want to tackle this with an i.d.? How would this new ID idea be different than: http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-01.txt ? The above is the answer doc to the requirements ID we authors have been kinda dragging out feet about revving at: http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-trait-authz-00.txt but we think is essentially done once revved. >Dave. cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Dec 3 17:42:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14295 for ; Fri, 3 Dec 2004 17:42:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaMEV-0007Wn-1C for iptel-web-archive@ietf.org; Fri, 03 Dec 2004 17:48:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaLj3-0008CZ-Kp; Fri, 03 Dec 2004 17:16:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaL32-0003zW-UV; Fri, 03 Dec 2004 16:33:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08469; Fri, 3 Dec 2004 16:33:03 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaL8r-0005d2-7P; Fri, 03 Dec 2004 16:39:05 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iB3LVTQ12813; Fri, 3 Dec 2004 13:31:29 -0800 (PST) Message-Id: <200412032131.iB3LVTQ12813@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 03 Dec 2004 13:31:29 -0800 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: iptel@ietf.org, rfc-editor@rfc-editor.org Subject: [Iptel] RFC 3966 on The tel URI for Telephone Numbers X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3966 Title: The tel URI for Telephone Numbers Author(s): H. Schulzrinne Status: Standards Track Date: December 2004 Mailbox: hgs@cs.columbia.edu Pages: 17 Characters: 40783 Obsoletes: 2806 I-D Tag: draft-ietf-iptel-rfc2806bis-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3966.txt This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. This document is a product of the IP Telephony Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <041203133005.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3966 --OtherAccess Content-Type: Message/External-body; name="rfc3966.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <041203133005.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --NextPart-- From iptel-bounces@ietf.org Sat Dec 4 07:56:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26112 for ; Sat, 4 Dec 2004 07:56:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaZYk-0008NG-C6 for iptel-web-archive@ietf.org; Sat, 04 Dec 2004 08:02:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaZSD-0007ZD-A8; Sat, 04 Dec 2004 07:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaZO8-0006Hh-UK for iptel@megatron.ietf.org; Sat, 04 Dec 2004 07:51:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25664 for ; Sat, 4 Dec 2004 07:51:47 -0500 (EST) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaZU5-00086Q-44 for iptel@ietf.org; Sat, 04 Dec 2004 07:57:57 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Sat, 4 Dec 2004 12:52:59 -0000 Received: from [127.0.0.1] (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id YF4R04XF; Sat, 4 Dec 2004 12:53:06 -0000 From: "Conroy, Lawrence (SMTP)" To: Henning Schulzrinne , iptel@ietf.org Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <2DD9CC06-45F3-11D9-8D60-000393A70BB2@roke.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed Date: Sat, 4 Dec 2004 12:51:13 +0000 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Iptel] Re. RFC3966 X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Hi Henning, folks, Just a quick thanks to all who worked hard on this document. It's the keystone for much other work, and I speak for many in appreciating the effort that went into what appeared to be a sisyphean task. all the best, Lawrence _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Sat Dec 4 13:56:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16338 for ; Sat, 4 Dec 2004 13:56:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CafAl-0006Qd-6w for iptel-web-archive@ietf.org; Sat, 04 Dec 2004 14:02:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Caf36-0002L3-Ib; Sat, 04 Dec 2004 13:54:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Caf16-0001nr-5N for iptel@megatron.ietf.org; Sat, 04 Dec 2004 13:52:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15984 for ; Sat, 4 Dec 2004 13:52:22 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Caf76-0006JJ-27 for iptel@ietf.org; Sat, 04 Dec 2004 13:58:36 -0500 Received: from lion.cs.columbia.edu (IDENT:d3TI/IaEu6ptYRoehk9ebCNhASjaMeNj@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iB4IqLTO013237 for ; Sat, 4 Dec 2004 13:52:21 -0500 (EST) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id iB4IqKiP006459 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 4 Dec 2004 13:52:21 -0500 Message-ID: <41B20760.7060602@cs.columbia.edu> Date: Sat, 04 Dec 2004 13:52:16 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF IPTEL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2004.12.4.4 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Xiaotao Wu Subject: [Iptel] CPL-related technical reports X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Xiaotao Wu and I have written two technical reports of possible interest to those following CPL. Both can be found at http://www1.cs.columbia.edu/~library/2004.html The Simplicity and Safety of the Language for End System Services (LESS) Xiaotao Wu and Henning Schulzrinne Service Learning in Internet Telephony Xiaotao Wu and Henning Schulzrinne We would appreciate any comments you might have on these documents. Henning _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Dec 6 00:37:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14968 for ; Mon, 6 Dec 2004 00:37:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbBfh-00012H-HD for iptel-web-archive@ietf.org; Mon, 06 Dec 2004 00:44:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbBTV-0005Fy-5C; Mon, 06 Dec 2004 00:31:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbBL5-0004As-O8 for iptel@megatron.ietf.org; Mon, 06 Dec 2004 00:23:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14176 for ; Mon, 6 Dec 2004 00:23:08 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbBRN-0000lR-0O for iptel@ietf.org; Mon, 06 Dec 2004 00:29:42 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iB65MT6J016281; Sun, 5 Dec 2004 23:22:29 -0600 (CST) Received: from lucent.com (vkg.lra.lucent.com [135.255.29.154]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id iB65MR118087; Sun, 5 Dec 2004 23:22:27 -0600 (CST) Message-ID: <41B3EC92.10504@lucent.com> Date: Sun, 05 Dec 2004 23:22:26 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shan Lu Subject: Re: [Iptel] Originating trunk group without calling number(Was[Re:Comments on Trunk Group ID]) References: <015901c4d6ff$b4384e50$eb00000a@SAJAK> In-Reply-To: <015901c4d6ff$b4384e50$eb00000a@SAJAK> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: "'IETF IPTEL WG'" , "'Takuya Sawada'" , "'Henning Schulzrinne'" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Shan Lu wrote: > Fixing the BNF does not make the issue disappear. The issue is, > tel uri, as currently defined, does not allow expression of > unavailable phone digits. If such a deficiency exists in the tel URI, the trunk-group I-D is probably not the right forum to argue for putting it in. I do note that 2806bis became RFC 3966 over the weekend, so arguing for a deficiency in the tel URI may be a moot point at this time. Instead, I would like to return the focus on what we should do in the trunk-group I-D when the calling party number is not present. The previous options are still on the table; please, let's pick one. As an aside, I am curious: does the ISUP ASN represent the calling party number as an optional parameter to the IAM message? If yes, what does an intermediary switch do when it gets a call setup request and there isn't any calling party number? At the very least, it would seem prudent that whatever we do is no worse than the existing behavior in the PSTN. Thanks, - vijay > > For example, "tel:xxx;phone-context=internal" can mean something even when > "xxx" isn't there. Think of a calling number that is "internal" but has > requested privacy. > > I am not for or against any particular way to indicate empty phone number > (which may or may not lead to empty uri). But I think -A- way will be > desirable. > > Regards, > > Shan Lu > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Dec 8 18:04:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21198 for ; Wed, 8 Dec 2004 18:04:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcAxt-0004cU-OG for iptel-web-archive@ietf.org; Wed, 08 Dec 2004 18:11:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcAoo-0006YH-DK; Wed, 08 Dec 2004 18:01:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcAZf-0007wg-TF for iptel@megatron.ietf.org; Wed, 08 Dec 2004 17:46:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18471 for ; Wed, 8 Dec 2004 17:46:17 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcAgW-0003mF-Br for iptel@ietf.org; Wed, 08 Dec 2004 17:53:25 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Dec 2004 15:51:10 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iB8MjjPv022038; Wed, 8 Dec 2004 14:45:45 -0800 (PST) Received: from [10.32.131.131] ([10.32.131.131]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUP28951; Wed, 8 Dec 2004 14:45:45 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 08 Dec 2004 14:45:51 -0800 From: Cullen Jennings To: "iptel@ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Subject: [Iptel] Calling Party Category X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit I promised to start a thread on this and figure out what people want to do with it and if we understand the requirements for it then propose next steps. Fortunately, there is a thread going in the sip mailing list. I would summarize that thread as: 1) the requirements and use case are varied and not clear 2) they involved complex security and authorization issues 3) SAML looks like it might help with many of them 4) there are issues with extension and scope of future categories This makes me very uncomfortable with moving forward with this work right now as a WG item in IPTEL. What I suggest is that we shelve this work for now and let sipping figure out what the requirements are and if the solutions looks like we need to add something to the tel URL, revive the draft and figure out what to do with it. What do people think of this? Folks ok with this? I will take silence as well, just a fact of life on the iptel list :-) Cullen _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Dec 8 21:22:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09966 for ; Wed, 8 Dec 2004 21:22:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcE3e-0000fJ-Hv for iptel-web-archive@ietf.org; Wed, 08 Dec 2004 21:29:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcDlK-0002lS-2U; Wed, 08 Dec 2004 21:10:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcDZ9-0000Cs-35 for iptel@megatron.ietf.org; Wed, 08 Dec 2004 20:57:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08339 for ; Wed, 8 Dec 2004 20:57:57 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcDg1-0000Fh-9X for iptel@ietf.org; Wed, 08 Dec 2004 21:05:06 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 08 Dec 2004 19:02:51 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iB91vOOS026246; Wed, 8 Dec 2004 17:57:24 -0800 (PST) Received: from [10.32.131.131] ([10.32.131.131]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUP47033; Wed, 8 Dec 2004 17:57:23 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 08 Dec 2004 17:57:28 -0800 From: Cullen Jennings To: Manjunath S Bangalore Message-ID: In-Reply-To: <418C1107.9030802@cisco.com> Mime-version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Dhaval N Shah , "iptel@ietf.org" , Hussein F Salama , rajneesh@cisco.com Subject: [Iptel] Re: tgrep 04 comments X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0108429612==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0108429612== Content-type: multipart/alternative; boundary="B_3185373449_4979438" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3185373449_4979438 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Any ETA on a new rev of this draft? --B_3185373449_4979438 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: tgrep 04 comments
Any ETA on a new rev of this draft?
 --B_3185373449_4979438-- --===============0108429612== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0108429612==-- From iptel-bounces@ietf.org Wed Dec 8 23:29:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01217 for ; Wed, 8 Dec 2004 23:29:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcG34-0003GQ-VT for iptel-web-archive@ietf.org; Wed, 08 Dec 2004 23:37:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcFuu-0007Hz-KP; Wed, 08 Dec 2004 23:28:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcFr7-0005gn-1W; Wed, 08 Dec 2004 23:24:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00786; Wed, 8 Dec 2004 23:24:38 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcFy0-0003A4-87; Wed, 08 Dec 2004 23:31:49 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Dec 2004 20:26:53 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB94Nxm4010826; Wed, 8 Dec 2004 20:24:00 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-180.cisco.com [10.86.242.180]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AGF33153; Wed, 8 Dec 2004 20:24:02 -0800 (PST) Message-ID: <41B7D361.8010105@cisco.com> Date: Wed, 08 Dec 2004 23:24:01 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jesske, R" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: An.Nguyen@ncs.gov, iptel@ietf.org, sip@ietf.org, taylor@nortelnetworks.com, oran@cisco.com, Mpierce1@aol.com Subject: [Iptel] Re: [Sip] AW: Calling Party's Category X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Jesske, R wrote: > Dear Tom, all, > I see there are several questions with regard to the CPC. Our approach is to use it for billing, charge info and routing purposes. > > Payphone: > 1. Payphone Calls are routed in an other manner than normal calls In what way are they routed differently? > 2. Payphone Calls are billed differently compared with normal calls > 3. The charge information shown to the user of the payphone is an other than for normal once > 4. Based on the CPC a blocking of numbers (e.G premium rate or special destinations) can be performed > 5. Special accounting mechanisms for free phone numbers are possible I think its also worth pointing out that the general topic of "payphones" in sip is a complicated one, of which the cpc aspect - asserting the trait of being a payphone - is one of the easier ones. Figuring out a way to do the payments securely is a much more challenging issue. I also wanted to note that if there are requirements for endpoint assertion of characteristics and capabilities, we have a spec for that too - namely rfc3840. The usage of SAML for doing the network asserted traits also seems right to me. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Dec 9 01:45:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10516 for ; Thu, 9 Dec 2004 01:45:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcIAd-0005tb-ES for iptel-web-archive@ietf.org; Thu, 09 Dec 2004 01:52:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcI2Y-0006HT-IH; Thu, 09 Dec 2004 01:44:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcHtI-0003sN-BF for iptel@megatron.ietf.org; Thu, 09 Dec 2004 01:35:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09876 for ; Thu, 9 Dec 2004 01:35:02 -0500 (EST) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcI01-0005iT-PT for iptel@ietf.org; Thu, 09 Dec 2004 01:42:12 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I8F00MUPZJ97O@szxga03-in.huawei.com> for iptel@ietf.org; Thu, 09 Dec 2004 14:33:09 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTP id <0I8F003DLZJ904@szxga03-in.huawei.com> foriptel@ietf.org; Thu, 09 Dec 2004 14:33:09 +0800 (CST) Received: from HUAWEIGK15KAH0 ([10.18.4.210]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTPA id <0I8F00IIQZOTCS@szxml01-in.huawei.com>; Thu, 09 Dec 2004 14:36:30 +0800 (CST) Date: Thu, 09 Dec 2004 12:05:33 +0530 From: Jyoti Subject: RE: [Iptel] Re: tgrep 04 comments In-reply-to: To: "'Cullen Jennings'" , "'Manjunath S Bangalore'" Message-id: <001001c4ddb9$49aefeb0$d204120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.007 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: iptel@ietf.org, "'Dhaval N Shah'" , rajneesh@cisco.com, "'Hussein F Salama'" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jyothij@huawei.com List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2007496527==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is a multi-part message in MIME format. --===============2007496527== Content-type: multipart/alternative; boundary="Boundary_(ID_vRTHHbGo44MigimYYN77dw)" This is a multi-part message in MIME format. --Boundary_(ID_vRTHHbGo44MigimYYN77dw) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Hello All, For TGrep and TRIP - pls can you let me know if any charging data framework is available i.e if any charge related information can be updated , stored and queried. Thanks Jyoti -----Original Message----- From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Thursday, December 09, 2004 7:27 AM To: Manjunath S Bangalore Cc: Dhaval N Shah; iptel@ietf.org; Hussein F Salama; rajneesh@cisco.com Subject: [Iptel] Re: tgrep 04 comments Any ETA on a new rev of this draft? --Boundary_(ID_vRTHHbGo44MigimYYN77dw) Content-type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message
Hello All,
For TGrep and TRIP - pls can you let me know if any charging data framework is available i.e if any charge related information can be updated , stored and queried.
Thanks
Jyoti
-----Original Message-----
From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of Cullen Jennings
Sent: Thursday, December 09, 2004 7:27 AM
To: Manjunath S Bangalore
Cc: Dhaval N Shah; iptel@ietf.org; Hussein F Salama; rajneesh@cisco.com
Subject: [Iptel] Re: tgrep 04 comments


Any ETA on a new rev of this draft?
--Boundary_(ID_vRTHHbGo44MigimYYN77dw)-- --===============2007496527== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============2007496527==-- From iptel-bounces@ietf.org Thu Dec 9 07:32:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17301 for ; Thu, 9 Dec 2004 07:32:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcNZo-0003pQ-81 for iptel-web-archive@ietf.org; Thu, 09 Dec 2004 07:39:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcNQb-0003CT-4R; Thu, 09 Dec 2004 07:29:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcNJw-0002IM-0I for iptel@megatron.ietf.org; Thu, 09 Dec 2004 07:22:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16741 for ; Thu, 9 Dec 2004 07:22:55 -0500 (EST) Received: from usjk1003.kddi.com ([211.4.169.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcNQu-0003f9-45 for iptel@ietf.org; Thu, 09 Dec 2004 07:30:09 -0500 Received: from usjk1035.kddi.com ([10.96.2.25]) by usjk1003.kddi.com with ESMTP id iB9CLtV10527; Thu, 9 Dec 2004 21:21:55 +0900 (JST) Received: from usjk1038 (localhost [127.0.0.1]) by usjk1035.kddi.com with SMTP id iB9CLth29327; Thu, 9 Dec 2004 21:21:55 +0900 (JST) Received: from KDDI-0403PC0002 ([10.100.94.32]) by usjk1009.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20041209122151.QJMT24157.usjk1009.kddi.com@KDDI-0403PC0002>; Thu, 9 Dec 2004 21:21:51 +0900 To: fluffy@cisco.com, iptel@ietf.org Subject: Re: [Iptel] Calling Party Category From: Takuya Sawada References: In-Reply-To: Message-Id: <200412092121.HGE47900.B-BXEUVBT@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Thu, 9 Dec 2004 21:21:52 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-WAuditID: 0412092121510000100423 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Hi, Regarding 1), I think the requirements from those who reqire cpc parameter are simple and clear; carry the ISUP cpc information in SIP messages with tel URI. Use cases are varied as they are varied in ISUP. Regaerding 2), IMHO, cpc parameter will be used with P-Asserted-Identity header. In this scenario, trust domains model described in RFC 3324 is enough solution for security and authorization issues. Anyway we will require cpc value to be asserted by the network as it is in ISUP. I totally agree that 'because ISUP has it' is not sufficient to move it forward as an iptel WG item. During the discussion I feel it is very difficult to justify cpc work for iptel work item beyond 'because ISUP has it'. Now I propose that let's move cpc draft forward as an individual document and make it an informational RFC. It may be a good idea to add the limited scope of cpc and some use cases. If we can find more complete and general solution to cover cpc work later, we will make it a standard track RFC. I think we did that way for network asserted identity. How do people think about the above idea? Note that according RFC 3966, new tel URI RFC, an informational RFC is sufficient for optional tel URI parameters. Regards, Takuya > > I promised to start a thread on this and figure out what people want to do > with it and if we understand the requirements for it then propose next > steps. > > Fortunately, there is a thread going in the sip mailing list. I would > summarize that thread as: > > 1) the requirements and use case are varied and not clear > 2) they involved complex security and authorization issues > 3) SAML looks like it might help with many of them > 4) there are issues with extension and scope of future categories > > This makes me very uncomfortable with moving forward with this work right > now as a WG item in IPTEL. What I suggest is that we shelve this work for > now and let sipping figure out what the requirements are and if the > solutions looks like we need to add something to the tel URL, revive the > draft and figure out what to do with it. > > What do people think of this? Folks ok with this? I will take silence as > well, just a fact of life on the iptel list :-) > > Cullen > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Dec 9 07:52:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18347 for ; Thu, 9 Dec 2004 07:52:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcNtm-00048r-JC for iptel-web-archive@ietf.org; Thu, 09 Dec 2004 07:59:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcNl9-00072J-IB; Thu, 09 Dec 2004 07:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcNcY-0005et-1o for iptel@megatron.ietf.org; Thu, 09 Dec 2004 07:42:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17687 for ; Thu, 9 Dec 2004 07:42:09 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcNjW-0003yv-HX for iptel@ietf.org; Thu, 09 Dec 2004 07:49:23 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Dec 2004 13:42:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Iptel] Calling Party Category Date: Thu, 9 Dec 2004 13:41:04 +0100 Message-ID: <49E7012A614B024B80A7D175CB9A64ECD12FAC@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [Iptel] Calling Party Category thread-index: AcTd6zCbi4wqbzSHTka1OOwhPL1ubgAAK9/Q From: "GARCIN Sebastien RD-CORE-ISS" To: "Takuya Sawada" , , X-OriginalArrivalTime: 09 Dec 2004 12:42:02.0054 (UTC) FILETIME=[7B1A0660:01C4DDEC] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Hi, I would like to support Takuya' proposal. I'd also like to point out = that there are clear uses cases for the calling party's category and = operators experience those requirements every day in their networks.=20 Here is a brief summary of those that relate to the "payphone" value: Charging -------- The cpc value "payphone" is used for charging purposes Services -------- Some services (e.g. Call return, Freephone services) use the "payphone" = value. The fact that we are in a pure SIP or ISUP environment does not change = those requirements. Regards, S=E9bastien =20 -----Message d'origine----- De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] De la part = de Takuya Sawada Envoy=E9 : jeudi 9 d=E9cembre 2004 13:22 =C0 : fluffy@cisco.com; iptel@ietf.org Objet : Re: [Iptel] Calling Party Category Hi, Regarding 1), I think the requirements from those who reqire cpc = parameter are simple and clear; carry the ISUP cpc information in SIP = messages with tel URI. Use cases are varied as they are varied in ISUP. Regaerding 2), IMHO, cpc parameter will be used with P-Asserted-Identity = header. In this scenario, trust domains model described in RFC 3324 is = enough solution for security and authorization issues. Anyway we will = require cpc value to be asserted by the network as it is in ISUP. I totally agree that 'because ISUP has it' is not sufficient to move it = forward as an iptel WG item. During the discussion I feel it is very = difficult to justify cpc work for iptel work item beyond 'because ISUP = has it'. Now I propose that let's move cpc draft forward as an individual = document and make it an informational RFC. It may be a good idea to add = the limited scope of cpc and some use cases. If we can find more complete and general solution to cover cpc work = later, we will make it a standard track RFC. I think we did that way for network asserted identity. How do people think about the above idea? Note that according RFC 3966, new tel URI RFC, an informational RFC is = sufficient for optional tel URI parameters. Regards, Takuya >=20 > I promised to start a thread on this and figure out what people want=20 > to do with it and if we understand the requirements for it then=20 > propose next steps. >=20 > Fortunately, there is a thread going in the sip mailing list. I would=20 > summarize that thread as: >=20 > 1) the requirements and use case are varied and not clear > 2) they involved complex security and authorization issues > 3) SAML looks like it might help with many of them > 4) there are issues with extension and scope of future categories >=20 > This makes me very uncomfortable with moving forward with this work=20 > right now as a WG item in IPTEL. What I suggest is that we shelve this = > work for now and let sipping figure out what the requirements are and=20 > if the solutions looks like we need to add something to the tel URL,=20 > revive the draft and figure out what to do with it. >=20 > What do people think of this? Folks ok with this? I will take silence=20 > as well, just a fact of life on the iptel list :-) >=20 > Cullen >=20 >=20 >=20 > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Dec 9 08:16:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20258 for ; Thu, 9 Dec 2004 08:16:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcOHB-0004pd-9p for iptel-web-archive@ietf.org; Thu, 09 Dec 2004 08:24:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcO1k-0003vf-FE; Thu, 09 Dec 2004 08:08:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcNzz-0003KH-Sj for iptel@megatron.ietf.org; Thu, 09 Dec 2004 08:06:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19280 for ; Thu, 9 Dec 2004 08:06:22 -0500 (EST) Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcO6y-0004Wq-3f for iptel@ietf.org; Thu, 09 Dec 2004 08:13:36 -0500 Received: from g8pbq.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Thu, 9 Dec 2004 14:05:33 +0100 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Dec 2004 14:05:49 +0100 Message-Id: From: "Jesske, R" To: sebastien.garcin@francetelecom.com, tu-sawada@kddi.com, fluffy@cisco.com, iptel@ietf.org Subject: AW: [Iptel] Calling Party Category Date: Thu, 9 Dec 2004 14:05:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: quoted-printable X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable Hi, I would also like to support Takuya' and the comments from Sebatien = proposal. A in addition it could be used for routing purposes in a SIP Proxy to = choose the best MGC/MG.=20 EG in PSTN/ISDN the "data-call" can be only transferred over 64kbit/s = trunks. This can be used for a efficient coos of the correct MGC/MG = combination with the clearmode codec. Best Regards Roland=20 > -----Urspr=FCngliche Nachricht----- > Von: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org]Im Auftrag > von GARCIN Sebastien RD-CORE-ISS > Gesendet: Donnerstag, 9. Dezember 2004 13:41 > An: Takuya Sawada; fluffy@cisco.com; iptel@ietf.org > Betreff: RE: [Iptel] Calling Party Category >=20 >=20 > Hi, >=20 > I would like to support Takuya' proposal. I'd also like to=20 > point out that there are clear uses cases for the calling=20 > party's category and operators experience those requirements=20 > every day in their networks.=20 >=20 > Here is a brief summary of those that relate to the "payphone" value: >=20 > Charging > -------- > The cpc value "payphone" is used for charging purposes >=20 > Services > -------- > Some services (e.g. Call return, Freephone services) use the=20 > "payphone" value. >=20 > The fact that we are in a pure SIP or ISUP environment does=20 > not change those requirements. >=20 > Regards, > S=E9bastien > =20 >=20 > -----Message d'origine----- > De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org]=20 > De la part de Takuya Sawada > Envoy=E9 : jeudi 9 d=E9cembre 2004 13:22 > =C0 : fluffy@cisco.com; iptel@ietf.org > Objet : Re: [Iptel] Calling Party Category >=20 > Hi, >=20 > Regarding 1), I think the requirements from those who reqire=20 > cpc parameter are simple and clear; carry the ISUP cpc=20 > information in SIP messages with tel URI. > Use cases are varied as they are varied in ISUP. >=20 > Regaerding 2), IMHO, cpc parameter will be used with=20 > P-Asserted-Identity header. In this scenario, trust domains=20 > model described in RFC 3324 is enough solution for security=20 > and authorization issues. Anyway we will require cpc value to=20 > be asserted by the network as it is in ISUP. >=20 > I totally agree that 'because ISUP has it' is not sufficient=20 > to move it forward as an iptel WG item. During the discussion=20 > I feel it is very difficult to justify cpc work for iptel=20 > work item beyond 'because ISUP has it'. >=20 > Now I propose that let's move cpc draft forward as an=20 > individual document and make it an informational RFC. It may=20 > be a good idea to add the limited scope of cpc and some use cases. > If we can find more complete and general solution to cover=20 > cpc work later, we will make it a standard track RFC. > I think we did that way for network asserted identity. >=20 > How do people think about the above idea? >=20 > Note that according RFC 3966, new tel URI RFC, an=20 > informational RFC is sufficient for optional tel URI parameters. >=20 > Regards, > Takuya > >=20 > > I promised to start a thread on this and figure out what=20 > people want=20 > > to do with it and if we understand the requirements for it then=20 > > propose next steps. > >=20 > > Fortunately, there is a thread going in the sip mailing=20 > list. I would=20 > > summarize that thread as: > >=20 > > 1) the requirements and use case are varied and not clear > > 2) they involved complex security and authorization issues > > 3) SAML looks like it might help with many of them > > 4) there are issues with extension and scope of future categories > >=20 > > This makes me very uncomfortable with moving forward with this work = > > right now as a WG item in IPTEL. What I suggest is that we=20 > shelve this=20 > > work for now and let sipping figure out what the=20 > requirements are and=20 > > if the solutions looks like we need to add something to the=20 > tel URL,=20 > > revive the draft and figure out what to do with it. > >=20 > > What do people think of this? Folks ok with this? I will=20 > take silence=20 > > as well, just a fact of life on the iptel list :-) > >=20 > > Cullen > >=20 > >=20 > >=20 > > _______________________________________________ > > Iptel mailing list > > Iptel@ietf.org > > https://www1.ietf.org/mailman/listinfo/iptel >=20 >=20 > -------- > Takuya Sawada > KDDI Corporation (KDDI) > Garden Air Tower, 3-10-10, Iidabashi, > Chiyoda-ku, Tokyo 102-8460, Japan > Tel: +81-3-6678-2997 > Fax: +81-3-6678-0286 > tu-sawada@kddi.com >=20 > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel >=20 > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel >=20 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Dec 9 08:35:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21097 for ; Thu, 9 Dec 2004 08:35:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcOYn-00057X-Tj for iptel-web-archive@ietf.org; Thu, 09 Dec 2004 08:42:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcOHm-0006dN-I1; Thu, 09 Dec 2004 08:24:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcOGE-0005q6-7A; Thu, 09 Dec 2004 08:23:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20483; Thu, 9 Dec 2004 08:23:09 -0500 (EST) Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcON9-0004uk-VZ; Thu, 09 Dec 2004 08:30:23 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Thu, 9 Dec 2004 14:22:14 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Dec 2004 14:22:30 +0100 Message-Id: From: "Jesske, R" To: jdrosen@cisco.com Date: Thu, 9 Dec 2004 14:22:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: An.Nguyen@ncs.gov, iptel@ietf.org, sip@ietf.org, taylor@nortelnetworks.com, oran@cisco.com, kmainwar@cisco.com, Mpierce1@aol.com Subject: [Iptel] AW: [Sip] AW: Calling Party's Category X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 > -----Ursprungliche Nachricht----- > Von: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Gesendet: Donnerstag, 9. Dezember 2004 05:24 > An: Jesske, Roland > Cc: taylor@nortelnetworks.com; An.Nguyen@ncs.gov; sip@ietf.org; > iptel@ietf.org; oran@cisco.com; Mpierce1@aol.com > Betreff: Re: [Sip] AW: Calling Party's Category > > > > > Jesske, R wrote: > > > Dear Tom, all, > > I see there are several questions with regard to the CPC. > Our approach is to use it for billing, charge info and > routing purposes. > > > > Payphone: > > 1. Payphone Calls are routed in an other manner than normal calls > > In what way are they routed differently? One of our main issues is interoperability between PSTN/ISDN and SIP/NGN. PSTN/ISDN use this indication also for routing. In PSTN/ISDN the "data-call" can be only transferred over 64kbit/s trunks. This can be used for a efficient coos of the correct MGC/MG combination with the clearmode codec. > > > > 2. Payphone Calls are billed differently compared with normal calls > > 3. The charge information shown to the user of the payphone > is an other than for normal once > > 4. Based on the CPC a blocking of numbers (e.G premium rate > or special destinations) can be performed > > 5. Special accounting mechanisms for free phone numbers are possible > > I think its also worth pointing out that the general topic of > "payphones" in sip is a complicated one, of which the cpc aspect - > asserting the trait of being a payphone - is one of the easier ones. > Figuring out a way to do the payments securely is a much more > challenging issue. > > I also wanted to note that if there are requirements for endpoint > assertion of characteristics and capabilities, we have a spec > for that > too - namely rfc3840. The usage of SAML for doing the network > asserted > traits also seems right to me. As Takuya said: cpc parameter will be used with P-Asserted-Identity header. In this scenario, trust domains model described in RFC 3324 is enough solution for security and authorization issues. Anyway we will require cpc value to be asserted by the network as it is in ISUP. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Dec 9 12:38:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13391 for ; Thu, 9 Dec 2004 12:38:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcSMm-0002FQ-Ic for iptel-web-archive@ietf.org; Thu, 09 Dec 2004 12:46:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcS2S-0004NJ-Iw; Thu, 09 Dec 2004 12:25:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcRmV-0004za-JF for iptel@megatron.ietf.org; Thu, 09 Dec 2004 12:08:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10979 for ; Thu, 9 Dec 2004 12:08:41 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcRtV-0001Xr-KL for iptel@ietf.org; Thu, 09 Dec 2004 12:15:58 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iB9H87eJ013184 for ; Thu, 9 Dec 2004 11:08:08 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id <4M32DQ33>; Thu, 9 Dec 2004 11:08:07 -0600 Message-ID: From: "Chaidez, Fidencio (Fidencio)" To: "'iptel@ietf.org'" Subject: RE: [Iptel] Calling Party Category Date: Thu, 9 Dec 2004 11:08:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: quoted-printable X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: quoted-printable All, It is clear that a solution is needed in relation to supporting "cpc" type of information.=20 Many SIP-based service providers will likely be=20 making use of a walled-garden, trust-based, approach, for which Takuya's proposal will be sufficient to meet their requirements. Because of the non-general nature of this solution (as Takuya=20 pointed out) targetting a revived cpc draft as an=20 Informational RFC would be a good way to go. =20 Regards, Fidencio -----Urspr=FCngliche Nachricht----- Von: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org]Im Auftrag von Jesske, Roland Gesendet: Donnerstag, 9. Dezember 2004 14:06 An: sebastien.garcin@francetelecom.com; tu-sawada@kddi.com; fluffy@cisco.com; iptel@ietf.org Betreff: AW: [Iptel] Calling Party Category Hi, I would also like to support Takuya' and the comments from Sebatien = proposal. A in addition it could be used for routing purposes in a SIP Proxy to = choose the best MGC/MG.=20 EG in PSTN/ISDN the "data-call" can be only transferred over 64kbit/s = trunks. This can be used for a efficient coos of the correct MGC/MG = combination with the clearmode codec. Best Regards Roland=20 > -----Urspr=FCngliche Nachricht----- > Von: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org]Im Auftrag > von GARCIN Sebastien RD-CORE-ISS > Gesendet: Donnerstag, 9. Dezember 2004 13:41 > An: Takuya Sawada; fluffy@cisco.com; iptel@ietf.org > Betreff: RE: [Iptel] Calling Party Category >=20 >=20 > Hi, >=20 > I would like to support Takuya' proposal. I'd also like to=20 > point out that there are clear uses cases for the calling=20 > party's category and operators experience those requirements=20 > every day in their networks.=20 >=20 > Here is a brief summary of those that relate to the "payphone" value: >=20 > Charging > -------- > The cpc value "payphone" is used for charging purposes >=20 > Services > -------- > Some services (e.g. Call return, Freephone services) use the=20 > "payphone" value. >=20 > The fact that we are in a pure SIP or ISUP environment does=20 > not change those requirements. >=20 > Regards, > S=E9bastien > =20 >=20 > -----Message d'origine----- > De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org]=20 > De la part de Takuya Sawada > Envoy=E9 : jeudi 9 d=E9cembre 2004 13:22 > =C0 : fluffy@cisco.com; iptel@ietf.org > Objet : Re: [Iptel] Calling Party Category >=20 > Hi, >=20 > Regarding 1), I think the requirements from those who reqire=20 > cpc parameter are simple and clear; carry the ISUP cpc=20 > information in SIP messages with tel URI. > Use cases are varied as they are varied in ISUP. >=20 > Regaerding 2), IMHO, cpc parameter will be used with=20 > P-Asserted-Identity header. In this scenario, trust domains=20 > model described in RFC 3324 is enough solution for security=20 > and authorization issues. Anyway we will require cpc value to=20 > be asserted by the network as it is in ISUP. >=20 > I totally agree that 'because ISUP has it' is not sufficient=20 > to move it forward as an iptel WG item. During the discussion=20 > I feel it is very difficult to justify cpc work for iptel=20 > work item beyond 'because ISUP has it'. >=20 > Now I propose that let's move cpc draft forward as an=20 > individual document and make it an informational RFC. It may=20 > be a good idea to add the limited scope of cpc and some use cases. > If we can find more complete and general solution to cover=20 > cpc work later, we will make it a standard track RFC. > I think we did that way for network asserted identity. >=20 > How do people think about the above idea? >=20 > Note that according RFC 3966, new tel URI RFC, an=20 > informational RFC is sufficient for optional tel URI parameters. >=20 > Regards, > Takuya > >=20 > > I promised to start a thread on this and figure out what=20 > people want=20 > > to do with it and if we understand the requirements for it then > > propose next steps. > >=20 > > Fortunately, there is a thread going in the sip mailing=20 > list. I would=20 > > summarize that thread as: > >=20 > > 1) the requirements and use case are varied and not clear > > 2) they involved complex security and authorization issues > > 3) SAML looks like it might help with many of them > > 4) there are issues with extension and scope of future categories > >=20 > > This makes me very uncomfortable with moving forward with this work = > > right now as a WG item in IPTEL. What I suggest is that we=20 > shelve this=20 > > work for now and let sipping figure out what the=20 > requirements are and=20 > > if the solutions looks like we need to add something to the=20 > tel URL,=20 > > revive the draft and figure out what to do with it. > >=20 > > What do people think of this? Folks ok with this? I will=20 > take silence=20 > > as well, just a fact of life on the iptel list :-) > >=20 > > Cullen > >=20 > >=20 > >=20 > > _______________________________________________ > > Iptel mailing list > > Iptel@ietf.org > > https://www1.ietf.org/mailman/listinfo/iptel >=20 >=20 > -------- > Takuya Sawada > KDDI Corporation (KDDI) > Garden Air Tower, 3-10-10, Iidabashi, > Chiyoda-ku, Tokyo 102-8460, Japan > Tel: +81-3-6678-2997 > Fax: +81-3-6678-0286 > tu-sawada@kddi.com >=20 > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel >=20 > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel >=20 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Dec 9 15:35:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01612 for ; Thu, 9 Dec 2004 15:35:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcV80-0006J6-HR for iptel-web-archive@ietf.org; Thu, 09 Dec 2004 15:43:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcUrp-0005pD-CX; Thu, 09 Dec 2004 15:26:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcUnD-0002iK-Ud for iptel@megatron.ietf.org; Thu, 09 Dec 2004 15:21:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00202 for ; Thu, 9 Dec 2004 15:21:38 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcUuG-0005z2-O4 for iptel@ietf.org; Thu, 09 Dec 2004 15:28:57 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 09 Dec 2004 12:24:12 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB9KL9m4001674; Thu, 9 Dec 2004 12:21:10 -0800 (PST) Received: from [10.32.131.131] ([10.32.131.131]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUQ09591; Thu, 9 Dec 2004 12:21:16 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 09 Dec 2004 12:21:21 -0800 Subject: Re: [Iptel] Calling Party Category From: Cullen Jennings To: Takuya Sawada , "iptel@ietf.org" Message-ID: In-Reply-To: <200412092121.HGE47900.B-BXEUVBT@kddi.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Not really disagreeing with but adding a bit more inline ... On 12/9/04 4:21 AM, "Takuya Sawada" wrote: > Hi, > > Regarding 1), I think the requirements from those who reqire > cpc parameter are simple and clear; carry the ISUP cpc > information in SIP messages with tel URI. > Use cases are varied as they are varied in ISUP. > It seems that this is better addressed by something like SIP-T that can explicitly deal with caring all the ISUP that is needed. > Regaerding 2), IMHO, cpc parameter will be used with > P-Asserted-Identity header. In this scenario, trust domains > model described in RFC 3324 is enough solution for security > and authorization issues. Anyway we will require cpc value to > be asserted by the network as it is in ISUP. P-Asserted-Identity was an Information document not standards track because it had a very limited deployment model. It solved a very specific problem of dealing call trace for anonymous calls in a particular walled garden model. > > I totally agree that 'because ISUP has it' is not sufficient > to move it forward as an iptel WG item. During the discussion > I feel it is very difficult to justify cpc work for iptel > work item beyond 'because ISUP has it'. > > Now I propose that let's move cpc draft forward as an individual > document and make it an informational RFC. It may be a good idea > to add the limited scope of cpc and some use cases. > If we can find more complete and general solution to cover cpc work > later, we will make it a standard track RFC. > I think we did that way for network asserted identity. > > How do people think about the above idea? > > Note that according RFC 3966, new tel URI RFC, an informational > RFC is sufficient for optional tel URI parameters. > > Regards, > Takuya >> >> I promised to start a thread on this and figure out what people want to do >> with it and if we understand the requirements for it then propose next >> steps. >> >> Fortunately, there is a thread going in the sip mailing list. I would >> summarize that thread as: >> >> 1) the requirements and use case are varied and not clear >> 2) they involved complex security and authorization issues >> 3) SAML looks like it might help with many of them >> 4) there are issues with extension and scope of future categories >> >> This makes me very uncomfortable with moving forward with this work right >> now as a WG item in IPTEL. What I suggest is that we shelve this work for >> now and let sipping figure out what the requirements are and if the >> solutions looks like we need to add something to the tel URL, revive the >> draft and figure out what to do with it. >> >> What do people think of this? Folks ok with this? I will take silence as >> well, just a fact of life on the iptel list :-) >> >> Cullen >> >> >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel > > > -------- > Takuya Sawada > KDDI Corporation (KDDI) > Garden Air Tower, 3-10-10, Iidabashi, > Chiyoda-ku, Tokyo 102-8460, Japan > Tel: +81-3-6678-2997 > Fax: +81-3-6678-0286 > tu-sawada@kddi.com > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Dec 9 15:37:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01703 for ; Thu, 9 Dec 2004 15:37:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcV9A-0006KJ-LC for iptel-web-archive@ietf.org; Thu, 09 Dec 2004 15:44:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcUrq-0005q7-KW; Thu, 09 Dec 2004 15:26:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcUpP-0004GH-Ca for iptel@megatron.ietf.org; Thu, 09 Dec 2004 15:23:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00419 for ; Thu, 9 Dec 2004 15:23:53 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcUwQ-00061N-Mi for iptel@ietf.org; Thu, 09 Dec 2004 15:31:12 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 09 Dec 2004 12:26:14 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iB9KNIPv003292; Thu, 9 Dec 2004 12:23:18 -0800 (PST) Received: from [10.32.131.131] ([10.32.131.131]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUQ09841; Thu, 9 Dec 2004 12:23:18 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 09 Dec 2004 12:23:24 -0800 Subject: Re: [Iptel] Calling Party Category From: Cullen Jennings To: GARCIN Sebastien RD-CORE-ISS , Takuya Sawada , "iptel@ietf.org" Message-ID: In-Reply-To: <49E7012A614B024B80A7D175CB9A64ECD12FAC@ftrdmel1.rd.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Yes, I agree that there is an interest in billing calls from payphone differently than from say, bordellos (thanks Dave :-). However, I'm sitting here reading the charter of iptel and sipping and this seem like a great se= t of requirements to take to sipping and figure out how to solve the problem. The connection to a tel URL seem very tenuous other than it's a place this data could be stuck for transport. On 12/9/04 4:41 AM, "GARCIN Sebastien RD-CORE-ISS" wrote: > Hi, >=20 > I would like to support Takuya' proposal. I'd also like to point out that > there are clear uses cases for the calling party's category and operators > experience those requirements every day in their networks. >=20 > Here is a brief summary of those that relate to the "payphone" value: >=20 > Charging > -------- > The cpc value "payphone" is used for charging purposes >=20 > Services > -------- > Some services (e.g. Call return, Freephone services) use the "payphone" v= alue. >=20 > The fact that we are in a pure SIP or ISUP environment does not change th= ose > requirements. >=20 > Regards, > S=E9bastien > =20 >=20 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Dec 9 17:05:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16987 for ; Thu, 9 Dec 2004 17:05:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcWX2-0002bP-HF for iptel-web-archive@ietf.org; Thu, 09 Dec 2004 17:13:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcWEB-0006nu-Bz; Thu, 09 Dec 2004 16:53:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcW0M-0006mR-GL for iptel@megatron.ietf.org; Thu, 09 Dec 2004 16:39:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12356 for ; Thu, 9 Dec 2004 16:39:16 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcW7P-0001EI-IP for iptel@ietf.org; Thu, 09 Dec 2004 16:46:36 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 09 Dec 2004 14:44:20 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB9Lch5O012315 for ; Thu, 9 Dec 2004 13:38:45 -0800 (PST) Received: from [10.32.131.131] ([10.32.131.131]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUQ17926; Thu, 9 Dec 2004 13:38:42 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 09 Dec 2004 13:38:48 -0800 From: Cullen Jennings To: "iptel@ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Subject: [Iptel] FW: IPTEL Minutes - IETF 61 X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit ------ Forwarded Message From: Cullen Jennings Date: Thu, 09 Dec 2004 12:46:42 -0800 To: Cc: Jonathan Rosenberg , Cullen Jennings Subject: IPTEL Minutes - IETF 61 TUESDAY, November 9, 2004, 1300-1400 ==================================== CHAIRS: Jonathan Rosenberg Cullen Jennings Note-taker - Spencer Dawkins Status Update: Since last meeting we have published TRIP MIB and CPL. 2806bis was published shortly after the meeting. Enum dip indicator: Richard Stastny presented draft-stastny-iptel-tel-enumdi. This would add a flag that indicated that the ENUM dip had been done and did not need to be repeated. General consensus in room was to accept this work. Some discussion about if there should be a way to indicate that dips had been done to different roots. Eventually decided that there are no current documents specifying ENUM for multiple roots and we would not do this. draft-ietf-iptel-tel-np-02.txt Revision is coming and it will be WGLC and hopefully finished. Volunteers agreed to review. Some interested in implementing this. draft-ietf-iptel-trunk-group-02.txt Volunteers agreed to review. Need to WGLC. Some interested in implementing this. Dial string draft: will go forward as individual submission Calling party category draft: This has expired with very little response to comments. There is substantial work left to finish this. One or two people in room thought they might implement it. Not clear what the key uses of it are. Will discuss on list if we want to move forward with this (as a WG item) or not. It could always be done as individual. More detailed notes follow: * TRIP MIB, CPL published as RFCs since last meeting of IPTel * rfc2096bis in RFC editor queue 20 min Enum Indicator Richard Stastny - draft-stastny-iptel-tel-enumdi-00.txt * Also heads-uped in ENUM * Add "enumdi" to E.164 tel URI saying "we've already done an ENUM lookup, so you don't have to try again when you're resolving the URI" * "MUST NOT attempt e164.arpa resolution" requirement also discussed in ENUM * Who can add "enumdi?" - if you would do ENUM, you can add it, and an endpoint can add it to the original URI before anyone tries to resolve it * Cullen points out that this is not a mandatory parameter, so network elements that don't understand it will still attempt the lookup * <>This is good. Why limit it to e164.arpa? There will be other lightweight mechanisms, too. * <><>2806bis should probably also be a SHOULD - how consistent do we need to be?Makes sense, but do we need to say this in the current draft? * <><>If we allow this for multiple routes, we need to say what routes have been queried. Should we add a translation counter to help people realize a URI has been changed? How does transitive trust work? And please don't change semantics in a future rev - do it now, or don't do it. * Allow other roots in the first version, too - won't this slow the document down on the approval process? * If you know who did the lookup, you can decide whether to trust them based on that knowledge. * Leave it like is, or extend it (loop counter or something else)? Not a significant difference in sense of the room. We're trying to shut the working group down, so the authors will be guided by whatever the chairs ask for. * We don't actually have a spec that says you can legitimately query against another domain. Jonathan doesn't get it... no harm in redoing the lookup ("dip"). * Punt this question to the ENUM working group chair :-) - service providers would like to do something like this. Would like to continue as a working group document, would like to rev quickly and WGLC quickly. * Ignoring this is like ignoring NATs - don't put our heads in the sand. We'll block for six months to a year if we add alternative roots. * Accept as WG item with no changes - humm? Sense of room is "yes". [still needs to be confirmed on the list, right?] 30 min Plan for concluding work - Chairs Et.Al. draft-ietf-iptel-tel-np-02.txt draft-ietf-iptel-trunk-group-02.txt draft-ietf-iptel-tgrep-04.txt * Number portability draft revision is coming and addresses comments to date. * Volunteer reviewers were selected for NP and trunk group drafts. * Lite interest in implementing NP extensions and trunk group drafts. Will be immediately WGLCed. Reviewers, please report back during that timeframe. Dial string draft * will go forward as individual submission Calling party category draft * has expired, no responses to comments received * some concerns raised (trust boundaries, asserted identity) - not near done with this one. * We discussed making this a WG item many moons ago, and decided not to do it for pretty much the same reasons being raised now. * This work will take some time to get right. If the working group takes it on, we have to expect to come to consensus before we can close. * This work is useful, but maybe doesn't matter whether it's a WG item or not. * Who would implement? maybe one or two in the room * Not sure who needs this - what problem is being solved? duplicate parameters, endpoint identification - what? Maybe emergency services and coin phones, or something like that. Check with development groups and discuss this on the list in a couple of weeks after end of IETF. ENUM Dip? * We think we decided to do this at the beginning of the meeting. ------ End of Forwarded Message _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Dec 10 01:47:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00239 for ; Fri, 10 Dec 2004 01:47:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccefo-0005J3-SG for iptel-web-archive@ietf.org; Fri, 10 Dec 2004 01:54:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cce7s-0000CU-Bu; Fri, 10 Dec 2004 01:19:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcdsP-0005cS-1f for iptel@megatron.ietf.org; Fri, 10 Dec 2004 01:03:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27690 for ; Fri, 10 Dec 2004 01:03:36 -0500 (EST) Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcdzW-0004cx-TE for iptel@ietf.org; Fri, 10 Dec 2004 01:10:59 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Fri, 10 Dec 2004 07:02:46 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Dec 2004 07:03:02 +0100 Message-Id: From: "Jesske, R" To: fluffy@cisco.com, tu-sawada@kddi.com, iptel@ietf.org Subject: AW: [Iptel] Calling Party Category Date: Fri, 10 Dec 2004 07:03:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Some comments to your addings. Using SIP-T or SIP-I assumes that the applications have to support the full ISUP stack, but we want to use SIP. The P-Asserted-ID is used within standards from 3GPP, ITU-T, ETSI, T1S1... so I don't think that it is very limited... I don't think that the use is very limited e.G: -Billing -Routing based on originating indications (e.G. special domainnames or numbergroups) -Services selective Call Forwarding -incomming screening of Calls based on a trusted number ... Best Regards Roland > -----Ursprungliche Nachricht----- > Von: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org]Im Auftrag > von Cullen Jennings > Gesendet: Donnerstag, 9. Dezember 2004 21:21 > An: Takuya Sawada; iptel@ietf.org > Betreff: Re: [Iptel] Calling Party Category > > > > Not really disagreeing with but adding a bit more inline ... > > On 12/9/04 4:21 AM, "Takuya Sawada" wrote: > > > Hi, > > > > Regarding 1), I think the requirements from those who reqire > > cpc parameter are simple and clear; carry the ISUP cpc > > information in SIP messages with tel URI. > > Use cases are varied as they are varied in ISUP. > > > It seems that this is better addressed by something like > SIP-T that can > explicitly deal with caring all the ISUP that is needed. > > > Regaerding 2), IMHO, cpc parameter will be used with > > P-Asserted-Identity header. In this scenario, trust domains > > model described in RFC 3324 is enough solution for security > > and authorization issues. Anyway we will require cpc value to > > be asserted by the network as it is in ISUP. > P-Asserted-Identity was an Information document not standards > track because > it had a very limited deployment model. It solved a very > specific problem of > dealing call trace for anonymous calls in a particular walled > garden model. > > > > > I totally agree that 'because ISUP has it' is not sufficient > > to move it forward as an iptel WG item. During the discussion > > I feel it is very difficult to justify cpc work for iptel > > work item beyond 'because ISUP has it'. > > > > Now I propose that let's move cpc draft forward as an individual > > document and make it an informational RFC. It may be a good idea > > to add the limited scope of cpc and some use cases. > > If we can find more complete and general solution to cover cpc work > > later, we will make it a standard track RFC. > > I think we did that way for network asserted identity. > > > > How do people think about the above idea? > > > > Note that according RFC 3966, new tel URI RFC, an informational > > RFC is sufficient for optional tel URI parameters. > > > > Regards, > > Takuya > >> > >> I promised to start a thread on this and figure out what > people want to do > >> with it and if we understand the requirements for it then > propose next > >> steps. > >> > >> Fortunately, there is a thread going in the sip mailing > list. I would > >> summarize that thread as: > >> > >> 1) the requirements and use case are varied and not clear > >> 2) they involved complex security and authorization issues > >> 3) SAML looks like it might help with many of them > >> 4) there are issues with extension and scope of future categories > >> > >> This makes me very uncomfortable with moving forward with > this work right > >> now as a WG item in IPTEL. What I suggest is that we > shelve this work for > >> now and let sipping figure out what the requirements are and if the > >> solutions looks like we need to add something to the tel > URL, revive the > >> draft and figure out what to do with it. > >> > >> What do people think of this? Folks ok with this? I will > take silence as > >> well, just a fact of life on the iptel list :-) > >> > >> Cullen > >> > >> > >> > >> _______________________________________________ > >> Iptel mailing list > >> Iptel@ietf.org > >> https://www1.ietf.org/mailman/listinfo/iptel > > > > > > -------- > > Takuya Sawada > > KDDI Corporation (KDDI) > > Garden Air Tower, 3-10-10, Iidabashi, > > Chiyoda-ku, Tokyo 102-8460, Japan > > Tel: +81-3-6678-2997 > > Fax: +81-3-6678-0286 > > tu-sawada@kddi.com > > > > _______________________________________________ > > Iptel mailing list > > Iptel@ietf.org > > https://www1.ietf.org/mailman/listinfo/iptel > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Dec 10 15:08:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12669 for ; Fri, 10 Dec 2004 15:08:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcrBJ-0004Oa-TK for iptel-web-archive@ietf.org; Fri, 10 Dec 2004 15:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcqwK-0000ud-5Z; Fri, 10 Dec 2004 15:00:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcqmC-0004UK-Ev for iptel@megatron.ietf.org; Fri, 10 Dec 2004 14:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10634 for ; Fri, 10 Dec 2004 14:50:02 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcqtQ-0003op-1T for iptel@ietf.org; Fri, 10 Dec 2004 14:57:34 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 10 Dec 2004 11:49:45 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBAJnSPv025660; Fri, 10 Dec 2004 11:49:29 -0800 (PST) Received: from [10.32.131.131] ([10.32.131.131]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUQ96625; Fri, 10 Dec 2004 11:49:21 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 10 Dec 2004 11:49:28 -0800 Subject: Re: AW: [Iptel] Calling Party Category From: Cullen Jennings To: "Jesske, R" , , "iptel@ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit On 12/9/04 10:03 PM, "Jesske, R" wrote: > Using SIP-T or SIP-I assumes that the applications have to support the full > ISUP stack, but we want to use SIP. Yes - I agree, but this is the grief I am having is an arguments of the form: People come and say please add parameter X from ISUP. Then folks say sure, why what do you want to do with it? Then the answer is well it is in ISUP so we must have it. If this is true for all values of X then you need all of ISUP and just go do ISUP. If their is some feature you want (that ISUP can do), like special billing from a payphone, then don't even mention ISUP. Say "I would like to be able to bill payphone users extra" - take that to the sipping WG and I predict people will come up with a solution to the problem. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Sat Dec 11 03:11:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01354 for ; Sat, 11 Dec 2004 03:11:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cd2So-0004wn-7Z for iptel-web-archive@ietf.org; Sat, 11 Dec 2004 03:18:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cd2H9-0006hd-RJ; Sat, 11 Dec 2004 03:06:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cd2Fu-0006Hw-J0 for iptel@megatron.ietf.org; Sat, 11 Dec 2004 03:05:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00991 for ; Sat, 11 Dec 2004 03:05:28 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cd2NE-0004pU-PI for iptel@ietf.org; Sat, 11 Dec 2004 03:13:07 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 Dec 2004 01:10:48 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBB84om4000828; Sat, 11 Dec 2004 00:04:50 -0800 (PST) Received: from cisco.com (sjc-vpn5-61.cisco.com [10.21.88.61]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AZS85456; Sat, 11 Dec 2004 00:13:59 -0800 (PST) Message-ID: <41BAAA25.2010502@cisco.com> Date: Sat, 11 Dec 2004 00:04:53 -0800 From: Manjunath Bangalore User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings References: X-Spam-Score: 0.7 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Dhaval N Shah , Salama , "iptel@ietf.org" , Hussein, rajneesh@cisco.com Subject: [Iptel] Re: tgrep 04 comments X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1595731406==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 --===============1595731406== Content-Type: multipart/alternative; boundary="------------050508060600030901080301" --------------050508060600030901080301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cullen, I was hoping to have the next rev out by early Jan. -Manjax Cullen Jennings wrote: > > Any ETA on a new rev of this draft? --------------050508060600030901080301 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Cullen,

I was hoping to have the next rev out by early Jan.

-Manjax

Cullen Jennings wrote:
Re: tgrep 04 comments
Any ETA on a new rev of this draft?

--------------050508060600030901080301-- --===============1595731406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============1595731406==-- From iptel-bounces@ietf.org Sat Dec 11 03:22:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02077 for ; Sat, 11 Dec 2004 03:22:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cd2da-00059p-PK for iptel-web-archive@ietf.org; Sat, 11 Dec 2004 03:29:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cd2Uo-00016I-OF; Sat, 11 Dec 2004 03:20:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cd2Tw-0000jW-Dt for iptel@megatron.ietf.org; Sat, 11 Dec 2004 03:20:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01898 for ; Sat, 11 Dec 2004 03:19:58 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cd2bH-00055S-Hu for iptel@ietf.org; Sat, 11 Dec 2004 03:27:36 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 11 Dec 2004 00:22:39 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBB8JP5M002978; Sat, 11 Dec 2004 00:19:26 -0800 (PST) Received: from cisco.com (sjc-vpn5-61.cisco.com [10.21.88.61]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AZS85780; Sat, 11 Dec 2004 00:28:30 -0800 (PST) Message-ID: <41BAAD8C.5090907@cisco.com> Date: Sat, 11 Dec 2004 00:19:24 -0800 From: Manjunath Bangalore User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jyothij@huawei.com Subject: Re: [Iptel] Re: tgrep 04 comments References: <001001c4ddb9$49aefeb0$d204120a@china.huawei.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: "'Cullen Jennings'" , iptel@ietf.org, "'Dhaval N Shah'" , rajneesh@cisco.com, "'Hussein F Salama'" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0621539248==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 --===============0621539248== Content-Type: multipart/alternative; boundary="------------000608010803050408050107" --------------000608010803050408050107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jyoti, There's no attribute currently to express "charge" or "pricing" information associated with a route. It was considered at some point for TGREP but it was dropped b'coz of the complexity of representing it. For instance, the price offered by a provider can vary by time of day, it can potentially be based on an agreement between two service providers interconnecting with each other. Least Cost routing choices and Grades of service offered by a carrier can affect pricing. There could be other factors as well. Expressing this complex interplay between different factors that determine pricing is non-trivial to represent. -Manjax Jyoti wrote: > Hello All, > For TGrep and TRIP - pls can you let me know if any charging data > framework is available i.e if any charge related information can be > updated , stored and queried. > Thanks > Jyoti > > -----Original Message----- > *From:* iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] *On > Behalf Of *Cullen Jennings > *Sent:* Thursday, December 09, 2004 7:27 AM > *To:* Manjunath S Bangalore > *Cc:* Dhaval N Shah; iptel@ietf.org; Hussein F Salama; > rajneesh@cisco.com > *Subject:* [Iptel] Re: tgrep 04 comments > > > Any ETA on a new rev of this draft? > --------------000608010803050408050107 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jyoti,

There's no attribute currently to express "charge" or "pricing" information associated with a route. It was considered at some point for TGREP but it was dropped b'coz of the complexity of representing it. For instance, the price offered by a provider can vary by time of day,  it can potentially be based on an agreement between two service providers interconnecting with each other. Least Cost routing choices and Grades of service offered by a carrier can affect pricing. There could be other factors as well. Expressing this complex interplay between different factors that determine pricing is non-trivial to represent.

-Manjax

Jyoti wrote:
Message
Hello All,
For TGrep and TRIP - pls can you let me know if any charging data framework is available i.e if any charge related information can be updated , stored and queried.
Thanks
Jyoti
-----Original Message-----
From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of Cullen Jennings
Sent: Thursday, December 09, 2004 7:27 AM
To: Manjunath S Bangalore
Cc: Dhaval N Shah; iptel@ietf.org; Hussein F Salama; rajneesh@cisco.com
Subject: [Iptel] Re: tgrep 04 comments


Any ETA on a new rev of this draft?

--------------000608010803050408050107-- --===============0621539248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0621539248==-- From iptel-bounces@ietf.org Sat Dec 11 14:45:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13723 for ; Sat, 11 Dec 2004 14:45:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdDIY-0000oZ-Ba for iptel-web-archive@ietf.org; Sat, 11 Dec 2004 14:52:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdD5Y-0000gu-9f; Sat, 11 Dec 2004 14:39:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdCzS-0007hS-6u for iptel@megatron.ietf.org; Sat, 11 Dec 2004 14:33:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12671 for ; Sat, 11 Dec 2004 14:33:12 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdD6u-0000Um-Gs for iptel@ietf.org; Sat, 11 Dec 2004 14:40:56 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Dec 2004 12:38:41 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBBJWePv006906; Sat, 11 Dec 2004 11:32:41 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn1-439.cisco.com [10.21.97.183]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUR49302; Sat, 11 Dec 2004 11:32:39 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 11 Dec 2004 11:32:46 -0800 From: Cullen Jennings To: Manjunath S Bangalore Message-ID: In-Reply-To: <41BAAA25.2010502@cisco.com> Mime-version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Dhaval N Shah , "iptel@ietf.org" , Hussein F Salama , rajneesh@cisco.com Subject: [Iptel] Re: tgrep 04 comments X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0205771296==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0205771296== Content-type: multipart/alternative; boundary="B_3185609567_10047956" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3185609567_10047956 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit On 12/11/04 12:04 AM, "Manjunath Bangalore" wrote: > Cullen, > > I was hoping to have the next rev out by early Jan. > > -Manjax > > Cullen Jennings wrote: >> Re: tgrep 04 comments >> Any ETA on a new rev of this draft? >> > > Great - thank you - I would really like to get this done well before everyone getting busy writing drafts fro next IETF. --B_3185609567_10047956 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: tgrep 04 comments On 12= /11/04 12:04 AM, "Manjunath Bangalore" <manjax@cisco.com> wr= ote:

Cullen,

I was hoping to have the next rev out by early Jan.

-Manjax

Cullen Jennings wrote:
Re: tgrep 04 comments
 Any ETA on a new rev of this draft?
  



Great -  thank you - I would really like to get this done well before = everyone getting busy writing drafts fro next IETF.
 --B_3185609567_10047956-- --===============0205771296== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0205771296==-- From iptel-bounces@ietf.org Mon Dec 13 03:56:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11659 for ; Mon, 13 Dec 2004 03:56:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdm8Q-0007dd-Qm for iptel-web-archive@ietf.org; Mon, 13 Dec 2004 04:04:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdlyj-000429-A9; Mon, 13 Dec 2004 03:54:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdluf-00033G-OI for iptel@megatron.ietf.org; Mon, 13 Dec 2004 03:50:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11346 for ; Mon, 13 Dec 2004 03:50:36 -0500 (EST) Received: from usjk1002.kddi.com ([211.4.169.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdm2R-0007NG-Gr for iptel@ietf.org; Mon, 13 Dec 2004 03:58:40 -0500 Received: from usjk1005.kddi.com (usjk1005 [10.96.2.2]) by usjk1002.kddi.com with ESMTP id iBD8noN07613; Mon, 13 Dec 2004 17:49:50 +0900 (JST) Received: from usjk1038 (localhost [127.0.0.1]) by usjk1005.kddi.com with SMTP id iBD8nnb08331; Mon, 13 Dec 2004 17:49:49 +0900 (JST) Received: from KDDI-0403PC0002 ([10.100.94.32]) by usjk1010.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20041213084943.QDBA12322.usjk1010.kddi.com@KDDI-0403PC0002>; Mon, 13 Dec 2004 17:49:43 +0900 To: fluffy@cisco.com, R.Jesske@t-com.net, tu-sawada@kddi.com, iptel@ietf.org Subject: Re: AW: [Iptel] Calling Party Category From: Takuya Sawada References: In-Reply-To: Message-Id: <200412131749.BHD06012.XBTBB-EVU@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Mon, 13 Dec 2004 17:49:43 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-WAuditID: 0412131749430000113200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a I would also like to keep SIP clean, really. I would be happy if we could throw ISUP away and go with pure SIP. We know it is not possible. Can we understand cpc work along the following way? - It is NOT a SIP extension. cpc parameter does not affect any SIP behaviour. (Actually, it is a tel URI extension) - It is just additional information to be added to the resource indicated by tel URI in a certain circumstances. - Billing from a payphone is a use case, not a requirement. Requirement is that cpc parameter value range should cover all the characteristics used in ISUP network at minimum. It is not the work for SIPPING WG. --- For the general problem, adding other parameters X from ISUP, I think we should be careful in doing that. I hope there are not so much candidates, though I can imagine ATP, access transport prameter, and UUS, user-to-user information..... I noticed that Q.1980.1, which is in progress in ITU-T, is related to that type of problem. I am not so familiar with that work that I am not sure it will fit and cover all the problems. Regards, Takuya > On 12/9/04 10:03 PM, "Jesske, R" wrote: > > > Using SIP-T or SIP-I assumes that the applications have to support the full > > ISUP stack, but we want to use SIP. > > Yes - I agree, but this is the grief I am having is an arguments of the > form: > > People come and say please add parameter X from ISUP. Then folks say sure, > why what do you want to do with it? Then the answer is well it is in ISUP so > we must have it. > > If this is true for all values of X then you need all of ISUP and just go do > ISUP. > > If their is some feature you want (that ISUP can do), like special billing > from a payphone, then don't even mention ISUP. Say "I would like to be able > to bill payphone users extra" - take that to the sipping WG and I predict > people will come up with a solution to the problem. > -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Dec 14 02:14:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24440 for ; Tue, 14 Dec 2004 02:14:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce70j-0007tZ-2j for iptel-web-archive@ietf.org; Tue, 14 Dec 2004 02:22:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce6re-0000hZ-M0; Tue, 14 Dec 2004 02:12:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce6pV-0008CX-6L for iptel@megatron.ietf.org; Tue, 14 Dec 2004 02:10:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21106 for ; Tue, 14 Dec 2004 02:10:40 -0500 (EST) Received: from [203.196.162.98] (helo=newmail.india.globespan.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce6xS-0007pJ-1E for iptel@ietf.org; Tue, 14 Dec 2004 02:18:55 -0500 Received: from kheterg ([172.26.0.219]) by newmail.india.globespan.net (8.11.6/8.11.6) with SMTP id iBE78bQ10095 for ; Tue, 14 Dec 2004 12:38:37 +0530 From: "Gaurav.Kheterpal" To: Date: Tue, 14 Dec 2004 12:41:06 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: [Iptel] FW: SIP - TEL URI Implementation Query X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Hello, I am currently implementing support for URI's in our User Agent as per RFC 3966/ RFC 2806-bis standards. I had the following doubts regarding the same. Any inputs will be highly appreciated. 1. Contact Header: As per RFC 3261 Section 8.1.1.8, it mentions that this URI must be in either SIP/ SIPS format. In Section 10.2.1, it is mentioned that for registrations, the Contact header field can contain any URI Scheme (e.g the tel URL, RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32]) as Contacts for an address-of-record. Does this mean that the 'Contact' field in an INVITE message must always be a SIP/SIPS URI while in a REGISTER message, it can be a SIP/SIPS/TEL/Mailto URI ? 2. Besides 'Request URI' and 'To:' header fields, can the TEL URI be present in any other INVITE header values (e.g. Via, Route Header, Contact etc). In other words, which fields in the INVITE request does the proxy scan for possible tel->sip translation using ENUM/ any other mechanism ? In case, there is no other field which contains this information, how is the TEL URI information propagated across intermediate proxies when the UA is configured with a outbound proxy having a defined route set. If the defined route set is proxy 1-> proxy 2 in the below diagram, the request will be formed using: INVITE sip:proxy1 Route: To: User A Proxy 1 Proxy 2 User B | | | | | INVITE F1 | | | |--------------->| | | Does this mean that in such a case, the only parameter which contains the TEL URI is the 'To' field. As I understand, this field is never processed by the proxies unless they implement privacy/ RFC 3324(5) ?? I am current not aware of any proxy which is capable of handling TEL URI's, any information/ links regarding the same will be highly useful. Thanks in advance for your help. regards, Gaurav _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Dec 15 02:21:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24803 for ; Wed, 15 Dec 2004 02:21:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeTbk-0004wy-GR for iptel-web-archive@ietf.org; Wed, 15 Dec 2004 02:30:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeTRt-0003aw-4V; Wed, 15 Dec 2004 02:19:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeTRJ-0003Nr-UZ; Wed, 15 Dec 2004 02:19:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22620; Wed, 15 Dec 2004 02:19:11 -0500 (EST) Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeTZU-0004sq-6w; Wed, 15 Dec 2004 02:27:40 -0500 Received: from g8pbq.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Wed, 15 Dec 2004 08:18:21 +0100 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Dec 2004 08:18:37 +0100 Message-Id: From: "Jesske, R" To: An.Nguyen@ncs.gov, taylor@nortelnetworks.com Subject: AW: [Sip] RE: [Iptel] Calling Party's Category Date: Wed, 15 Dec 2004 08:18:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org, sip@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Hello An The below mentioned draft is expiered. There is no work in SIP or IPTEL = at the moment, but we hope it will. We brought up the issue, becuse we see the demand on such a element in = SIP. Best Regerds Roland > -----Urspr=FCngliche Nachricht----- > Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]Im Auftrag von > Nguyen, An > Gesendet: Dienstag, 30. November 2004 19:00 > An: 'Tom Taylor' > Cc: iptel@ietf.org; sip@ietf.org; Jesske, Roland > Betreff: [Sip] RE: [Iptel] Calling Party's Category >=20 >=20 > Mr. Taylor; >=20 > I am just curious ... What is the status of the Internet Draft? >=20 > An >=20 >=20 >=20 > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortelnetworks.com] > Sent: Tuesday, November 30, 2004 10:07 AM > To: Jesske, R > Cc: iptel@ietf.org; sip@ietf.org > Subject: Re: [Iptel] Calling Party's Category >=20 >=20 > The question was what the requirement is for this sort of=20 > indication. How > is it used? >=20 > Jesske, R wrote: > > Dear all, > > in the past there was a discussion regarding the specification of a > Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) > > What is the actual status of this activity.=20 > > We are still interested in such kind of originating=20 > indication if the > call/communication is coming from a normal SIP user or a SIP=20 > -Payphone or > SIP-Hotelphone.=20 > > Is there a interest from other parties in this issue? > >=20 > > Best Regards > >=20 > > Roland > >=20 > > Deutsche Telekom AG > > T-Com Zentrale > > Roland Jesske, TE332-2 > > Section TE33; Signalling, Gateways and Switching Systems=20 > > Am Kavalleriesand 3, 64295 Darmstadt, Germany > > Phone: +49 6151 83-5940=20 > > Fax: +49 6151 83-4577=20 > > email: r.jesske@t-com.net > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Iptel mailing list > > Iptel@ietf.org > > https://www1.ietf.org/mailman/listinfo/iptel > >=20 > >=20 >=20 > --=20 > Tom Taylor > Carrier VoIP Standards Development > Nortel Networks > Phone +1 613 763 1496 (ESN 393-1496) > E-mail: taylor@nortelnetworks.com >=20 > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Dec 20 17:13:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17874 for ; Mon, 20 Dec 2004 17:13:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgVwH-0007qo-Lm for iptel-web-archive@ietf.org; Mon, 20 Dec 2004 17:23:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgVgL-0000Ur-IJ; Mon, 20 Dec 2004 17:07:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgVXw-0004Vj-W7 for iptel@megatron.ietf.org; Mon, 20 Dec 2004 16:58:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14792 for ; Mon, 20 Dec 2004 16:58:26 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgVhH-00071p-TQ for iptel@ietf.org; Mon, 20 Dec 2004 17:08:08 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 20 Dec 2004 17:06:47 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from [10.82.241.48] (rtp-vpn2-304.cisco.com [10.82.241.48]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBKLvr9E014555; Mon, 20 Dec 2004 16:57:54 -0500 (EST) Message-ID: <41C74AE2.6000000@cisco.com> Date: Mon, 20 Dec 2004 16:57:54 -0500 From: Flemming Andreasen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: iptel@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA14792 Cc: James Yu Subject: [Iptel] Review of draft-ietf-iptel-tel-np-03.txt X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable Greetings Below, please find review comments for draft-ietf-iptel-tel-np-03.txt.=20 In general, I think the document is close to being done, but there are a=20 few minor issues to address as well as some nits. Non-Editorial =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Section 4, ABNF The production for "global-hex-digits" ends with "*phonedigit-hex". I=20 don't understand what that is for, not least considering the ensuing=20 text for "local-rn" For a "local-rn", the routing number in the "rn" parameter MUST be meaningful in terms of "rn-context". For example, if a national routing number is in the "rn" parameter, the "rn-context" MUST contain a valid E.164 country code after "+" if it is in the "global-hex-digits" format. Section 5.1, 6th paragraph "The network node SHALL ignore the "cic" parameter if it identifies a=20 carrier or service provider associated with that node, or if that=20 parameter contains a code for indicating that a geographic number is=20 supplied (e.g., +1-0110 means "local, translated geographical telephone=20 number provided"). ". Given the normative requirement, we either need=20 some more text or references to explain how we determine if the=20 parameter contains a code for indicating that a geographic number is=20 supplied. Section 5.1, 6th paragraph "The network node SHALL remove the "cic" parameter and look for the "rn"=20 parameter for making the routing decision." I don't see why the network=20 node SHALL remove the "cic" parameter and would in fact argue for at=20 most a MAY. I agree it shall look for the "rn" parameter for making the=20 routing decision though. Section 5.1, 9th and 10th paragraph. Again, I don't see why "the network SHALL remove the "rn" parameter". Section 5.2.4, 1st paragraph "A Public Switched Telephone Network (PSTN) gateway needs to convert between SS7 ISUP and the VoIP protocol such as SIP or H.323. This type of network node SHALL add the corresponding information from the ISUP to the defined parameters to the "tel" URI for routing and the "tel" URI associated with the caller and vice versa." I disagree with the latter part ("and the "tel" URI associated with the=20 caller and vice versa"). We are getting into privacy and security=20 related issues and hence cannot make it mandatory for all. Section 7 Need to add security considerations for using the extensions for the=20 caller (JIP considerations) Editorial and/or nits: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Global Three spaces after period in several places. Not sure if formatting adheres to RFC Editor guidelines (at least I=20 can't get it to print with proper page breaks) - Abstract Should not describe the actual extension parameters in the abstract but=20 rather describe the problem and outline the solution. - Abstract =20 "that NP database dip" =3D> "that an NP database dip" ^^ - Section 2, 1st paragraph "It has been identified that NP has impacts on several works-in-progress=20 at the IETF." =3D> "NP impacts call signaling." or something like that. - Section 2, 3rd paragraph "call set up" =3D> "call setup" - Section 2, 5th paragraph The sentence "Section 5 describes the rules for a network node that deals with=20 some or all of the defined parameters in a "tel" URI" is not accurate since we are only talking about some specific extensions=20 here. The phrase "defined parameters" is used throughout the document to=20 refer to the extensions defined in this document. I'd suggest using=20 another more accurate phrase throughout. - Section 4, 1st paragraph Add some words explaining how this ABNF simply defines new parameters in=20 accordance with the ABNF for "tel" URI provided in RFC 3966. - Section 4, 5th paragraph "...the routing number in the "rn" parameter MUST be meaningful in terms=20 of "rn-context". Although the example that follows helps clarify it for=20 E.164 numbers, it is in general not well defined what "meamingful"=20 means. Please rephrase to make it clearer. - Section 4, last paragraph "...the CIC value in the "cic" parameter MUST be meaningful in terms of=20 "cic-context". Semantics unclear - please rephrase to make it clearer. Section 5.1, 4th paragraph "or routing information" =3D> "or routing number information" (?) Section 5.1, last paragraph "making routing decision" =3D> "making routing decisions" ^ "set to do so or may route the call to a designated network node that=20 will access the NP database or may route the call" =3D> ^^ "set to do so, it may route the call to a designated network node that=20 will access the NP database, or it may route the call" =20 ^^^ = =20 ^ ^^ Section 5.2.2, 6th paragraph "telephone number that is the typical case for the second freephone=20 database access, the" =3D> "telephone number (which is the typical case for the second freephone=20 database access), the" =20 ^^^^^^ ^ Section 5.2.3, 2nd paragraph "For example, if the network node is a PSTN gateway that receives an=20 ISUP message that contains the JIP, the "rn" parameter in the "tel" URI=20 would normally contain the correct location information." Please=20 rephrase (it is the ISUP message that contains the correct location=20 information which is therefore placed in the "rn" parameter in the "tel"=20 URI). Section 5.2.4, 2nd paragraph "put it after the "tel:" in the "tel" URI that is used for routing" =3D> "put it in the global-number-digits or local-number-digits (see RFC=20 3966) part of the "tel" URI that is used for routing" =20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Section 5.2.4, 3rd paragraph "put it after "tel:" in the "tel" URI that is used for routing" =3D> "put it in the global-number-digits or local-number-digits (see RFC=20 3966) part of the "tel" URI that is used for routing" =20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Section 5.2.4, 3rd paragraph "No "rn" SHALL appear in the "tel" URI." =3D> "An "rn" SHALL NOT appear in the "tel" URI." ^^ ^^^ Section 5.2.4, 3rd paragraph "It is outside the scope of this document how to include the "rn"=20 parameter if the local policies require the network node to do so." I=20 don't follow - the previous sentence just said that you are not allowed=20 to do so. Section 6, example B "provider=C6s" =3D> "provider's" Section 6, example E " E. A "tel" URI, tel:+1-202-533-1234;rn=3D+1-202-000-0000;npdi, contai= ns an invalid routing number (e.g., no routing information on "+1- 202-000"), " Example seems to assume prefix-based routing - might be good to clarify=20 that. Section 8 and 9 There are gaps in the reference numbers. In general, it would probably=20 be better to use symbolic references instead of plain numbers. 2806bis-09 is now RFC 3966. -- Flemming =20 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Dec 20 19:26:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28325 for ; Mon, 20 Dec 2004 19:26:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgY0j-0002QB-9v for iptel-web-archive@ietf.org; Mon, 20 Dec 2004 19:36:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgXpn-0002RS-BN; Mon, 20 Dec 2004 19:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgXpG-0002Hd-TF for iptel@megatron.ietf.org; Mon, 20 Dec 2004 19:24:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28221 for ; Mon, 20 Dec 2004 19:24:27 -0500 (EST) Message-Id: <200412210024.TAA28221@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgXyT-0002MI-4t for iptel@ietf.org; Mon, 20 Dec 2004 19:34:11 -0500 Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.43) id 1CgYhE-0000gO-0r for iptel@ietf.org; Mon, 20 Dec 2004 18:20:16 -0700 From: "Brian Rosen" To: Date: Mon, 20 Dec 2004 19:23:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcTm80y2N0HinDkeSTicrwM0E9OB5w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Subject: [Iptel] Review of draft-ietf-iptel-trunk-group-02 X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit I've reviewed this draft for readiness to advance to the IESG. I don't find any substantive issues with the draft from a protocol point of view. As RFC text, the following changes would make a better document 1. Define trunk group, at least informally, at the beginning of the Problem Statement. 2. The problem statement could use substantial rewording. Pointing out the need to specify a trunk group is sufficient. At the very least, that point should be ahead of where you put the parameter. Think about how this reads 3 years from now as an RFC. A self reference should use "this document", although I think the RFC editor fixes things like that. 3. I think REQ1 would be better expressed as "A trunk group parameter MUST be defined as an extension to the TEL uri". That makes the second paragraph make more sense. 4. The last paragraph in 4.2 is misplaced. It's actually normative text for the parameter itself. You can discuss a solution here, but you can't make it be the MUST language for the extension itself. This might be the only thing I think we have to fix. This mistake is common to several of the requirements, but this one is the only one I spotted that does not have normative text elsewhere. 5. The local/global discussion is confusing, because "global" in this context is not the "global" in a tel uri. As best I can tell, you mean to use "phone context" with some guaranteed globally unique name space, like a domain name. You can't just say "use phone-context" and get global out of that. More text is needed to explain what you are trying to accomplish with global context. 6. Consider changing the language at the end of 4.2 to mirror that in the tel uri. RFC3966 says "If a recipient of the URI intends to place a call to the local number, it MUST understand the context and be able to place calls within that context." It doesn't say you ignore phone context. Actually, it's silent on what you do when you get one that you don't understand. I'm not really thrilled with letting the call go through ignoring the parameter. 7. In the security section, it says if you don't want to reveal trunk group, hide it. This puzzles me. How do you hide a parameter to a tel uri? Did you mean "not use it"? 8. You can now update the reference to 2806bis as RFC3966 (YAY!) 9. Nits Section 3, could use a spacer between the two definitions Also, might want to lose the subgroup exception since you didn't define subgroup Section 4.1 lose the reference to RFC2806 (it gets deleted entirely from the reference section), since 3966 obsoletes it. Section 5 Missing comma: GW3 has only one trunk group configured, TG3-1 ^ The following text is awkward: On requests arriving to the proxy from GW1, the proxy will have access to the trunk group TG1-1 if the request arrived on that particular trunk The proxy always has access to trunk group TG1-1. If a call arrives on that group and the proxy wants to let a downstream entity know that, then it puts the parameter on the Contact header. Section 8 Extra space in security concerns beyond those already enumerated in [3] . ^ Section 11 should be dropped sometime Brian _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Dec 21 10:29:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19721 for ; Tue, 21 Dec 2004 10:29:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgm6r-0006ap-IJ for iptel-web-archive@ietf.org; Tue, 21 Dec 2004 10:39:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cglo5-0006rH-OQ; Tue, 21 Dec 2004 10:20:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cglmk-0006Q7-Py for iptel@megatron.ietf.org; Tue, 21 Dec 2004 10:18:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18280 for ; Tue, 21 Dec 2004 10:18:48 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CglwD-0006KN-V2 for iptel@ietf.org; Tue, 21 Dec 2004 10:28:39 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iBLFIDwe020494; Tue, 21 Dec 2004 09:18:14 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id iBLFIDV05815; Tue, 21 Dec 2004 09:18:13 -0600 (CST) Message-ID: <41C83EB5.2010505@lucent.com> Date: Tue, 21 Dec 2004 09:18:13 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Iptel] Review of draft-ietf-iptel-trunk-group-02 References: <200412210024.TAA28221@ietf.org> In-Reply-To: <200412210024.TAA28221@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Brian Rosen wrote: > I've reviewed this draft for readiness to advance to the IESG. > > I don't find any substantive issues with the draft from a protocol > point of view. Brian: I very much appreciate your time on this. Your review comments will be folded in the next rev. Thank you for a thorough review! Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Dec 23 22:22:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23736 for ; Thu, 23 Dec 2004 22:22:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChgCC-0000Cf-9r for iptel-web-archive@ietf.org; Thu, 23 Dec 2004 22:32:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChfnR-0004Ol-LI; Thu, 23 Dec 2004 22:07:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Chfk6-0003Pv-Is for iptel@megatron.ietf.org; Thu, 23 Dec 2004 22:03:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22353 for ; Thu, 23 Dec 2004 22:03:47 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Chfu6-0008B4-JX for iptel@ietf.org; Thu, 23 Dec 2004 22:14:10 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Dec 2004 20:11:47 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBO33Ho9016568; Thu, 23 Dec 2004 19:03:17 -0800 (PST) Received: from [192.168.1.102] (sjc-vpn1-331.cisco.com [10.21.97.75]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUZ78930; Thu, 23 Dec 2004 19:03:20 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 23 Dec 2004 05:47:15 -0800 Subject: Re: [Iptel] FW: SIP - TEL URI Implementation Query From: Cullen Jennings To: "Gaurav.Kheterpal" , "sip-implementors@cs.columbia.edu" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: "iptel@ietf.org" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit This question would probably be better on sip-implementors so if you reply, please remove iptel. Bit of an answer inline. On 12/14/04 12:11 AM, "Gaurav.Kheterpal" wrote: > Hello, > > I am currently implementing support for URI's in our User Agent as > per RFC 3966/ RFC 2806-bis standards. I had the following doubts regarding > the same. Any inputs will be highly appreciated. > > 1. Contact Header: As per RFC 3261 Section 8.1.1.8, it mentions that this > URI must be in either SIP/ SIPS format. In Section 10.2.1, it is mentioned > that for registrations, the Contact header field can contain any URI Scheme > (e.g the tel URL, RFC 2806 [9]) or email addresses (with a mailto URL, RFC > 2368 [32]) as Contacts for an address-of-record. > > Does this mean that the 'Contact' field in an INVITE message must always be > a SIP/SIPS URI while in a REGISTER message, it can be a SIP/SIPS/TEL/Mailto > URI ? Yes. Pretty weird Eh? The contact header in SIP got overloaded for too many different uses but that is the way it is. Also, a 302 can have a Contact header field value that is any URI (such as tel, email). > > 2. Besides 'Request URI' and 'To:' header fields, can the TEL URI be present > in any other INVITE header values (e.g. Via, Route Header, Contact etc). It can be in a From header and the RFC 3325 P-Asserted-Identity header. It should never be in a Via. > In > other words, which fields in the INVITE request does the proxy scan for > possible tel->sip translation using ENUM/ any other mechanism ? Only the request URI. The others should never be changed by a proxy. > In case, > there is no other field which contains this information, how is the TEL URI > information propagated across intermediate proxies when the UA is configured > with a outbound proxy having a defined route set. If the defined route set > is proxy 1-> proxy 2 in the below diagram, the request will be formed using: > > INVITE sip:proxy1 > Route: > To: > Proxies never route based on the To. Again, weird but true. So to make something like this work the path below happen, you would have. The routes are used before the R-URI. (I'm assuming that proxy 2 will route 1234 to user B) INVITE tel:1234 Route: , > User A Proxy 1 Proxy 2 User B > | | | | > | INVITE F1 | | | > |--------------->| | | > > Does this mean that in such a case, the only parameter which contains the > TEL URI is the 'To' field. No the request URI should have had the tel > As I understand, this field is never processed by > the proxies unless they implement privacy/ RFC 3324(5) ?? Yes - even then the the To field is never changed by a proxy. > > I am current not aware of any proxy which is capable of handling TEL URI's, > any information/ links regarding the same will be highly useful. I think there several proxies that can do tel and ENUM - there are also several GWs capable of tel. > > Thanks in advance for your help. > > regards, > > Gaurav > Hope that helps, Cullen _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Dec 27 11:25:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25658 for ; Mon, 27 Dec 2004 11:25:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CixrB-0006yU-Ue for iptel-web-archive@ietf.org; Mon, 27 Dec 2004 11:36:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CixcI-0003hr-HF; Mon, 27 Dec 2004 11:21:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cixbd-0003YA-Lc for iptel@megatron.ietf.org; Mon, 27 Dec 2004 11:20:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25345 for ; Mon, 27 Dec 2004 11:20:23 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CixmM-0006qh-7b for iptel@ietf.org; Mon, 27 Dec 2004 11:31:31 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iBRGJoKn005471; Mon, 27 Dec 2004 10:19:51 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id iBRGJnY18684; Mon, 27 Dec 2004 10:19:49 -0600 (CST) Message-ID: <41D03626.4010409@lucent.com> Date: Mon, 27 Dec 2004 10:19:50 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF IPTEL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: tu-sawada@kddi.com, Shan Lu Subject: [Iptel] Finalizing trunk-group I-D X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Folks: As part of WGLC, I have received the nits comments from the WG reviewers who kindly volunteered their time in reviewing the trunk-group I-D. I will be issuing an updated rev shortly. There is one pending item that was being discussed on the list; I will like to reach conclusion on this. The issue is summarized in the following email from the WG archives: http://www1.ietf.org/mail-archive/web/iptel/current/msg00726.html In the interest of moving forward and concluding this particular I-D, if I do not hear any counter proposals, I will consider the issue resolved as outlined in the email. Thank you for your patience in indulging this discussion, and happy holidays. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Dec 27 14:24:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12828 for ; Mon, 27 Dec 2004 14:24:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj0eR-00044O-PA for iptel-web-archive@ietf.org; Mon, 27 Dec 2004 14:35:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj0SM-00062n-GH; Mon, 27 Dec 2004 14:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj0RM-0005oD-Ig for iptel@megatron.ietf.org; Mon, 27 Dec 2004 14:22:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12692 for ; Mon, 27 Dec 2004 14:21:59 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj0c7-0003zf-13 for iptel@ietf.org; Mon, 27 Dec 2004 14:33:08 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 27 Dec 2004 11:29:29 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBRJLLdP000223; Mon, 27 Dec 2004 11:21:21 -0800 (PST) Received: from [192.168.1.102] (sjc-vpn4-798.cisco.com [10.21.83.29]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVA51788; Mon, 27 Dec 2004 11:21:24 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 27 Dec 2004 12:21:24 -0700 From: Cullen Jennings To: "iptel@ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Iptel] No meeting at next IETF? X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit I am trying to figure out if we need agenda time at the next IETF. My current assumption is that we do not need agenda time to finish any of our current work so I am not planning on requesting any. If you think there is some draft that we can not finish "on the list" without having agenda time, let me know before the end of January. Thanks, Cullen _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Dec 29 18:14:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29937 for ; Wed, 29 Dec 2004 18:14:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjnCO-0006f4-I4 for iptel-web-archive@ietf.org; Wed, 29 Dec 2004 18:25:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjmf2-00058o-H1; Wed, 29 Dec 2004 17:51:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjmee-0004qm-Vg for iptel@megatron.ietf.org; Wed, 29 Dec 2004 17:50:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27417 for ; Wed, 29 Dec 2004 17:50:54 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cjmpr-00069e-TK for iptel@ietf.org; Wed, 29 Dec 2004 18:02:32 -0500 Received: (qmail 20841 invoked by uid 1014); 29 Dec 2004 22:50:13 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.80. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.042247 secs); 29 Dec 2004 22:50:13 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 29 Dec 2004 22:50:13 -0000 From: "Shan Lu" To: "'Vijay K. Gurbani'" , "'IETF IPTEL WG'" Subject: RE: [Iptel] Finalizing trunk-group I-D Date: Wed, 29 Dec 2004 17:51:36 -0500 Message-ID: <006001c4edf8$f40531f0$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <41D03626.4010409@lucent.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: tu-sawada@kddi.com X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Vijay, I like your proposal in spirit, but am weary of the (over)use of "anonymous". For everybody's benefit, you propose the following format = when calling party number is absent: Contact: = , where the origination TG is "foo". RFC3398 (and 3261) hinted that "sip:anonymous " SIP URI = has privacy implications. To quote RFC3398: "If the presentation indicators are set to 'presentation restricted', then a special URI is created by the gateway which communicates to the far end that the caller's identity has been omitted. This URI SHOULD be a SIP URI with a display-name and username of 'Anonymous', e.g.: From: Anonymous " There are existing implementations where "anonymous" = display-name/userinfo can trigger special processing on both From and Contact headers. OTOH, what we want is to convey to the recipient of Contact header the following: the SIP URI userinfo in Contact is a "quasi-" tel URI in that = any subsequent fields following the first semi-colon must be treated as tel = URI parameters, including ";tgrp=3D".=20 I believe a keyword different than "anonymous" serves this purpose = better. For example, we don't have to consider the subtle difference between "presentation restricted" and "address unavailable". My suggestion is "telurifmt", i.e.: Contact: . Note since this is not tel URI, there should not be requirement on = mandatory "phone-context" parameter. Comments? Regards, Shan Lu >-----Original Message----- >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org]=20 >On Behalf Of Vijay K. Gurbani >Sent: Monday, December 27, 2004 11:20 AM >To: IETF IPTEL WG >Cc: tu-sawada@kddi.com; Shan Lu >Subject: [Iptel] Finalizing trunk-group I-D > > >Folks: > >As part of WGLC, I have received the nits comments from the WG >reviewers who kindly volunteered their time in reviewing >the trunk-group I-D. I will be issuing an updated rev >shortly. > >There is one pending item that was being discussed on the >list; I will like to reach conclusion on this. The issue >is summarized in the following email from the WG archives: > >http://www1.ietf.org/mail-archive/web/iptel/current/msg00726.html > >In the interest of moving forward and concluding this particular >I-D, if I do not hear any counter proposals, I will consider >the issue resolved as outlined in the email. > >Thank you for your patience in indulging this discussion, and >happy holidays. > >Regards, > >- vijay >--=20 >Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >Wireless Networks Group/Internet Software and Services >Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >Naperville, Illinois 60566 Voice: +1 630 224 0216 > >_______________________________________________ >Iptel mailing list >Iptel@ietf.org >https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel