From exim@www1.ietf.org Sun Feb 1 22:03:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29450 for ; Sun, 1 Feb 2004 22:03:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnUMi-0004nU-55 for sipping-archive@odin.ietf.org; Sun, 01 Feb 2004 22:03:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1233CFd018434 for sipping-archive@odin.ietf.org; Sun, 1 Feb 2004 22:03:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnUMi-0004nF-09 for sipping-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 22:03:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29400 for ; Sun, 1 Feb 2004 22:03:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnUMe-0003vA-00 for sipping-web-archive@ietf.org; Sun, 01 Feb 2004 22:03:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnULg-0003pC-00 for sipping-web-archive@ietf.org; Sun, 01 Feb 2004 22:02:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnUKl-0003j3-00 for sipping-web-archive@ietf.org; Sun, 01 Feb 2004 22:01:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnUKd-0004az-Bl; Sun, 01 Feb 2004 22:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnUJs-0004XG-OG for sipping@optimus.ietf.org; Sun, 01 Feb 2004 22:00:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29291 for ; Sun, 1 Feb 2004 22:00:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnUJp-0003cT-00 for sipping@ietf.org; Sun, 01 Feb 2004 22:00:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnUIr-0003XA-00 for sipping@ietf.org; Sun, 01 Feb 2004 21:59:13 -0500 Received: from mail.cedarpointcom.com ([64.80.26.186] helo=exchange.cedarpointcom.com) by ietf-mx with esmtp (Exim 4.12) id 1AnUHu-0003NO-00 for sipping@ietf.org; Sun, 01 Feb 2004 21:58:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 1 Feb 2004 21:57:44 -0500 Message-ID: <66F2ACFAB4E7764EAF85274020DD5342017F9082@exchange.cedarpointcom.com> Thread-Topic: TCAP tunneling Thread-Index: AcPpOFTWm6M1v5dsSUy9+eU1o6SHpA== From: "Kaitki Agarwal" To: Content-Transfer-Encoding: base64 Subject: [Sipping] TCAP tunneling Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkNCiBDYW4gd2UgdHVubmVsIHRjYXAgbWVzc2FnZSBpbiBTSVAgYXMgd2UgZG8gIElTVVAuIElm IG5vdCB3aHkuIA0KIA0KVGhhbmtzDQpLYWl0a2kNCg== _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 1 23:58:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04706 for ; Sun, 1 Feb 2004 23:58:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnWAG-0002ZQ-TH for sipping-archive@odin.ietf.org; Sun, 01 Feb 2004 23:58:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i124wSR2009874 for sipping-archive@odin.ietf.org; Sun, 1 Feb 2004 23:58:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnWAG-0002ZB-P4 for sipping-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 23:58:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04561 for ; Sun, 1 Feb 2004 23:58:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnWAE-0007ac-00 for sipping-web-archive@ietf.org; Sun, 01 Feb 2004 23:58:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnW96-0007LR-00 for sipping-web-archive@ietf.org; Sun, 01 Feb 2004 23:57:16 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AnW8O-0007H9-02 for sipping-web-archive@ietf.org; Sun, 01 Feb 2004 23:56:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AnW56-00037l-Tu for sipping-web-archive@ietf.org; Sun, 01 Feb 2004 23:53:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnW50-0002Jy-1z; Sun, 01 Feb 2004 23:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnW4G-0002IN-2p for sipping@optimus.ietf.org; Sun, 01 Feb 2004 23:52:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04451 for ; Sun, 1 Feb 2004 23:52:13 -0500 (EST) From: ranjit.avasarala@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnW4D-0006xv-00 for sipping@ietf.org; Sun, 01 Feb 2004 23:52:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnW3H-0006tu-00 for sipping@ietf.org; Sun, 01 Feb 2004 23:51:15 -0500 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1AnW2c-0006lT-00 for sipping@ietf.org; Sun, 01 Feb 2004 23:50:36 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i124o2AK012294 for ; Mon, 2 Feb 2004 10:20:02 +0530 (IST) Received: from blr-ec-bh3.wipro.com ([10.200.50.93]) by ec-vwall-wd with InterScan Messaging Security Suite; Mon, 02 Feb 2004 10:21:15 +0530 Received: from blr-ec-msg03.wipro.com ([10.200.52.99]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Feb 2004 10:20:02 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] TCAP tunneling Date: Mon, 2 Feb 2004 10:20:01 +0530 Message-ID: Thread-Topic: [Sipping] TCAP tunneling Thread-Index: AcPpOFTWm6M1v5dsSUy9+eU1o6SHpAAD2jlg To: , X-OriginalArrivalTime: 02 Feb 2004 04:50:02.0262 (UTC) FILETIME=[04B87360:01C3E948] Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi TCAP is used for Transaction Capabilities i.e database related while SIP with ISUP tunneling is used between MGCs. So I don't think TCAP can be tunneled in SIP. Ranjit Ph: 8520408/16 extn: 2173 -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Kaitki Agarwal Sent: Monday, February 02, 2004 8:28 AM To: sipping@ietf.org Subject: [Sipping] TCAP tunneling Hi Can we tunnel tcap message in SIP as we do ISUP. If not why.=20 =20 Thanks Kaitki Jj~Yzy=3Di~Rz}y _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 2 00:29:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05853 for ; Mon, 2 Feb 2004 00:29:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnWe4-00053u-Ek for sipping-archive@odin.ietf.org; Mon, 02 Feb 2004 00:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i125TGDS019452 for sipping-archive@odin.ietf.org; Mon, 2 Feb 2004 00:29:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnWe4-00053f-BU for sipping-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 00:29:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05848 for ; Mon, 2 Feb 2004 00:29:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnWe1-0002Tg-00 for sipping-web-archive@ietf.org; Mon, 02 Feb 2004 00:29:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnWd6-0002P1-00 for sipping-web-archive@ietf.org; Mon, 02 Feb 2004 00:28:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnWcu-0002Kx-00 for sipping-web-archive@ietf.org; Mon, 02 Feb 2004 00:28:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnWcr-0004sp-UA; Mon, 02 Feb 2004 00:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnWc8-0004qB-5l for sipping@optimus.ietf.org; Mon, 02 Feb 2004 00:27:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05837 for ; Mon, 2 Feb 2004 00:27:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnWc5-0002KD-00 for sipping@ietf.org; Mon, 02 Feb 2004 00:27:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnWb8-0002GR-00 for sipping@ietf.org; Mon, 02 Feb 2004 00:26:14 -0500 Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx with esmtp (Exim 4.12) id 1AnWb2-0002Cj-00 for sipping@ietf.org; Mon, 02 Feb 2004 00:26:08 -0500 Received: from harvest.india.hp.com (harvest.india.hp.com [15.76.216.203]) by palrel11.hp.com (Postfix) with ESMTP id 061A61C006C3; Sun, 1 Feb 2004 21:26:08 -0800 (PST) Received: from nt13192 (nt13192.india.hp.com [15.76.113.192]) by harvest.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id KAA08506; Mon, 2 Feb 2004 10:57:27 +0530 (IST) From: "Banibrata Dutta" To: , , Subject: RE: [Sipping] TCAP tunneling Date: Mon, 2 Feb 2004 10:55:31 +0530 Message-ID: <018901c3e94c$fa675c50$c0714c0f@nt13192> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi, franly, i'd say that, it depends on your motivation/reason to use SIP for tunneling TCAP. of course you can tunnel TCAP, but why you'd want to, is a justification you'd have to work out. AFAIK, there's not ietf-draft that says, how. you can obviously tunnel TCAP query in an INVITE or INFO for that matter (ideally in INVITE s.t. a SIP-dialog is also created which may be used to model the TCAP dialog as well, perhaps!). the ASN.1 BER encoded TCAP messages may then reside within the body of a multi-part (MIME) enc, INVITE. infact 1 reason i see where this may make sense is that you would rather not have two stacks s.a. SIGTRAN and SIP for signalling transport, and use SIP as the *only* signalling solution, i.e. for the signalling application as well as for signalling transport, and support legacy/TCAP apps by tunneling them within SIP. but then, you generally have the constraints of not-enough- space, (for 2 stacks) only on resource-limited devices, s.a. hand-sets, embedded devices etc., but i am unable see (yet), how TCAP can be related to such devices. my 2 cents, Banibrata Dutta, Hewlett-Packard ISO (P) Ltd, 29, Cunningham Road, Bangalore - 560052 Ph: +91-80-22051796 > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of ranjit.avasarala@wipro.com > Sent: Monday, February 02, 2004 10:20 AM > To: kagarwal@cedarpointcom.com; sipping@ietf.org > Subject: RE: [Sipping] TCAP tunneling > > > Hi > TCAP is used for Transaction Capabilities i.e database > related while SIP with ISUP tunneling is used between MGCs. > So I don't think TCAP can be tunneled in SIP. > > Ranjit > Ph: 8520408/16 extn: 2173 > > > > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Kaitki Agarwal > Sent: Monday, February 02, 2004 8:28 AM > To: sipping@ietf.org > Subject: [Sipping] TCAP tunneling > > > Hi > Can we tunnel tcap message in SIP as we do ISUP. If not why. > > Thanks > Kaitki > Jj~Yzy=i~Rz}y > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 2 09:30:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14829 for ; Mon, 2 Feb 2004 09:30:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anf54-0005wH-1f for sipping-archive@odin.ietf.org; Mon, 02 Feb 2004 09:29:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12ETgVX022825 for sipping-archive@odin.ietf.org; Mon, 2 Feb 2004 09:29:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anf53-0005w4-Tp for sipping-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 09:29:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14826 for ; Mon, 2 Feb 2004 09:29:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anf52-0006WX-00 for sipping-web-archive@ietf.org; Mon, 02 Feb 2004 09:29:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anf42-0006Rb-00 for sipping-web-archive@ietf.org; Mon, 02 Feb 2004 09:28:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Anf3c-0006MI-00 for sipping-web-archive@ietf.org; Mon, 02 Feb 2004 09:28:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anf3S-0005Yp-3N; Mon, 02 Feb 2004 09:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anf31-0005WK-OP for sipping@optimus.ietf.org; Mon, 02 Feb 2004 09:27:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14734 for ; Mon, 2 Feb 2004 09:27:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anf30-0006LH-00 for sipping@ietf.org; Mon, 02 Feb 2004 09:27:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anf25-0006GE-00 for sipping@ietf.org; Mon, 02 Feb 2004 09:26:37 -0500 Received: from [208.236.67.14] (helo=gateway.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1Anf1J-0006Bq-00; Mon, 02 Feb 2004 09:25:49 -0500 Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by gateway.hns.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i12EPcac006579 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 Feb 2004 09:25:40 -0500 (EST) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id i12EPUVY021225; Mon, 2 Feb 2004 09:25:30 -0500 (EST) To: "Banibrata Dutta" Cc: kagarwal@cedarpointcom.com, ranjit.avasarala@wipro.com, sipping@ietf.org, sipping-admin@ietf.org Subject: RE: [Sipping] TCAP tunneling MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Arjun Roychowdhury Date: Mon, 2 Feb 2004 09:25:27 -0500 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 02/02/2004 09:23:32 AM, Serialize complete at 02/02/2004 09:23:32 AM Content-Type: text/plain; charset="us-ascii" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Actually, there _is_ an independant draft on how to carry TCAP in SIP. http://www.ietf.org/internet-drafts/draft-miller-sip-tcap-00.txt Its another matter whether this is the right thing to do or not (please refer to old archives for the debates). Kaitaki, you may want to read the above draft as well as the discussions on it to conclude for yourself which is the preferred method in your deployment scenario. regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 VOIP: (SIP) 10303@fwd.pulver.com (PSTN alias:360-207-0467) "Banibrata Dutta" Sent by: sipping-admin@ietf.org 02/02/2004 12:25 AM To: , , cc: Subject: RE: [Sipping] TCAP tunneling hi, franly, i'd say that, it depends on your motivation/reason to use SIP for tunneling TCAP. of course you can tunnel TCAP, but why you'd want to, is a justification you'd have to work out. AFAIK, there's not ietf-draft that says, how. you can obviously tunnel TCAP query in an INVITE or INFO for that matter (ideally in INVITE s.t. a SIP-dialog is also created which may be used to model the TCAP dialog as well, perhaps!). the ASN.1 BER encoded TCAP messages may then reside within the body of a multi-part (MIME) enc, INVITE. infact 1 reason i see where this may make sense is that you would rather not have two stacks s.a. SIGTRAN and SIP for signalling transport, and use SIP as the *only* signalling solution, i.e. for the signalling application as well as for signalling transport, and support legacy/TCAP apps by tunneling them within SIP. but then, you generally have the constraints of not-enough- space, (for 2 stacks) only on resource-limited devices, s.a. hand-sets, embedded devices etc., but i am unable see (yet), how TCAP can be related to such devices. my 2 cents, Banibrata Dutta, Hewlett-Packard ISO (P) Ltd, 29, Cunningham Road, Bangalore - 560052 Ph: +91-80-22051796 > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of ranjit.avasarala@wipro.com > Sent: Monday, February 02, 2004 10:20 AM > To: kagarwal@cedarpointcom.com; sipping@ietf.org > Subject: RE: [Sipping] TCAP tunneling > > > Hi > TCAP is used for Transaction Capabilities i.e database > related while SIP with ISUP tunneling is used between MGCs. > So I don't think TCAP can be tunneled in SIP. > > Ranjit > Ph: 8520408/16 extn: 2173 > > > > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Kaitki Agarwal > Sent: Monday, February 02, 2004 8:28 AM > To: sipping@ietf.org > Subject: [Sipping] TCAP tunneling > > > Hi > Can we tunnel tcap message in SIP as we do ISUP. If not why. > > Thanks > Kaitki > Jj~Yzy=i~Rz}y > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 2 11:04:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20044 for ; Mon, 2 Feb 2004 11:04:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AngY7-0003A0-63 for sipping-archive@odin.ietf.org; Mon, 02 Feb 2004 11:03:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12G3ldS012144 for sipping-archive@odin.ietf.org; Mon, 2 Feb 2004 11:03:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AngY7-00039m-1B for sipping-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 11:03:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20014 for ; Mon, 2 Feb 2004 11:03:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AngY4-00016q-00 for sipping-web-archive@ietf.org; Mon, 02 Feb 2004 11:03:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AngXI-0000xl-00 for sipping-web-archive@ietf.org; Mon, 02 Feb 2004 11:02:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AngWU-0000p1-00 for sipping-web-archive@ietf.org; Mon, 02 Feb 2004 11:02:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AngWQ-0002rA-HC; Mon, 02 Feb 2004 11:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AngWJ-0002qp-Sy for sipping@optimus.ietf.org; Mon, 02 Feb 2004 11:01:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19870 for ; Mon, 2 Feb 2004 11:01:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AngWF-0000nO-00 for sipping@ietf.org; Mon, 02 Feb 2004 11:01:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AngVA-0000ga-00 for sipping@ietf.org; Mon, 02 Feb 2004 11:00:45 -0500 Received: from mail.cedarpointcom.com ([64.80.26.186] helo=exchange.cedarpointcom.com) by ietf-mx with esmtp (Exim 4.12) id 1AngUe-0000Zy-00 for sipping@ietf.org; Mon, 02 Feb 2004 11:00:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] TCAP tunneling Date: Mon, 2 Feb 2004 10:59:41 -0500 Message-ID: <66F2ACFAB4E7764EAF85274020DD5342017F9084@exchange.cedarpointcom.com> Thread-Topic: [Sipping] TCAP tunneling Thread-Index: AcPpTRE2xG/QMx8BSZuBHZoLYjWmUQATgFxw From: "Kaitki Agarwal" To: "Banibrata Dutta" , , Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Typically we use ISUP tunneling in SIP when the end exchange is talking to another switch who is terminating traditional SS7 links to save cost on SS7 links. The end exchange is the one who has all the subscriber profiles and knows if it needs CNAM or LNP or AC/AR. If we have a way to tunnel TCAP in SIP using INVITE (as suggested below) we can access all these services from the end exchange.=20 TUA is not yet RFC so I would prefer not to use it. With SUA you still need TCAP ASN.1 BER encoded message. Instead of building Sigtran I can use SIP if it has a TCAP extension. It is not just space constraint , it is cost of writing/buying SIGTRAN stack and building then supporting it in to the system.=20 Thanks Kaitki =20 -----Original Message----- From: Banibrata Dutta [mailto:dutta@india.hp.com]=20 Sent: Monday, February 02, 2004 12:26 AM To: ranjit.avasarala@wipro.com; Kaitki Agarwal; sipping@ietf.org Subject: RE: [Sipping] TCAP tunneling hi, franly, i'd say that, it depends on your motivation/reason to use SIP for=20 tunneling TCAP. of course you can tunnel TCAP, but why you'd want to, is a justification you'd have to work out. AFAIK, there's not ietf-draft that says, how. you can obviously tunnel TCAP query in an INVITE or INFO for that matter (ideally in INVITE s.t. a SIP-dialog is also created which may be used to model the TCAP dialog as well, perhaps!). the ASN.1 BER encoded TCAP messages may then reside within the body of a multi-part (MIME) enc, INVITE. infact 1 reason i see where this may make sense is that you would rather not have two stacks s.a. SIGTRAN and SIP for signalling transport, and use SIP as the *only* signalling solution, i.e. for the signalling application as well as for signalling transport, and support legacy/TCAP apps by tunneling them within SIP. but then, you generally have the constraints of not-enough- space, (for 2 stacks) only on resource-limited devices, s.a. hand-sets, embedded devices etc., but i am unable see (yet), how TCAP can be related to such devices. my 2 cents, Banibrata Dutta, Hewlett-Packard ISO (P) Ltd, 29, Cunningham Road, Bangalore - 560052 Ph: +91-80-22051796 > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of ranjit.avasarala@wipro.com > Sent: Monday, February 02, 2004 10:20 AM > To: kagarwal@cedarpointcom.com; sipping@ietf.org > Subject: RE: [Sipping] TCAP tunneling >=20 >=20 > Hi > TCAP is used for Transaction Capabilities i.e database > related while SIP with ISUP tunneling is used between MGCs.=20 > So I don't think TCAP can be tunneled in SIP. >=20 > Ranjit > Ph: 8520408/16 extn: 2173 >=20 >=20 >=20 >=20 > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Kaitki Agarwal > Sent: Monday, February 02, 2004 8:28 AM > To: sipping@ietf.org > Subject: [Sipping] TCAP tunneling >=20 >=20 > Hi > Can we tunnel tcap message in SIP as we do ISUP. If not why. > =20 > Thanks > Kaitki > Jj~Yzy=3Di~Rz}y >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 2 14:03:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02784 for ; Mon, 2 Feb 2004 14:03:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjLO-0005Fw-6B for sipping-archive@odin.ietf.org; Mon, 02 Feb 2004 14:02:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12J2oct020198 for sipping-archive@odin.ietf.org; Mon, 2 Feb 2004 14:02:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjLO-0005Fh-0b for sipping-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 14:02:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02719 for ; Mon, 2 Feb 2004 14:02:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjLL-0005BA-00 for sipping-web-archive@ietf.org; Mon, 02 Feb 2004 14:02:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjK4-0004w7-00 for sipping-web-archive@ietf.org; Mon, 02 Feb 2004 14:01:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnjIp-0004eu-00 for sipping-web-archive@ietf.org; Mon, 02 Feb 2004 14:00:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjIi-0004tw-TR; Mon, 02 Feb 2004 14:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjIB-0004rz-8H for sipping@optimus.ietf.org; Mon, 02 Feb 2004 13:59:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02129 for ; Mon, 2 Feb 2004 13:59:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjI8-0004TG-00 for sipping@ietf.org; Mon, 02 Feb 2004 13:59:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjG0-0003u8-00 for sipping@ietf.org; Mon, 02 Feb 2004 13:57:19 -0500 Received: from qfe5.f4cc49-01.broomfield1.level3.net ([209.245.18.95] helo=f4cc49-01.idc1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 1AnjD3-00037A-00 for sipping@ietf.org; Mon, 02 Feb 2004 13:54:13 -0500 Received: from scanner1.level3.com (qfe0.f4gg49-02.idc1.oss.level3.com [10.1.156.106]) by f4cc49-01.idc1.level3.com (8.12.10/8.12.10) with ESMTP id i12Is8w5026491; Mon, 2 Feb 2004 18:54:08 GMT Received: from scanner1.level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 22DF178AC81; Mon, 2 Feb 2004 18:54:08 +0000 (GMT) Received: from ldc1exc0001.corp.global.level3.com (ldc1exc0001.corp.global.level3.com [10.15.72.156]) by scanner1.level3.com (Postfix) with ESMTP id 77BC778AC83; Mon, 2 Feb 2004 18:54:07 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com ([10.1.7.194]) by ldc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 2 Feb 2004 18:54:06 +0000 Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 2 Feb 2004 11:54:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] TCAP tunneling Date: Mon, 2 Feb 2004 11:54:02 -0700 Message-ID: <3F75233A2E57CC468B35F3B1FAF71EC012909B@idc1exc0004.corp.global.level3.com> Thread-Topic: [Sipping] TCAP tunneling Thread-Index: AcPpmOUCKcpXLoM/ScqLVL43upxGFAAJJoXQ From: "Hearty, John" To: Cc: "Peterson, Jon" X-OriginalArrivalTime: 02 Feb 2004 18:54:02.0617 (UTC) FILETIME=[ECB96690:01C3E9BD] Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Other than the miller draft below, is there any SIP standard proposed to carry cnam queries? John Hearty Level3 > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of > Arjun Roychowdhury > Sent: Monday, February 02, 2004 7:25 AM > To: Banibrata Dutta > Cc: kagarwal@cedarpointcom.com; ranjit.avasarala@wipro.com; > sipping@ietf.org; sipping-admin@ietf.org > Subject: RE: [Sipping] TCAP tunneling >=20 > Actually, there _is_ an independant draft on how to carry TCAP in SIP. > http://www.ietf.org/internet-drafts/draft-miller-sip-tcap-00.txt >=20 > Its another matter whether this is the right thing to do or not (please > refer to old archives for the debates). > Kaitaki, you may want to read the above draft as well as the discussions > on it to conclude for yourself which is the preferred method in your > deployment scenario. >=20 > regds > arjun >=20 >=20 > -- > Arjun Roychowdhury @ Hughes Software Systems > 11717 Exploration Lane, Germantown MD 20876 > (O): 301 212 7860 > VOIP: (SIP) 10303@fwd.pulver.com (PSTN alias:360-207-0467) >=20 >=20 >=20 >=20 > "Banibrata Dutta" > Sent by: sipping-admin@ietf.org > 02/02/2004 12:25 AM >=20 >=20 > To: , , > > cc: > Subject: RE: [Sipping] TCAP tunneling >=20 >=20 > hi, >=20 > franly, i'd say that, it depends on your motivation/reason to use SIP > for > tunneling TCAP. of course you can tunnel TCAP, but why you'd want to, is > a justification you'd have to work out. AFAIK, there's not ietf-draft > that > says, how. >=20 > you can obviously tunnel TCAP query in an INVITE or INFO for that matter >=20 > (ideally in INVITE s.t. a SIP-dialog is also created which may be used > to > model the TCAP dialog as well, perhaps!). the ASN.1 BER encoded TCAP > messages may then reside within the body of a multi-part (MIME) enc, > INVITE. >=20 > infact 1 reason i see where this may make sense is that you would rather > not have two stacks s.a. SIGTRAN and SIP for signalling transport, and > use > SIP as the *only* signalling solution, i.e. for the signalling > application > as well as for signalling transport, and support legacy/TCAP apps by > tunneling > them within SIP. but then, you generally have the constraints of > not-enough- > space, (for 2 stacks) only on resource-limited devices, s.a. hand-sets, > embedded devices etc., but i am unable see (yet), how TCAP can be > related to > such devices. >=20 > my 2 cents, > Banibrata Dutta, > Hewlett-Packard ISO (P) Ltd, > 29, Cunningham Road, > Bangalore - 560052 > Ph: +91-80-22051796 >=20 > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of ranjit.avasarala@wipro.com > > Sent: Monday, February 02, 2004 10:20 AM > > To: kagarwal@cedarpointcom.com; sipping@ietf.org > > Subject: RE: [Sipping] TCAP tunneling > > > > > > Hi > > TCAP is used for Transaction Capabilities i.e database > > related while SIP with ISUP tunneling is used between MGCs. > > So I don't think TCAP can be tunneled in SIP. > > > > Ranjit > > Ph: 8520408/16 extn: 2173 > > > > > > > > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of Kaitki Agarwal > > Sent: Monday, February 02, 2004 8:28 AM > > To: sipping@ietf.org > > Subject: [Sipping] TCAP tunneling > > > > > > Hi > > Can we tunnel tcap message in SIP as we do ISUP. If not why. > > > > Thanks > > Kaitki > > Jj~Yzy=3Di~Rz}y > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current > > sip Use sip@ietf.org for new developments of core SIP > > >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 >=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 3 00:10:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06847 for ; Tue, 3 Feb 2004 00:10:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnspD-0003EB-Lf for sipping-archive@odin.ietf.org; Tue, 03 Feb 2004 00:10:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i135AFFh012407 for sipping-archive@odin.ietf.org; Tue, 3 Feb 2004 00:10:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnspD-0003E2-BZ for sipping-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 00:10:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06818 for ; Tue, 3 Feb 2004 00:10:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnspA-0003bd-00 for sipping-web-archive@ietf.org; Tue, 03 Feb 2004 00:10:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anso8-0003Uj-00 for sipping-web-archive@ietf.org; Tue, 03 Feb 2004 00:09:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnsnH-0003P2-00 for sipping-web-archive@ietf.org; Tue, 03 Feb 2004 00:08:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ansn3-0002uX-Ow; Tue, 03 Feb 2004 00:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnsmC-0002e1-G7 for sipping@optimus.ietf.org; Tue, 03 Feb 2004 00:07:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06790 for ; Tue, 3 Feb 2004 00:07:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnsmA-0003J5-00 for sipping@ietf.org; Tue, 03 Feb 2004 00:07:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnslC-0003ER-00 for sipping@ietf.org; Tue, 03 Feb 2004 00:06:07 -0500 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx with esmtp (Exim 4.12) id 1Ansl5-00039g-00 for sipping@ietf.org; Tue, 03 Feb 2004 00:05:59 -0500 Received: from harvest.india.hp.com (harvest.india.hp.com [15.76.216.203]) by palrel10.hp.com (Postfix) with ESMTP id 833021C01F44; Mon, 2 Feb 2004 21:05:57 -0800 (PST) Received: from nt13192 (nt13192.india.hp.com [15.76.113.192]) by harvest.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id KAA21723; Tue, 3 Feb 2004 10:37:18 +0530 (IST) From: "Banibrata Dutta" To: "'Kaitki Agarwal'" , , Subject: RE: [Sipping] TCAP tunneling Date: Tue, 3 Feb 2004 10:35:19 +0530 Message-ID: <01a201c3ea13$522831f0$c0714c0f@nt13192> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <66F2ACFAB4E7764EAF85274020DD5342017F9084@exchange.cedarpointcom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Kaitki, I see your point. Well, the idea of using standards for such things is: a) it's a standard, so every node you talk to speaks the same lingo, and there are no major interworking issues with n/w elements from other vendors. b) you don't have to re-invent the wheel, i.e. you get a logic, that is well understood, mature, robust and stable (i.e. all the goodies). c) you can probably buy it off the shelf (so a cost is attached). The pitfalls of not using a standard, i.e. using a draft, that *may* not become a standard are just the opposites of a),b) and to some extent c). I think the bigger danger is (b) i.e. you re-invent the wheel and there are chances that it doesn't go thru a strong and prolonged community review, and you *may* leave few holes which you keep patching for the rest of the life of such a product. coming back to the point of using SIP, well, i've already said, you definitely can use it. and i didn't realize that your intention was to save on the ASN.1 encoding/decoding (that you have to do in SUA), but then ASN.1 gives you the power (and at time compactness of "binary encoding") of representation that is again standard and hence you get a),b) & c), which you lose if you use something like a customized-XML message-set etc. for your purpose SIGTRAN (w/SUA) + regular TCAP layer is the way to go. or even more widely deployed and used - SIGTRAN (w/M3UA) + regular TCAP/SCCP. although less popular (i think than SIGTRAN), you may like to evaluate TALI (the RFC version). my 2 cents, regards, Banibrata. > -----Original Message----- > From: Kaitki Agarwal [mailto:kagarwal@cedarpointcom.com] > Sent: Monday, February 02, 2004 9:30 PM > To: Banibrata Dutta; ranjit.avasarala@wipro.com; sipping@ietf.org > Subject: RE: [Sipping] TCAP tunneling > > > Typically we use ISUP tunneling in SIP when the end exchange > is talking to another switch who is terminating traditional > SS7 links to save cost on SS7 links. The end exchange is the > one who has all the subscriber profiles and knows if it needs > CNAM or LNP or AC/AR. If we have a way to tunnel TCAP in SIP > using INVITE (as suggested below) we can access all these > services from the end exchange. > TUA is not yet RFC so I would prefer not to use it. With SUA > you still need TCAP ASN.1 BER encoded message. Instead of > building Sigtran I can use SIP if it has a TCAP extension. It > is not just space constraint , it is cost of writing/buying > SIGTRAN stack and building then supporting it in to the system. > > Thanks > Kaitki > > -----Original Message----- > From: Banibrata Dutta [mailto:dutta@india.hp.com] > Sent: Monday, February 02, 2004 12:26 AM > To: ranjit.avasarala@wipro.com; Kaitki Agarwal; sipping@ietf.org > Subject: RE: [Sipping] TCAP tunneling > > > hi, > > franly, i'd say that, it depends on your motivation/reason to > use SIP for > tunneling TCAP. of course you can tunnel TCAP, but why you'd > want to, is a justification you'd have to work out. AFAIK, > there's not ietf-draft that says, how. > > you can obviously tunnel TCAP query in an INVITE or INFO for > that matter > > (ideally in INVITE s.t. a SIP-dialog is also created which > may be used to model the TCAP dialog as well, perhaps!). the > ASN.1 BER encoded TCAP messages may then reside within the > body of a multi-part (MIME) enc, INVITE. > > infact 1 reason i see where this may make sense is that you > would rather not have two stacks s.a. SIGTRAN and SIP for > signalling transport, and use SIP as the *only* signalling > solution, i.e. for the signalling application as well as for > signalling transport, and support legacy/TCAP apps by > tunneling them within SIP. but then, you generally have the > constraints of > not-enough- > space, (for 2 stacks) only on resource-limited devices, s.a. > hand-sets, embedded devices etc., but i am unable see (yet), > how TCAP can be related to such devices. > > my 2 cents, > Banibrata Dutta, > Hewlett-Packard ISO (P) Ltd, > 29, Cunningham Road, > Bangalore - 560052 > Ph: +91-80-22051796 > > > -----Original Message----- > > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org] On Behalf > > Of > ranjit.avasarala@wipro.com > > Sent: Monday, February 02, 2004 10:20 AM > > To: kagarwal@cedarpointcom.com; sipping@ietf.org > > Subject: RE: [Sipping] TCAP tunneling > > > > > > Hi > > TCAP is used for Transaction Capabilities i.e database related > > while SIP with ISUP tunneling is used between MGCs. So I > don't think > > TCAP can be tunneled in SIP. > > > > Ranjit > > Ph: 8520408/16 extn: 2173 > > > > > > > > > > -----Original Message----- > > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org] On Behalf > > Of Kaitki > Agarwal > > Sent: Monday, February 02, 2004 8:28 AM > > To: sipping@ietf.org > > Subject: [Sipping] TCAP tunneling > > > > > > Hi > > Can we tunnel tcap message in SIP as we do ISUP. If not why. > > > > Thanks > > Kaitki > > Jj~Yzy=i~Rz}y > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sip@ietf.org for new developments of core SIP > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 3 01:41:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11144 for ; Tue, 3 Feb 2004 01:41:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnuFC-0004vy-38 for sipping-archive@odin.ietf.org; Tue, 03 Feb 2004 01:41:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i136fAbG018960 for sipping-archive@odin.ietf.org; Tue, 3 Feb 2004 01:41:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnuFB-0004vj-SV for sipping-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 01:41:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11048 for ; Tue, 3 Feb 2004 01:41:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnuF8-0005pR-00 for sipping-web-archive@ietf.org; Tue, 03 Feb 2004 01:41:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnuEA-0005en-00 for sipping-web-archive@ietf.org; Tue, 03 Feb 2004 01:40:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AnuD9-0005Ub-04 for sipping-web-archive@ietf.org; Tue, 03 Feb 2004 01:39:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Anu7Q-00008K-Sj for sipping-web-archive@ietf.org; Tue, 03 Feb 2004 01:33:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anu7J-00042c-L1; Tue, 03 Feb 2004 01:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anu6S-00041B-Dd for sipping@optimus.ietf.org; Tue, 03 Feb 2004 01:32:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10925 for ; Tue, 3 Feb 2004 01:32:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anu6P-00051W-00 for sipping@ietf.org; Tue, 03 Feb 2004 01:32:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anu5Q-0004w1-00 for sipping@ietf.org; Tue, 03 Feb 2004 01:31:05 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Anu4S-0004ng-00 for sipping@ietf.org; Tue, 03 Feb 2004 01:30:04 -0500 Received: from dynamicsoft.com ([63.113.46.124]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i136Ta9W014317; Tue, 3 Feb 2004 01:29:37 -0500 (EST) Message-ID: <401F3FC6.4090001@dynamicsoft.com> Date: Tue, 03 Feb 2004 01:29:26 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hearty, John" CC: sipping@ietf.org, "Peterson, Jon" Subject: Re: [Sipping] TCAP tunneling References: <3F75233A2E57CC468B35F3B1FAF71EC012909B@idc1exc0004.corp.global.level3.com> In-Reply-To: <3F75233A2E57CC468B35F3B1FAF71EC012909B@idc1exc0004.corp.global.level3.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit SIP isnt a database query protocol, and cnam is just a DB query service. As such, I would think that enum would be an appropriate technique for this. Any other DB query mechanism will do as well. Another idea would be to use a redirect service, similar to what has been proposed in the past for LNP: http://www.watersprings.org/pub/id/draft-yu-sip-np-02.txt except that a request for a number would be redirected to a Contact which contains that number plus the display name, representing the calling name. -Jonathan R. Hearty, John wrote: > Other than the miller draft below, is there any SIP standard proposed to > carry cnam queries? > > John Hearty > Level3 > > >>-----Original Message----- >>From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf > > Of > >>Arjun Roychowdhury >>Sent: Monday, February 02, 2004 7:25 AM >>To: Banibrata Dutta >>Cc: kagarwal@cedarpointcom.com; ranjit.avasarala@wipro.com; >>sipping@ietf.org; sipping-admin@ietf.org >>Subject: RE: [Sipping] TCAP tunneling >> >>Actually, there _is_ an independant draft on how to carry TCAP in SIP. >>http://www.ietf.org/internet-drafts/draft-miller-sip-tcap-00.txt >> >>Its another matter whether this is the right thing to do or not > > (please > >>refer to old archives for the debates). >>Kaitaki, you may want to read the above draft as well as the > > discussions > >>on it to conclude for yourself which is the preferred method in your >>deployment scenario. >> >>regds >>arjun >> >> >>-- >>Arjun Roychowdhury @ Hughes Software Systems >>11717 Exploration Lane, Germantown MD 20876 >>(O): 301 212 7860 >>VOIP: (SIP) 10303@fwd.pulver.com (PSTN alias:360-207-0467) >> >> >> >> >>"Banibrata Dutta" >>Sent by: sipping-admin@ietf.org >>02/02/2004 12:25 AM >> >> >> To: , > > , > >> >> cc: >> Subject: RE: [Sipping] TCAP tunneling >> >> >>hi, >> >>franly, i'd say that, it depends on your motivation/reason to use SIP >>for >>tunneling TCAP. of course you can tunnel TCAP, but why you'd want to, > > is > >>a justification you'd have to work out. AFAIK, there's not ietf-draft >>that >>says, how. >> >>you can obviously tunnel TCAP query in an INVITE or INFO for that > > matter > >>(ideally in INVITE s.t. a SIP-dialog is also created which may be used >>to >>model the TCAP dialog as well, perhaps!). the ASN.1 BER encoded TCAP >>messages may then reside within the body of a multi-part (MIME) enc, >>INVITE. >> >>infact 1 reason i see where this may make sense is that you would > > rather > >>not have two stacks s.a. SIGTRAN and SIP for signalling transport, and >>use >>SIP as the *only* signalling solution, i.e. for the signalling >>application >>as well as for signalling transport, and support legacy/TCAP apps by >>tunneling >>them within SIP. but then, you generally have the constraints of >>not-enough- >>space, (for 2 stacks) only on resource-limited devices, s.a. > > hand-sets, > >>embedded devices etc., but i am unable see (yet), how TCAP can be >>related to >>such devices. >> >>my 2 cents, >>Banibrata Dutta, >> Hewlett-Packard ISO (P) Ltd, >> 29, Cunningham Road, >> Bangalore - 560052 >> Ph: +91-80-22051796 >> >> >>>-----Original Message----- >>>From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] >>>On Behalf Of ranjit.avasarala@wipro.com >>>Sent: Monday, February 02, 2004 10:20 AM >>>To: kagarwal@cedarpointcom.com; sipping@ietf.org >>>Subject: RE: [Sipping] TCAP tunneling >>> >>> >>>Hi >>> TCAP is used for Transaction Capabilities i.e database >>>related while SIP with ISUP tunneling is used between MGCs. >>>So I don't think TCAP can be tunneled in SIP. >>> >>>Ranjit >>>Ph: 8520408/16 extn: 2173 >>> >>> >>> >>> >>>-----Original Message----- >>>From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] >>>On Behalf Of Kaitki Agarwal >>>Sent: Monday, February 02, 2004 8:28 AM >>>To: sipping@ietf.org >>>Subject: [Sipping] TCAP tunneling >>> >>> >>>Hi >>> Can we tunnel tcap message in SIP as we do ISUP. If not why. >>> >>>Thanks >>>Kaitki >>>Jj~Yzy=i~Rz}y >>> >>>_______________________________________________ >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the application of SIP >>>Use sip-implementors@cs.columbia.edu for questions on current >>>sip Use sip@ietf.org for new developments of core SIP >>> >> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP >> >> >> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 3 06:41:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05048 for ; Tue, 3 Feb 2004 06:41:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anyuw-0004ds-Pe for sipping-archive@odin.ietf.org; Tue, 03 Feb 2004 06:40:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13BeYRg017840 for sipping-archive@odin.ietf.org; Tue, 3 Feb 2004 06:40:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anyuw-0004df-Lp for sipping-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 06:40:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05036 for ; Tue, 3 Feb 2004 06:40:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anyus-0005ak-00 for sipping-web-archive@ietf.org; Tue, 03 Feb 2004 06:40:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anytz-0005TZ-00 for sipping-web-archive@ietf.org; Tue, 03 Feb 2004 06:39:35 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AnytQ-0005M2-00 for sipping-web-archive@ietf.org; Tue, 03 Feb 2004 06:39:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AnytT-0001dx-0n for sipping-web-archive@ietf.org; Tue, 03 Feb 2004 06:39:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnytR-0004PH-1M; Tue, 03 Feb 2004 06:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anyso-0004FW-8z for sipping@optimus.ietf.org; Tue, 03 Feb 2004 06:38:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04884 for ; Tue, 3 Feb 2004 06:38:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anysk-0005G0-00 for sipping@ietf.org; Tue, 03 Feb 2004 06:38:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anyrq-00056I-00 for sipping@ietf.org; Tue, 03 Feb 2004 06:37:22 -0500 Received: from law9-f36.law9.hotmail.com ([64.4.9.36] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1Anyr4-0004q9-00 for sipping@ietf.org; Tue, 03 Feb 2004 06:36:35 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Feb 2004 03:36:05 -0800 Received: from 202.88.208.67 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 03 Feb 2004 11:36:05 GMT X-Originating-IP: [202.88.208.67] X-Originating-Email: [aartii@hotmail.com] X-Sender: aartii@hotmail.com From: "Aarti Iyengar" To: sipping@ietf.org Date: Tue, 03 Feb 2004 11:36:05 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Feb 2004 11:36:05.0576 (UTC) FILETIME=[E8CCE480:01C3EA49] Subject: [Sipping] SIP-T and BICC Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 All, I am trying to understand SIP-T and BICC in detail. From my initial reading, both are essentially to seamlessly interface the PSTN to broadband networks. SIP-T is specifically for SIP based IP networks, whereas BICC is bearer independent and can interface with IP/ATM networks well. Apart from that, SIP-T deals with ISUP translation and encapsulation while BICC deals with extensions with ISUP for additional bearer support. BICC CS3 will also enable SIP services to co-exist with BICC based networks. My questions are - Are these the only key differences between these protocols which essentially are intended perform the same function? If there are others, what are they? Are there certain situations where one would fit in better than the other, and if so what are these? How well would these interoperate with each other if they have to co-exist? Also, any pointers to urls/whitepapers on the above (BICC versus SIP-T) would be appreciated. thanks Aarti _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 3 08:22:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07822 for ; Tue, 3 Feb 2004 08:22:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao0VZ-00036I-Lg for sipping-archive@odin.ietf.org; Tue, 03 Feb 2004 08:22:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13DMTtV011912 for sipping-archive@odin.ietf.org; Tue, 3 Feb 2004 08:22:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao0VZ-000363-Fh for sipping-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 08:22:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07816 for ; Tue, 3 Feb 2004 08:22:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao0VY-00003n-00 for sipping-web-archive@ietf.org; Tue, 03 Feb 2004 08:22:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao0Ui-0007lT-00 for sipping-web-archive@ietf.org; Tue, 03 Feb 2004 08:21:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao0UI-0007f8-00 for sipping-web-archive@ietf.org; Tue, 03 Feb 2004 08:21:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao0UB-0002rn-AM; Tue, 03 Feb 2004 08:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao0TZ-0002mc-HX for sipping@optimus.ietf.org; Tue, 03 Feb 2004 08:20:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07761 for ; Tue, 3 Feb 2004 08:20:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao0TY-0007dB-00 for sipping@ietf.org; Tue, 03 Feb 2004 08:20:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao0Sd-0007YD-00 for sipping@ietf.org; Tue, 03 Feb 2004 08:19:28 -0500 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao0SS-0007T9-00 for sipping@ietf.org; Tue, 03 Feb 2004 08:19:16 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Feb 2004 08:18:45 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6380@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Aarti Iyengar'" , sipping@ietf.org Subject: RE: [Sipping] SIP-T and BICC Date: Tue, 3 Feb 2004 08:18:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Since SIP depends on SDP for describing bearers, and SDP can describe an ATM bearer (RFC3108), you can't use that as a discriminator. We have SIP products that are ATM based. The primary difference between the two is that BICC uses the EXISTING SS7 network for the signaling, and an IP (or ATM) network for the bearer, where SIP-T uses IP (or ATM) for both the signaling and the bearer. Also, the fundamental idea of SIP-T is that SIP is the signaling protocol, and the -T part allows SIP to carry those parts of ISUP that have no SIP equivalent. This allows calls between two ISUP controlled endpoints to use SIP in the middle of the network. Contrast that to BICC, where the assumption is that the whole network is ISUP signaled. Thus if you believe that SIP will eventually supplant ISUP for voice signaling, you might want to use SIP-T. If you expect that multimedia (video, text, ...) bearers might be interesting, you might want to chose SIP-T. Conversely, if you think that separating signaling from bearers is essential, you might choose BICC. Interoperating with these two protocols is somewhat problematic, primarily because they don't anticipate each other; SIP-T does not specifically deal with the bearer extension introduced by BICC, although it would be pretty trivial to take it into account. BICC does not admit any other signaling for endpoints (CS-3 notwithstanding). In practice, I expect you COULD interwork them if you needed to. Brian > -----Original Message----- > From: Aarti Iyengar [mailto:aartii@hotmail.com] > Sent: Tuesday, February 03, 2004 6:36 AM > To: sipping@ietf.org > Subject: [Sipping] SIP-T and BICC > > > All, > I am trying to understand SIP-T and BICC in detail. > From my initial reading, both are essentially to seamlessly > interface the PSTN to broadband networks. SIP-T is specifically for > SIP based IP networks, whereas BICC is bearer independent and can > interface with IP/ATM networks well. Apart from that, SIP-T deals > with ISUP translation and encapsulation while BICC deals with > extensions with ISUP for additional bearer support. > BICC CS3 will also enable SIP services to co-exist with BICC based > networks. > My questions are - > Are these the only key differences between these protocols which > essentially are intended perform the same function? If there are > others, what are they? > Are there certain situations where one would fit in better than the > other, and if so what are these? > How well would these interoperate with each other if they have to > co-exist? > > Also, any pointers to urls/whitepapers on the above (BICC versus > SIP-T) would be appreciated. > > thanks > Aarti > > _________________________________________________________________ > The new MSN 8: advanced junk mail protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 4 00:42:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23624 for ; Wed, 4 Feb 2004 00:42:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoFnN-0006rb-KA for sipping-archive@odin.ietf.org; Wed, 04 Feb 2004 00:41:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i145frpd026377 for sipping-archive@odin.ietf.org; Wed, 4 Feb 2004 00:41:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoFnN-0006rM-G3 for sipping-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 00:41:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23581 for ; Wed, 4 Feb 2004 00:41:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoFnK-0004k1-00 for sipping-web-archive@ietf.org; Wed, 04 Feb 2004 00:41:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoFmM-0004dN-00 for sipping-web-archive@ietf.org; Wed, 04 Feb 2004 00:40:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoFlO-0004X0-00 for sipping-web-archive@ietf.org; Wed, 04 Feb 2004 00:39:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoFkb-0006c9-5y; Wed, 04 Feb 2004 00:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoFkV-0006bF-02 for sipping@optimus.ietf.org; Wed, 04 Feb 2004 00:38:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23429 for ; Wed, 4 Feb 2004 00:38:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoFkS-0004Ri-00 for sipping@ietf.org; Wed, 04 Feb 2004 00:38:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoFjY-0004MJ-00 for sipping@ietf.org; Wed, 04 Feb 2004 00:37:56 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AoFie-0004BE-00 for sipping@ietf.org; Wed, 04 Feb 2004 00:37:00 -0500 Received: from dynamicsoft.com ([63.113.46.81]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i145aU9W015064; Wed, 4 Feb 2004 00:36:31 -0500 (EST) Message-ID: <402084C9.7040503@dynamicsoft.com> Date: Wed, 04 Feb 2004 00:36:09 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: suhac@ednet.co.uk CC: sipping@ietf.org References: <001f01c3ea47$b5317200$e3e714d4@Azopardi> In-Reply-To: <001f01c3ea47$b5317200$e3e714d4@Azopardi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Sip] Music On Hold Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline, and moving to sipping. Suha Cubukcuoglu wrote: > Hi, > > During an attended call transfer attempt, the transferred party > (A-Party) is put on 'hold' by the transferor (B-Party) - i.e. no media > stream flows from B to A and vice versa. While the A-Party is on hold, > the B-Party can INVITE a third party to play 'Music on Hold' tune to the > A-Party until the transfer attempt succeeds. We think that there are > complications in this approach. Firstly, the SIP Proxy must now where to > route the new INVITE generated by the B-Party. If the destination URI is > 'moh@someserver.com', the SIP Proxy must either do a DNS query or use > its IP dial-plans to know where to route the call. Sure. The URI needs to exist and be routable in the domain. Why is this a problem? > Secondly, the B-Party > might eventually end-up receiving the music tune whereas it was > initially intended for the A-Party - we've had problems in the past > because of this. If the INVITE contains sdp pointing the media to the a-party (which it should), this shouldnt happen. Is your on-hold server ignoring the address in the SDP? > We think that third party invitation is a bad idea, and it would rather > be more suitable to have a dedicated server (IVR unit perhaps) which the > SIP Proxy Server can transfer calls to/from upon request for a MOH > service. Could you tell us your opinions about this please? Proxies dont transfer calls, as they dont maintain call state. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 4 02:10:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06758 for ; Wed, 4 Feb 2004 02:10:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHAe-0006cA-GJ for sipping-archive@odin.ietf.org; Wed, 04 Feb 2004 02:10:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i147A077025416 for sipping-archive@odin.ietf.org; Wed, 4 Feb 2004 02:10:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHAd-0006br-6A for sipping-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 02:09:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06299 for ; Wed, 4 Feb 2004 02:09:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHAZ-0004MC-00 for sipping-web-archive@ietf.org; Wed, 04 Feb 2004 02:09:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoH9c-0004Gn-00 for sipping-web-archive@ietf.org; Wed, 04 Feb 2004 02:08:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoH8q-0004C9-00 for sipping-web-archive@ietf.org; Wed, 04 Feb 2004 02:08:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoH8k-0005sW-Qp; Wed, 04 Feb 2004 02:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoH8h-0005r5-0T for sipping@optimus.ietf.org; Wed, 04 Feb 2004 02:07:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04085 for ; Wed, 4 Feb 2004 02:07:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoH8d-0004Bg-00 for sipping@ietf.org; Wed, 04 Feb 2004 02:07:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoH7g-00047M-00 for sipping@ietf.org; Wed, 04 Feb 2004 02:06:57 -0500 Received: from natsmtp01.rzone.de ([81.169.145.166]) by ietf-mx with esmtp (Exim 4.12) id 1AoH7N-00042q-00 for sipping@ietf.org; Wed, 04 Feb 2004 02:06:38 -0500 Received: from sip (pD9E10F4E.dip.t-dialin.net [217.225.15.78]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i1476Vdr018037; Wed, 4 Feb 2004 08:06:31 +0100 (MET) From: "Christian Stredicke" To: "'Jonathan Rosenberg'" , Cc: Subject: RE: [Sipping] Re: [Sip] Music On Hold Date: Wed, 4 Feb 2004 08:06:33 +0100 Message-ID: <06f101c3eaed$6c8a0840$8548e6c2@sip> 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.4510 Importance: Normal In-Reply-To: <402084C9.7040503@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I am still convinced we need a more lightweight model that puts less = burden on the user agent which puts someone on hold. I mean, which user agent = does implement the model with a media server? Why don't we just provide a music-URL like in Alert-Info? The other user agent then can pick whatever it likes (http/WAV, sip, MIDI or whatever). = I think that's ten times easier. BTW this information could also be inserted by the proxy (without maintaining call state). This avoids the problem of setting the user = agents up for this. Christian > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf = Of > Jonathan Rosenberg > Sent: Wednesday, February 04, 2004 6:36 AM > To: suhac@ednet.co.uk > Cc: sipping@ietf.org > Subject: [Sipping] Re: [Sip] Music On Hold >=20 > inline, and moving to sipping. >=20 > Suha Cubukcuoglu wrote: >=20 > > Hi, > > > > During an attended call transfer attempt, the transferred party > > (A-Party) is put on 'hold' by the transferor (B-Party) - i.e. no = media > > stream flows from B to A and vice versa. While the A-Party is on = hold, > > the B-Party can INVITE a third party to play 'Music on Hold' tune to = the > > A-Party until the transfer attempt succeeds. We think that there are > > complications in this approach. Firstly, the SIP Proxy must now = where to > > route the new INVITE generated by the B-Party. If the destination = URI is > > 'moh@someserver.com', the SIP Proxy must either do a DNS query or = use > > its IP dial-plans to know where to route the call. >=20 > Sure. The URI needs to exist and be routable in the domain. Why is = this > a problem? >=20 > > Secondly, the B-Party > > might eventually end-up receiving the music tune whereas it was > > initially intended for the A-Party - we've had problems in the past > > because of this. >=20 > If the INVITE contains sdp pointing the media to the a-party (which it > should), this shouldnt happen. Is your on-hold server ignoring the > address in the SDP? >=20 >=20 > > We think that third party invitation is a bad idea, and it would = rather > > be more suitable to have a dedicated server (IVR unit perhaps) which = the > > SIP Proxy Server can transfer calls to/from upon request for a MOH > > service. Could you tell us your opinions about this please? >=20 > Proxies dont transfer calls, as they dont maintain call state. >=20 > Thanks, > Jonathan R. >=20 >=20 >=20 > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 4 02:30:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21687 for ; Wed, 4 Feb 2004 02:30:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHTz-0003AH-VH for sipping-archive@odin.ietf.org; Wed, 04 Feb 2004 02:30:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i147TxIW012164 for sipping-archive@odin.ietf.org; Wed, 4 Feb 2004 02:29:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHTz-0003A5-ET for sipping-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 02:29:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21259 for ; Wed, 4 Feb 2004 02:29:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHTv-0006EU-00 for sipping-web-archive@ietf.org; Wed, 04 Feb 2004 02:29:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHSx-00069C-00 for sipping-web-archive@ietf.org; Wed, 04 Feb 2004 02:28:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoHS7-00064D-00 for sipping-web-archive@ietf.org; Wed, 04 Feb 2004 02:28:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHS7-0002gd-J0; Wed, 04 Feb 2004 02:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHR8-0002Sn-Lm for sipping@optimus.ietf.org; Wed, 04 Feb 2004 02:27:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19161 for ; Wed, 4 Feb 2004 02:26:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHR5-0005zT-00 for sipping@ietf.org; Wed, 04 Feb 2004 02:26:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHQG-0005ul-00 for sipping@ietf.org; Wed, 04 Feb 2004 02:26:09 -0500 Received: from mailserv.intranet.gr ([146.124.14.106]) by ietf-mx with esmtp (Exim 4.12) id 1AoHPj-0005nU-00 for sipping@ietf.org; Wed, 04 Feb 2004 02:25:35 -0500 Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.11.7/8.11.3) with ESMTP id i147Tcb21515 for ; Wed, 4 Feb 2004 09:29:38 +0200 (EET) Received: from hal.intranet.gr (hal.intranet.GR [146.124.2.254]) by mailserv.intranet.gr (8.11.7/8.11.3) with ESMTP id i147TTa21414; Wed, 4 Feb 2004 09:29:29 +0200 (EET) Received: from localhost (pcdpd120 [146.124.2.235]) by hal.intranet.gr (8.11.7p1+Sun/8.10.2) with ESMTP id i147EPc28085; Wed, 4 Feb 2004 09:14:25 +0200 (EET) Message-Id: <200402040714.i147EPc28085@hal.intranet.gr> From: "F.S.Salloum" To: "'Christian Stredicke'" , "'Jonathan Rosenberg'" , Cc: Subject: RE: [Sipping] Re: [Sip] Music On Hold Date: Wed, 4 Feb 2004 09:24:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <06f101c3eaed$6c8a0840$8548e6c2@sip> Thread-Index: AcPq7EqGsV9tAuIzTq6l/eS/yMezNAAApifQ Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, please find my opinions inline >>-----Original Message----- >>From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of >>Christian Stredicke >>Sent: Wednesday, February 04, 2004 9:07 AM >>To: 'Jonathan Rosenberg'; suhac@ednet.co.uk >>Cc: sipping@ietf.org >>Subject: RE: [Sipping] Re: [Sip] Music On Hold >>I am still convinced we need a more lightweight model that puts less >>burden >>on the user agent which puts someone on hold. I mean, which user agent >>does >>implement the model with a media server? A lot of commercial product also our HW phones(http://netphone.intracom.gr/) support this approach with no problem >>Why don't we just provide a music-URL like in Alert-Info? The other user >>agent then can pick whatever it likes (http/WAV, sip, MIDI or whatever). I >>think that's ten times easier. I think we should consider security issues check this link with a discussions with alert info stuff (http://www.atm.tut.fi/list-archive/sip/msg01278.html) >>BTW this information could also be inserted by the proxy (without >>maintaining call state). This avoids the problem of setting the user >>agents >>up for this. >>Christian Enjoy Sotiris > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of > Jonathan Rosenberg > Sent: Wednesday, February 04, 2004 6:36 AM > To: suhac@ednet.co.uk > Cc: sipping@ietf.org > Subject: [Sipping] Re: [Sip] Music On Hold > > inline, and moving to sipping. > > Suha Cubukcuoglu wrote: > > > Hi, > > > > During an attended call transfer attempt, the transferred party > > (A-Party) is put on 'hold' by the transferor (B-Party) - i.e. no media > > stream flows from B to A and vice versa. While the A-Party is on hold, > > the B-Party can INVITE a third party to play 'Music on Hold' tune to the > > A-Party until the transfer attempt succeeds. We think that there are > > complications in this approach. Firstly, the SIP Proxy must now where to > > route the new INVITE generated by the B-Party. If the destination URI is > > 'moh@someserver.com', the SIP Proxy must either do a DNS query or use > > its IP dial-plans to know where to route the call. > > Sure. The URI needs to exist and be routable in the domain. Why is this > a problem? > > > Secondly, the B-Party > > might eventually end-up receiving the music tune whereas it was > > initially intended for the A-Party - we've had problems in the past > > because of this. > > If the INVITE contains sdp pointing the media to the a-party (which it > should), this shouldnt happen. Is your on-hold server ignoring the > address in the SDP? > > > > We think that third party invitation is a bad idea, and it would rather > > be more suitable to have a dedicated server (IVR unit perhaps) which the > > SIP Proxy Server can transfer calls to/from upon request for a MOH > > service. Could you tell us your opinions about this please? > > Proxies dont transfer calls, as they dont maintain call state. > > Thanks, > Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 4 03:42:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25869 for ; Wed, 4 Feb 2004 03:42:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoIbk-00027f-4W for sipping-archive@odin.ietf.org; Wed, 04 Feb 2004 03:42:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i148g4aj008155 for sipping-archive@odin.ietf.org; Wed, 4 Feb 2004 03:42:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoIbj-00027P-KO for sipping-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 03:42:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25851 for ; Wed, 4 Feb 2004 03:42:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoIbh-0006YH-00 for sipping-web-archive@ietf.org; Wed, 04 Feb 2004 03:42:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoIan-0006SY-00 for sipping-web-archive@ietf.org; Wed, 04 Feb 2004 03:41:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoIZu-0006Mo-00 for sipping-web-archive@ietf.org; Wed, 04 Feb 2004 03:40:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoIZo-0001q9-5a; Wed, 04 Feb 2004 03:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoIYn-0001nZ-Ge for sipping@optimus.ietf.org; Wed, 04 Feb 2004 03:39:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25776 for ; Wed, 4 Feb 2004 03:38:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoIYl-0006GK-00 for sipping@ietf.org; Wed, 04 Feb 2004 03:38:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoIY0-0006Bn-00 for sipping@ietf.org; Wed, 04 Feb 2004 03:38:13 -0500 Received: from natsmtp01.rzone.de ([81.169.145.166]) by ietf-mx with esmtp (Exim 4.12) id 1AoIXL-00065x-00 for sipping@ietf.org; Wed, 04 Feb 2004 03:37:31 -0500 Received: from sip (pD9E10F4E.dip.t-dialin.net [217.225.15.78]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i148bSXB023686; Wed, 4 Feb 2004 09:37:29 +0100 (MET) From: "Christian Stredicke" To: "'F.S.Salloum'" , "'Jonathan Rosenberg'" , Cc: Subject: RE: [Sipping] Re: [Sip] Music On Hold Date: Wed, 4 Feb 2004 09:37:31 +0100 Message-ID: <070a01c3eafa$219c4980$8548e6c2@sip> 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.4510 Importance: Normal In-Reply-To: <200402040714.i147EPc28085@hal.intranet.gr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Comments inline! > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf = Of > F.S.Salloum > Sent: Wednesday, February 04, 2004 8:25 AM > To: 'Christian Stredicke'; 'Jonathan Rosenberg'; suhac@ednet.co.uk > Cc: sipping@ietf.org > Subject: RE: [Sipping] Re: [Sip] Music On Hold >=20 > Hi, please find my opinions inline >=20 > >>-----Original Message----- > >>From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On = Behalf > Of > >>Christian Stredicke > >>Sent: Wednesday, February 04, 2004 9:07 AM > >>To: 'Jonathan Rosenberg'; suhac@ednet.co.uk > >>Cc: sipping@ietf.org > >>Subject: RE: [Sipping] Re: [Sip] Music On Hold >=20 > >>I am still convinced we need a more lightweight model that puts less > >>burden > >>on the user agent which puts someone on hold. I mean, which user = agent > >>does > >>implement the model with a media server? >=20 >=20 > A lot of commercial product also our HW > phones(http://netphone.intracom.gr/) > support this approach with no problem >=20 [Christian Stredicke] We also support this, but I can't say "no = problem". It's easy to get it working in the lab, but the real world shows us a different picture. Calls get lost (people just plug the cable), transfer fails, people are sitting behind NAT, media server running out of = resources, media server and negotiated codec don't find a common codec (cause only = the answer is available). Maybe is a question of the pain level, but for us = it's a "problem". Of course, anything can be solved, but what I am trying to say is the Alert-Info model would be much simpler. We could have the same = discussion in ring tones!!! >=20 >=20 > >>Why don't we just provide a music-URL like in Alert-Info? The other = user > >>agent then can pick whatever it likes (http/WAV, sip, MIDI or = whatever). > I > >>think that's ten times easier. >=20 >=20 > I think we should consider security issues check this link with a > discussions with alert info stuff > (http://www.atm.tut.fi/list-archive/sip/msg01278.html) >=20 [Christian Stredicke] There are also (bigger?) security problems with = the 3PCC model. And the Alert-Info security problem has to be solved anyway = (or has been solved already). >=20 > >>BTW this information could also be inserted by the proxy (without > >>maintaining call state). This avoids the problem of setting the user > >>agents > >>up for this. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 4 15:47:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26018 for ; Wed, 4 Feb 2004 15:47:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTuq-0005PM-SP for sipping-archive@odin.ietf.org; Wed, 04 Feb 2004 15:46:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14KkWFk020784 for sipping-archive@odin.ietf.org; Wed, 4 Feb 2004 15:46:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTuq-0005P9-Mt for sipping-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 15:46:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25978 for ; Wed, 4 Feb 2004 15:46:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoTuo-00021C-00 for sipping-web-archive@ietf.org; Wed, 04 Feb 2004 15:46:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoTtw-0001u0-00 for sipping-web-archive@ietf.org; Wed, 04 Feb 2004 15:45:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoTsw-0001n2-00 for sipping-web-archive@ietf.org; Wed, 04 Feb 2004 15:44:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTsS-0004rS-Pk; Wed, 04 Feb 2004 15:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTs5-0004nP-7I for sipping@optimus.ietf.org; Wed, 04 Feb 2004 15:43:41 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25736; Wed, 4 Feb 2004 15:43:38 -0500 (EST) Message-Id: <200402042043.PAA25736@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 04 Feb 2004 15:43:38 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-kpml-02.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Keypad Stimulus Protocol (KPML) Author(s) : E. Burger Filename : draft-ietf-sipping-kpml-02.txt Pages : 42 Date : 2004-2-4 The Key Press Stimulus Protocol uses the SIP SUBSCRIBE/NOTIFY mechanism and Keypad Markup Language (KPML) to provide instructions to SIP User Agents for the reporting of user key presses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-kpml-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-kpml-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-4160302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-kpml-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-kpml-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-4160302.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 5 02:41:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05357 for ; Thu, 5 Feb 2004 02:41:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoe7z-0006c7-Ul for sipping-archive@odin.ietf.org; Thu, 05 Feb 2004 02:40:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i157elpM025419 for sipping-archive@odin.ietf.org; Thu, 5 Feb 2004 02:40:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoe7z-0006bu-EX for sipping-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 02:40:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05335 for ; Thu, 5 Feb 2004 02:40:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoe7v-0005gr-00 for sipping-web-archive@ietf.org; Thu, 05 Feb 2004 02:40:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoe6x-0005bZ-00 for sipping-web-archive@ietf.org; Thu, 05 Feb 2004 02:39:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aoe6N-0005Wt-00 for sipping-web-archive@ietf.org; Thu, 05 Feb 2004 02:39:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoe6I-0006K0-Q4; Thu, 05 Feb 2004 02:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoe61-0006Gn-V9 for sipping@optimus.ietf.org; Thu, 05 Feb 2004 02:38:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05308 for ; Thu, 5 Feb 2004 02:38:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoe5y-0005WA-00 for sipping@ietf.org; Thu, 05 Feb 2004 02:38:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoe52-0005Rr-00 for sipping@ietf.org; Thu, 05 Feb 2004 02:37:44 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aoe4L-0005IS-00 for sipping@ietf.org; Thu, 05 Feb 2004 02:37:01 -0500 Received: from dynamicsoft.com ([63.113.46.122]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i157aa9W015968; Thu, 5 Feb 2004 02:36:38 -0500 (EST) Message-ID: <4021F27B.3040007@dynamicsoft.com> Date: Thu, 05 Feb 2004 02:36:27 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Stredicke CC: "'F.S.Salloum'" , suhac@ednet.co.uk, sipping@ietf.org Subject: Re: [Sipping] Re: [Sip] Music On Hold References: <070a01c3eafa$219c4980$8548e6c2@sip> In-Reply-To: <070a01c3eafa$219c4980$8548e6c2@sip> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Christian Stredicke wrote: >>A lot of commercial product also our HW >>phones(http://netphone.intracom.gr/) >>support this approach with no problem >> > > [Christian Stredicke] We also support this, but I can't say "no problem". > It's easy to get it working in the lab, but the real world shows us a > different picture. Calls get lost (people just plug the cable), transfer > fails, people are sitting behind NAT, media server running out of resources, > media server and negotiated codec don't find a common codec (cause only the > answer is available). Maybe is a question of the pain level, but for us it's > a "problem". > > Of course, anything can be solved, but what I am trying to say is the > Alert-Info model would be much simpler. We could have the same discussion in > ring tones!!! Its not clear to me that many of the problems you list above would go away with an Alert-Info style approach. Certainly, those calls can get lost, there can be nat problems, the server can still run out of resources, etc. You also indicate that there is a problem finding a common codec. Of course, if there are simply no codecs in common no signaling in the world will help. However, I don't think thats what you mean. In the flow in the service examples draft, the user placing the call on hold (b-party) issues an invite to the music on hold server with no sdp. That triggers the music on hold server to issue an offer with a full codec list. That is passed to the A-party, which picks the one(s) it wants. Thus, the music on hold can use different codecs than what is negotiated in the call between A and B. So, I dont see a specific problem. Can you elaborate on the difficulty you see? >> >>I think we should consider security issues check this link with a >>discussions with alert info stuff >>(http://www.atm.tut.fi/list-archive/sip/msg01278.html) >> > > [Christian Stredicke] There are also (bigger?) security problems with the > 3PCC model. And the Alert-Info security problem has to be solved anyway (or > has been solved already). 3pcc in this specific case is not so hard, since (presumably) there is a relationship between the b-party and the music on hold server. If the B-party rather tells the A-party to contact the music on hold server directly (using an alert-info kind of approach), now there needs to be a security relationship between the A-party on the music on hold server, which doesnt exist. Relaying signaling through the B-party makes the security more tenable, I think. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 5 02:51:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05821 for ; Thu, 5 Feb 2004 02:51:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeHl-0007mK-Vz for sipping-archive@odin.ietf.org; Thu, 05 Feb 2004 02:50:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i157oroA029896 for sipping-archive@odin.ietf.org; Thu, 5 Feb 2004 02:50:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeHl-0007m6-HG for sipping-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 02:50:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05799 for ; Thu, 5 Feb 2004 02:50:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoeHh-0006em-00 for sipping-web-archive@ietf.org; Thu, 05 Feb 2004 02:50:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoeGh-0006Yp-00 for sipping-web-archive@ietf.org; Thu, 05 Feb 2004 02:49:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoeFz-0006Tf-00 for sipping-web-archive@ietf.org; Thu, 05 Feb 2004 02:49:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeFy-0007Z4-Nu; Thu, 05 Feb 2004 02:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeFh-0007XS-I8 for sipping@optimus.ietf.org; Thu, 05 Feb 2004 02:48:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05748 for ; Thu, 5 Feb 2004 02:48:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoeFd-0006Sa-00 for sipping@ietf.org; Thu, 05 Feb 2004 02:48:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoeEi-0006Nm-00 for sipping@ietf.org; Thu, 05 Feb 2004 02:47:45 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AoeDr-0006E6-00 for sipping@ietf.org; Thu, 05 Feb 2004 02:46:51 -0500 Received: from dynamicsoft.com ([63.113.46.122]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i157kV9W015977 for ; Thu, 5 Feb 2004 02:46:31 -0500 (EST) Message-ID: <4021F4CD.6070803@dynamicsoft.com> Date: Thu, 05 Feb 2004 02:46:21 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-kpml-02.txt References: <200402042043.PAA25736@ietf.org> In-Reply-To: <200402042043.PAA25736@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, The draft talks about sending the subscribe requests on the same dialog as the INVITE. For many reasons that have been discussed ad nauseam on the list, dialog sharing is a bad idea. GRUU provides a solution that does not require dialog sharing. As I recall, there was discussion on this point in the last ietf, and this seemed to be the preferred direction. Is there any reason we cant change this to use gruu's rather than dialog sharing? Also, you are missing the IANA registration for the kpml event package. Thanks, Jonathan R. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. > > Title : Keypad Stimulus Protocol (KPML) > Author(s) : E. Burger > Filename : draft-ietf-sipping-kpml-02.txt > Pages : 42 > Date : 2004-2-4 > > The Key Press Stimulus Protocol uses the SIP SUBSCRIBE/NOTIFY > mechanism and Keypad Markup Language (KPML) to provide instructions > to SIP User Agents for the reporting of user key presses. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-02.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sipping-kpml-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sipping-kpml-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 5 11:12:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21434 for ; Thu, 5 Feb 2004 11:12:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aom6m-0007uu-28 for sipping-archive@odin.ietf.org; Thu, 05 Feb 2004 11:12:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15GC4Dt030428 for sipping-archive@odin.ietf.org; Thu, 5 Feb 2004 11:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aom6l-0007uh-TS for sipping-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 11:12:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21392 for ; Thu, 5 Feb 2004 11:12:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aom6k-0006ts-00 for sipping-web-archive@ietf.org; Thu, 05 Feb 2004 11:12:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aom5n-0006nE-00 for sipping-web-archive@ietf.org; Thu, 05 Feb 2004 11:11:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aom4z-0006hT-00 for sipping-web-archive@ietf.org; Thu, 05 Feb 2004 11:10:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aom4q-0007EU-Q0; Thu, 05 Feb 2004 11:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aom45-0007CT-If for sipping@optimus.ietf.org; Thu, 05 Feb 2004 11:09:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21272 for ; Thu, 5 Feb 2004 11:09:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aom42-0006Zh-00 for sipping@ietf.org; Thu, 05 Feb 2004 11:09:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aom2x-0006Sz-00 for sipping@ietf.org; Thu, 05 Feb 2004 11:08:08 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1Aom2U-0006N8-00 for sipping@ietf.org; Thu, 05 Feb 2004 11:07:38 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i15G6pE01473; Thu, 5 Feb 2004 08:06:51 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMVY76T>; Thu, 5 Feb 2004 10:06:51 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF578FA9@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Jonathan Rosenberg'" , "'Gonzalo Camarillo'" Cc: "'sipping@ietf.org'" Date: Thu, 5 Feb 2004 10:06:50 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Sipping] General comments and NITs on draft-rosenberg-sipping-nat-scenario s-02 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Jonathan and Gonzalo, Sorry for the delay in providing feedback on this work. I have a couple of general points for discussion and then some detailed nits. Following the thread of this work , I also will post separately a few comments on the MMUSIC WG ICE draft. General: 1) What are the changes in the -02 from the -01? The only thing I could spot was an update to reference [11]. I had done an initial review of the -01 and the -02 appeared before I had a chance to post those comments, so perhaps I didn't re-review closely enough. 2) On the current plan to use this document to replace the existing WG NAT scenarios document, I have concerns that there will be a loss of background information that might be useful. I also think that the current WG document fairly accurately reflects the plethora of various solution options out there for this problem (albeit none of them ideal). And, though I do generally agree that with the ICE approach in terms of minimizing the knowledge of topology etc in the client, the reality is that ALGs and some of the other solutions are likely to remain around for a while and I think it's useful to keep documentation of where they fit relative to this solution. I realize that progressing the existing WG NAT scenarios document by itself (which would need some work to complete) isn't necessarily productive. One thought I had was that perhaps parts of the existing document could be included in the Appendix, with these less desireable alternatives referenced in the corresponding sections of the ICE based scenarios. In a sense, this might add strength to why ICE would be preferred to these alternatives. 3) Somewhat related to point 2, I really like the completeness of the flows in the existing WG NAT scenarios as they do include the SIP messages and the media flow in many cases. I realize that this draft does detail the appropriate SDP, but the message flows consist entirely of the STUN and TURN messages. I realize that adding the SIP messages will dramatically increase the size of the flows. Perhaps adding one or two detailed flows at the beginning (or as appropriate) and then just referring to Steps x, y, and z, etc. in those flows would add some value. Specific NITs/comments: 1) Relative to General point 2 above, I think one value of ICE beyond what's in the existing WG NAT scenarios document is the v6 to v4 scenario. I think it would be good to highlight that in the abstract. I would propose extending the sentence: "The examples cover a range of network topologies and use cases." to: "The examples cover a range of network topologies and use cases, including IPv6 networks interworking with IPv4." 2) Page 6, section 2.1, 1st para, next to last sentence: "Thought not show,..." should be "Though not shown, ...". 3) page 16, section 2.2, 1st para, last sentence: "A's discovers..." should be with "A discovers...". 4) page 18, section 2.2, paragraph between Figure 9 and Figure 2, for readability I would suggest splitting this into 2 paragraphs starting with the 4th sentence "B now begins connectivity checks." Also, consistent with the layout for section 2.2, it might be better to move that second portion of the paragraph after Figure 10. 5) Page 21, section 2.2, OPEN ISSUE, last sentence: "doesnt" should be "doesn't". Also, shouldn't this OPEN ISSUE be captured in the MMUSIC WG ICE document, as doesn't it reflect an algorithmic problem with the prioritization scheme? 6) Page 28, section 3.1, last para, 2nd sentence: "Thats" should be "That's" 7) Page 29, section 3.2, last para, last sentence would read more clearly by explicitly mentioning that it will not lockdown as follows: " Here, it will not lockdown, since the address learned from the TURN server --------- is never advertised to any peers." 7) Page 29, section 3.2, related to my general comment 3 above, it would be nice to have a message flow here, showing the continued flow though the TURN server for this scenario. 8) Page 33, section 3.3, SDP should be labeled as Figure 21. 9) Page 33, paragraph immediately following SDP, "... B;s connectivity test." should be "...B's connectivity test." 10) Page 47, section 6, 1st paragraph, "...packets addresses to that PREFIX..." should be "...packets addressed to that PREFIX..." 11) Page 55, I'm assuming Reference [4] needs to be updated as the MMUSIC WG ICE document. Regards, Mary H. Barnes mary.barnes@nortelnetworks.com 972-684-5432 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 5 15:03:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01913 for ; Thu, 5 Feb 2004 15:03:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AopiV-0005ys-O2 for sipping-archive@odin.ietf.org; Thu, 05 Feb 2004 15:03:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15K3FG2022984 for sipping-archive@odin.ietf.org; Thu, 5 Feb 2004 15:03:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AopiV-0005yd-H6 for sipping-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 15:03:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01846 for ; Thu, 5 Feb 2004 15:03:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AopiS-00001q-00 for sipping-web-archive@ietf.org; Thu, 05 Feb 2004 15:03:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AophW-0007iW-00 for sipping-web-archive@ietf.org; Thu, 05 Feb 2004 15:02:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aopgb-0007cF-00 for sipping-web-archive@ietf.org; Thu, 05 Feb 2004 15:01:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AopgN-0003vG-P0; Thu, 05 Feb 2004 15:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aopfj-0002yr-2j for sipping@optimus.ietf.org; Thu, 05 Feb 2004 15:00:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01761 for ; Thu, 5 Feb 2004 15:00:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aopfg-0007W2-00 for sipping@ietf.org; Thu, 05 Feb 2004 15:00:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aopel-0007Pq-00 for sipping@ietf.org; Thu, 05 Feb 2004 14:59:24 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Aope7-0007JH-00 for sipping@ietf.org; Thu, 05 Feb 2004 14:58:43 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i15JwgYG018403 for ; Thu, 5 Feb 2004 20:58:42 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 20:58:42 +0100 Received: from ericsson.com (rvi2-93-78.sw.ericsson.se [153.88.93.78]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJ15GGK; Thu, 5 Feb 2004 20:59:16 +0100 Message-ID: <4022A06B.4020708@ericsson.com> Date: Thu, 05 Feb 2004 21:58:35 +0200 X-Sybari-Trust: 6c7cd852 6b512624 6c3547e6 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mary Barnes CC: "'Jonathan Rosenberg'" , "'sipping@ietf.org'" References: <870397D7C140C84DB081B88396458DAF578FA9@zrc2c000.us.nortel.com> In-Reply-To: <870397D7C140C84DB081B88396458DAF578FA9@zrc2c000.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2004 19:58:42.0438 (UTC) FILETIME=[74845A60:01C3EC22] Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: General comments and NITs on draft-rosenberg-sipping-nat-scenario s-02 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mary, a quick answer to your first point: > 1) What are the changes in the -02 from the -01? The only thing I could > spot was an update to reference [11]. I had done an initial review of the > -01 and the -02 appeared before I had a chance to post those comments, so > perhaps I didn't re-review closely enough. The RFC editor got confused somehow when publishing this draft. So, we ended up with two different documents called the same way (version 01): an old version, and the new version... to resolve this mess, we submitted the 02 version. Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 5 15:47:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05695 for ; Thu, 5 Feb 2004 15:47:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqP8-0006yv-M4 for sipping-archive@odin.ietf.org; Thu, 05 Feb 2004 15:47:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15KlIVq026833 for sipping-archive@odin.ietf.org; Thu, 5 Feb 2004 15:47:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqP8-0006yi-I8 for sipping-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 15:47:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05667 for ; Thu, 5 Feb 2004 15:47:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoqP7-0004UT-00 for sipping-web-archive@ietf.org; Thu, 05 Feb 2004 15:47:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoqOD-0004No-00 for sipping-web-archive@ietf.org; Thu, 05 Feb 2004 15:46:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoqND-0004Gw-00 for sipping-web-archive@ietf.org; Thu, 05 Feb 2004 15:45:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqMz-0006bE-QW; Thu, 05 Feb 2004 15:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqMj-0006Yn-Tc for sipping@optimus.ietf.org; Thu, 05 Feb 2004 15:44:49 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05430; Thu, 5 Feb 2004 15:44:47 -0500 (EST) Message-Id: <200402052044.PAA05430@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 05 Feb 2004 15:44:47 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-transc-3pcc-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Transcoding Services Invocation in the Session Initiation Protocol Using Third Party Call Control Author(s) : G. Camarillo Filename : draft-ietf-sipping-transc-3pcc-00.txt Pages : 18 Date : 2004-2-5 This document describes how to invoke transcoding services using SIP and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-3pcc-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-transc-3pcc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-transc-3pcc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-5155353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-transc-3pcc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-transc-3pcc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-5155353.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 6 02:56:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15696 for ; Fri, 6 Feb 2004 02:56:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0q3-0006O7-A6 for sipping-archive@odin.ietf.org; Fri, 06 Feb 2004 02:55:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i167tlu0024549 for sipping-archive@odin.ietf.org; Fri, 6 Feb 2004 02:55:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0q3-0006Ns-4R for sipping-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 02:55:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15682 for ; Fri, 6 Feb 2004 02:55:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0pz-0002oy-00 for sipping-web-archive@ietf.org; Fri, 06 Feb 2004 02:55:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap0p6-0002l6-00 for sipping-web-archive@ietf.org; Fri, 06 Feb 2004 02:54:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0oN-0002gm-00 for sipping-web-archive@ietf.org; Fri, 06 Feb 2004 02:54:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0oN-00061r-2U; Fri, 06 Feb 2004 02:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0nt-000609-MN for sipping@optimus.ietf.org; Fri, 06 Feb 2004 02:53:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15587 for ; Fri, 6 Feb 2004 02:53:30 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0np-0002eH-00 for sipping@ietf.org; Fri, 06 Feb 2004 02:53:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap0mr-0002b5-00 for sipping@ietf.org; Fri, 06 Feb 2004 02:52:30 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0m2-0002Z4-00 for sipping@ietf.org; Fri, 06 Feb 2004 02:51:38 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i167pcv07730 for ; Fri, 6 Feb 2004 09:51:39 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Feb 2004 09:51:38 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 09:51:38 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 09:51:37 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 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: [Sipping] Conference policy URI Date: Fri, 6 Feb 2004 09:51:37 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797704@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] Conference policy URI Thread-Index: AcPiJAx3RA9FNGizTkyVU/mXNnfJVQKYddSg To: Cc: X-OriginalArrivalTime: 06 Feb 2004 07:51:37.0510 (UTC) FILETIME=[0C725C60:01C3EC86] Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks Jonathan. A draft has been submitted to the SIP WG. http://www.ietf.org/internet-drafts/draft-khartabil-sip-policy-uri-call-i= nfo-purpose-00.txt Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 24.January.2004 04:44 > To: Khartabil Hisham (Nokia-TP/Helsinki) > Cc: sipping@ietf.org > Subject: Re: [Sipping] Conference policy URI >=20 >=20 > I think this is a reasonable usage of Call-Info. However, it can only=20 > be done if a "purpose" tag value is registered with IANA, as=20 > indicated=20 > by section 20.9. However, it ocurred to me, when reading=20 > this, that we=20 > never set up an IANA registry for call-info purpose tokens! Oops!=20 > Thats easily rectifiable; when the draft defining the=20 > 'policy-uri' (or=20 > whatever its called) purpose tag is written, it should also=20 > create the=20 > registry and register the other tokens defined in rfc3261. >=20 > -Jonathan R. >=20 > hisham.khartabil@nokia.com wrote: >=20 > > Hi, > >=20 > > There was consensus on the XCON mailing list that the conference > > state event package needs to include in the notification the > > conference policy URI. > >=20 > > There was also consensus that some participants may not want to > > subscribe to the conference package but would still like to learn > > the conference policy URI. In this case, it was suggested that the > > Call-info header carries such information. Perhaps the > > cc-conferencing draft can include examples of that. > >=20 > > Thanks, Hisham > >=20 > > _______________________________________________ Sipping mailing > > list https://www1.ietf.org/mailman/listinfo/sipping This list is > > for NEW development of the application of SIP Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sip@ietf.org for new developments of core SIP > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 6 05:48:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19892 for ; Fri, 6 Feb 2004 05:48:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3WM-0001RF-L9 for sipping-archive@odin.ietf.org; Fri, 06 Feb 2004 05:47:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16AlcUK005529 for sipping-archive@odin.ietf.org; Fri, 6 Feb 2004 05:47:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3WM-0001R6-Gf for sipping-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 05:47:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19871 for ; Fri, 6 Feb 2004 05:47:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap3WI-0002gC-00 for sipping-web-archive@ietf.org; Fri, 06 Feb 2004 05:47:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap3VO-0002dY-00 for sipping-web-archive@ietf.org; Fri, 06 Feb 2004 05:46:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap3UW-0002bB-00 for sipping-web-archive@ietf.org; Fri, 06 Feb 2004 05:45:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap3Tq-00011j-6x; Fri, 06 Feb 2004 05:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHKS-0001AW-VA for sipping@optimus.ietf.org; Wed, 04 Feb 2004 02:20:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12015 for ; Wed, 4 Feb 2004 02:20:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHKP-0005JX-00 for sipping@ietf.org; Wed, 04 Feb 2004 02:20:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHJW-0005Db-00 for sipping@ietf.org; Wed, 04 Feb 2004 02:19:10 -0500 Received: from sea2-f66.sea2.hotmail.com ([207.68.165.66] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AoHIo-00055P-00 for sipping@ietf.org; Wed, 04 Feb 2004 02:18:26 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Feb 2004 23:17:57 -0800 Received: from 194.237.142.24 by sea2fd.sea2.hotmail.msn.com with HTTP; Wed, 04 Feb 2004 07:17:56 GMT X-Originating-IP: [194.237.142.24] X-Originating-Email: [jagdeepw@hotmail.com] X-Sender: jagdeepw@hotmail.com From: "Jagdeep Walia" To: sipping@ietf.org Cc: aartii@hotmail.com Subject: [Sipping] SIP-T and BICC Date: Wed, 04 Feb 2004 07:17:56 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Feb 2004 07:17:57.0212 (UTC) FILETIME=[036DD9C0:01C3EAEF] Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Dear Aarti, Since both have been developed to do the same job, the key to decide which one of them, really depends what your network looks like in actual pactice but Since the world is not always near to reality, the reason that would decide which protocol would be the mighty one standing test of time are, industry momemtum and hype generated. Its purely aesthetic than technical reasons since there are always ways how you put the point across. I believe in case it is incumbent operator who has a a fixed network in place and would like to migrate to a NGN infrastructure today, then he choice of BICC would be more suitable since it is based/extension of SS7 (so that a signalling control is there for the call bearer transversing through theATM/ IP network). It is possible to transport BICC over TDM/ATM/IP networks. The benefit that the incumbent drives from using BICC is that all the services and application that are supported via SS7 in his existing circuit switching network, can also still be available through BICC. But as regards to this SIP is still a evolving protocol which has still to have all capabilities e.g regarding support of TCAP services. It is a evolving protocol and would take sometime before thinghs settle down. SIP comes from IETF world where the protocol or standards are defines based on RFC which so as to say are bit open and loose when it comes to defining a certain procedure as it allows you to have flexibility and there could be different RFC which could coexist, so sometime the strenght of being open and flexible as we have come to understand is the Buzz word in todays telecom industry creates problem when we set out to interoperate. Thats quite evident from the fact that eventhough there had been IP router for so long, the interoperability for feature support between them took so long. So these things can be avoided in case BICC is used since it comes from ITU-T which truly defines standards and they are rigid to more extent when it comes down to implementing certain capabilities and functionalities. I see SIP-t presently could be good for some new operators who start with services that are supported via SIP-T. SIP-t surely is nearer to the concept of IP and would eventually be existing in most networks in future but the only thing is when does it get stabalised and a more rigid and defined protocol. ITU-T started work in the past on BICC CS3 which finally focussed on the defining a frame work for interworking between SIP and BICC/ISUP based network. In a recent SG11 meeting held in Geneva from September 1- September 12, ITU-T has already finalised the receommendation which existed as Q 1912.SIP and has become a recommendation called Q 1912.5. Regards jw Jagdeep Walia Telecommunication Engineer Email: Jagdeepw@hotmail.com _________________________________________________________________ Contact brides & grooms FREE! http://www.shaadi.com/ptnr.php?ptnr=hmltag Only on www.shaadi.com. Register now! _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 6 15:48:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15984 for ; Fri, 6 Feb 2004 15:48:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCtO-0006K6-G3 for sipping-archive@odin.ietf.org; Fri, 06 Feb 2004 15:48:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Km2kP024300 for sipping-archive@odin.ietf.org; Fri, 6 Feb 2004 15:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCtO-0006Jr-81 for sipping-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 15:48:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15920 for ; Fri, 6 Feb 2004 15:47:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApCtL-0002mz-00 for sipping-web-archive@ietf.org; Fri, 06 Feb 2004 15:47:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApCsR-0002hy-00 for sipping-web-archive@ietf.org; Fri, 06 Feb 2004 15:47:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApCrY-0002cw-00 for sipping-web-archive@ietf.org; Fri, 06 Feb 2004 15:46:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCrS-0005uJ-QK; Fri, 06 Feb 2004 15:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCqY-0005pV-0q for sipping@optimus.ietf.org; Fri, 06 Feb 2004 15:45:06 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15648; Fri, 6 Feb 2004 15:45:03 -0500 (EST) Message-Id: <200402062045.PAA15648@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 06 Feb 2004 15:45:02 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-transc-framework-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Framework for Transcoding with the Session Initiation Protocol Author(s) : G. Camarillo Filename : draft-ietf-sipping-transc-framework-00.txt Pages : 10 Date : 2004-2-7 This document defines a framework for transcoding with SIP. This framework includes how to discover the need of transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed; the conference bridge model and the third party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-framework-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-transc-framework-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-transc-framework-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-6160317.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-transc-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-transc-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-6160317.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 8 06:41:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16487 for ; Sun, 8 Feb 2004 06:41:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApnJP-0004t4-VI for sipping-archive@odin.ietf.org; Sun, 08 Feb 2004 06:41:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18BfJAR018780 for sipping-archive@odin.ietf.org; Sun, 8 Feb 2004 06:41:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApnJP-0004sp-RI for sipping-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 06:41:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16482 for ; Sun, 8 Feb 2004 06:41:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApnJL-0006gu-00 for sipping-web-archive@ietf.org; Sun, 08 Feb 2004 06:41:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApnIO-0006cI-00 for sipping-web-archive@ietf.org; Sun, 08 Feb 2004 06:40:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApnIC-0006Y7-00 for sipping-web-archive@ietf.org; Sun, 08 Feb 2004 06:40:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApnIB-0004gR-Nc; Sun, 08 Feb 2004 06:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApnHN-0004f5-I4 for sipping@optimus.ietf.org; Sun, 08 Feb 2004 06:39:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16446 for ; Sun, 8 Feb 2004 06:39:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApnHJ-0006X9-00 for sipping@ietf.org; Sun, 08 Feb 2004 06:39:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApnGM-0006Tf-00 for sipping@ietf.org; Sun, 08 Feb 2004 06:38:11 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1ApnGG-0006QJ-00 for sipping@ietf.org; Sun, 08 Feb 2004 06:38:04 -0500 Received: from eamrcnt748.exu.ericsson.se (eamrcnt748.exu.ericsson.se [138.85.133.46]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i18BbULc001098 for ; Sun, 8 Feb 2004 05:37:30 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt748.exu.ericsson.se with Microsoft SMTPSVC(5.0.2195.6713); Sun, 8 Feb 2004 05:33:34 -0600 Received: from ericsson.com (rvi2-92-31.sw.ericsson.se [153.88.92.31]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 13CKVSPQ; Sun, 8 Feb 2004 05:37:33 -0600 Message-ID: <40261F7E.9060608@ericsson.com> Date: Sun, 08 Feb 2004 13:37:34 +0200 X-Sybari-Trust: 48f946be 6b512624 7e80e808 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping CC: Rohan Mahy , Dean Willis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Feb 2004 11:33:34.0015 (UTC) FILETIME=[628744F0:01C3EE37] Content-Transfer-Encoding: 7bit Subject: [Sipping] Submissions to SIPPING Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, we are trying to maintain our supplemental page up to date; especially the draft database. So, I would appreciate if you let me know every time you submit an individual contribution to SIPPING (I generally get cc:ed in submissions of WG items). Some of them are not announced in the mailing list, or I may miss the announcement. http://www.softarmor.com/wgdb/?wg=SIPPING We hope that this WG-level ID tracker is useful to the community. Thanks, Gonzalo SIPPING co-chair This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 8 11:46:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23612 for ; Sun, 8 Feb 2004 11:46:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aps3p-0002Am-OQ for sipping-archive@odin.ietf.org; Sun, 08 Feb 2004 11:45:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18GjXHa008348 for sipping-archive@odin.ietf.org; Sun, 8 Feb 2004 11:45:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aps3p-0002AZ-Kk for sipping-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 11:45:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23606 for ; Sun, 8 Feb 2004 11:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aps3o-0004Ph-00 for sipping-web-archive@ietf.org; Sun, 08 Feb 2004 11:45:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aps2m-0004KW-00 for sipping-web-archive@ietf.org; Sun, 08 Feb 2004 11:44:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aps2U-0004Fz-00 for sipping-web-archive@ietf.org; Sun, 08 Feb 2004 11:44:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aps2L-0001yF-6j; Sun, 08 Feb 2004 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aps1h-0001rl-VH for sipping@optimus.ietf.org; Sun, 08 Feb 2004 11:43:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23559 for ; Sun, 8 Feb 2004 11:43:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aps1g-0004Ea-00 for sipping@ietf.org; Sun, 08 Feb 2004 11:43:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aps0n-0004An-00 for sipping@ietf.org; Sun, 08 Feb 2004 11:42:26 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1Aps0G-00046F-00 for sipping@ietf.org; Sun, 08 Feb 2004 11:41:52 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i18GfHh26844; Sun, 8 Feb 2004 08:41:17 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMVZ9TX>; Sun, 8 Feb 2004 10:41:16 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF578FD2@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Gonzalo Camarillo'" , sipping Cc: Rohan Mahy , Dean Willis Subject: RE: [Sipping] Submissions to SIPPING Date: Sun, 8 Feb 2004 10:41:14 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Gonzalo, In response to your point about the usefulness of this information; this information is extremely useful to the community and I really, really appreciate the time and effort that you chairs put into tracking all of this. Thanks, Mary H. Barnes mary.barnes@nortelnetworks.com 972-684-5432 -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] Sent: Sunday, February 08, 2004 5:38 AM To: sipping Cc: Rohan Mahy; Dean Willis Subject: [Sipping] Submissions to SIPPING Folks, we are trying to maintain our supplemental page up to date; especially the draft database. So, I would appreciate if you let me know every time you submit an individual contribution to SIPPING (I generally get cc:ed in submissions of WG items). Some of them are not announced in the mailing list, or I may miss the announcement. http://www.softarmor.com/wgdb/?wg=SIPPING We hope that this WG-level ID tracker is useful to the community. Thanks, Gonzalo SIPPING co-chair This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 8 16:34:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03279 for ; Sun, 8 Feb 2004 16:34:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApwYX-0004H2-7P for sipping-archive@odin.ietf.org; Sun, 08 Feb 2004 16:33:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18LXXTu016422 for sipping-archive@odin.ietf.org; Sun, 8 Feb 2004 16:33:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApwYX-0004Gn-3d for sipping-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 16:33:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03271 for ; Sun, 8 Feb 2004 16:33:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApwYV-0003Nl-00 for sipping-web-archive@ietf.org; Sun, 08 Feb 2004 16:33:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApwXY-0003K0-00 for sipping-web-archive@ietf.org; Sun, 08 Feb 2004 16:32:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApwXF-0003GN-00 for sipping-web-archive@ietf.org; Sun, 08 Feb 2004 16:32:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApwX2-00046y-Uz; Sun, 08 Feb 2004 16:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApwWY-00046Q-Oq for sipping@optimus.ietf.org; Sun, 08 Feb 2004 16:31:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03250 for ; Sun, 8 Feb 2004 16:31:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApwWW-0003Fe-00 for sipping@ietf.org; Sun, 08 Feb 2004 16:31:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApwVZ-0003C3-00 for sipping@ietf.org; Sun, 08 Feb 2004 16:30:30 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1ApwV7-000389-00 for sipping@ietf.org; Sun, 08 Feb 2004 16:30:01 -0500 Received: from eamrcnt748.exu.ericsson.se (eamrcnt748.exu.ericsson.se [138.85.133.46]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i18LTVfX022919 for ; Sun, 8 Feb 2004 15:29:31 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt748.exu.ericsson.se with Microsoft SMTPSVC(5.0.2195.6713); Sun, 8 Feb 2004 15:25:28 -0600 Received: from ericsson.com (rvi2-92-31.sw.ericsson.se [153.88.92.31]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 13CKWR5T; Sun, 8 Feb 2004 15:29:28 -0600 Message-ID: <4026AA39.5050509@ericsson.com> Date: Sun, 08 Feb 2004 23:29:29 +0200 X-Sybari-Trust: 7c78a0d1 6b512624 7e80e808 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping CC: Dean Willis , Rohan Mahy , "James M. Polk" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Feb 2004 21:25:28.0890 (UTC) FILETIME=[130B21A0:01C3EE8A] Content-Transfer-Encoding: 7bit Subject: [Sipping] WGLC for draft-ietf-sipping-reason-header-for-preemption-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, we would like to announce the start of the WGLC for the following draft. http://www.ietf.org/internet-drafts/draft-ietf-sipping-reason-header-for-preemption-00.txt This WGLC will end on Feb 29th. Send your comments to this mailing list and to the author. Thanks, Gonzalo SIPPING co-chair This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 10 07:33:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13901 for ; Tue, 10 Feb 2004 07:33:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqX4L-0006vj-AI for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 07:32:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ACWnl5026633 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 07:32:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqX4L-0006vU-6H for sipping-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 07:32:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13893 for ; Tue, 10 Feb 2004 07:32:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqX4K-0000q5-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 07:32:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqX3S-0000l6-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 07:31:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqX2h-0000fz-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 07:31:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqX2c-0006iT-Gy; Tue, 10 Feb 2004 07:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqX2M-0006h1-QY for sipping@optimus.ietf.org; Tue, 10 Feb 2004 07:30:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13808 for ; Tue, 10 Feb 2004 07:30:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqX2M-0000dZ-00 for sipping@ietf.org; Tue, 10 Feb 2004 07:30:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqX1N-0000XB-00 for sipping@ietf.org; Tue, 10 Feb 2004 07:29:46 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AqX0O-0000NK-00 for sipping@ietf.org; Tue, 10 Feb 2004 07:28:44 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1ACShAh020525 for ; Tue, 10 Feb 2004 13:28:43 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Feb 2004 13:28:43 +0100 Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJTRAW9; Tue, 10 Feb 2004 13:28:43 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.204]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A274C18A82; Tue, 10 Feb 2004 14:28:42 +0200 (EET) Message-ID: <4028CE7A.4050207@ericsson.com> Date: Tue, 10 Feb 2004 14:28:42 +0200 X-Sybari-Trust: 21fa5c1c 91259930 54753a94 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping Cc: Rohan Mahy , Dean Willis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2004 12:28:43.0285 (UTC) FILETIME=[6BD54C50:01C3EFD1] Content-Transfer-Encoding: 7bit Subject: [Sipping] Agenda Requests Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, we will be gathering agenda requests for Seoul under the following link: http://www.softarmor.com/sipping/meets/ietf59/requests.html As usual, if you use the template provided at the end of this email to submit your agenda request , it will make this task easier. Agenda requests are submitted in an email addressed to the chairs. Regarding the requests we will be accepting and rejecting, this time, we intend to use a big part of the meeting to discuss issues related to WG items. We will only discuss individual contributions that have received considerable attention since the last meeting. Gonzalo Camarillo Exploders
5
draft-camarillo-sipping-exploders-02.txt Thanks, Gonzalo SIPPING co-chair This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 10 11:15:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25720 for ; Tue, 10 Feb 2004 11:15:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaXl-0003lj-1i for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 11:15:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AGFPPa014483 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 11:15:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaXk-0003lW-Tu for sipping-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 11:15:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25660 for ; Tue, 10 Feb 2004 11:15:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaXk-0000bo-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 11:15:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaWX-0000VD-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 11:14:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqaVm-0000Oa-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 11:13:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaVO-0003A1-OQ; Tue, 10 Feb 2004 11:12:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaUV-00038w-H4 for sipping@optimus.ietf.org; Tue, 10 Feb 2004 11:12:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25553 for ; Tue, 10 Feb 2004 11:12:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaUU-0000GU-00 for sipping@ietf.org; Tue, 10 Feb 2004 11:12:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaTZ-0000B3-00 for sipping@ietf.org; Tue, 10 Feb 2004 11:11:06 -0500 Received: from natsmtp00.rzone.de ([81.169.145.165] helo=natsmtp00.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 1AqaTD-000051-00 for sipping@ietf.org; Tue, 10 Feb 2004 11:10:43 -0500 Received: from sip (pD9E1033B.dip.t-dialin.net [217.225.3.59]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i1AGAVSD003650; Tue, 10 Feb 2004 17:10:31 +0100 (MET) From: "Christian Stredicke" To: "'Jonathan Rosenberg'" Cc: "'F.S.Salloum'" , , Subject: RE: [Sipping] Music On Hold Date: Tue, 10 Feb 2004 17:10:31 +0100 Message-ID: <02e501c3eff0$68c53510$0a02a8c0@sip> 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.4510 In-Reply-To: <4021F27B.3040007@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jonathan, I wrote something about this topic on http://softarmor.com/wgdb/docs/draft-stredicke-sipping-late-media-01.txt Of course, technically it would be possible to initiate a conference = with 3PCC that mixes billing beeps into the audio stream. Maybe someone can = prove that 3PCC is a Turing-machine; then we can stop the discussion if = something is possible with this model. But I doubt that this will be a big = success. Today I had another discussion with a customer that wanted to know why = music on hold is NOT working with a phone (from a very popular vendor, not us) which is (big surprise) NOT initiating 3PCC MOH. Maybe, again, I am too stupid to see the configuration option in the product of another vendor. Or just use a B2BUA... CS > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf = Of > Jonathan Rosenberg > Sent: Thursday, February 05, 2004 8:36 AM > To: Christian Stredicke > Cc: 'F.S.Salloum'; suhac@ednet.co.uk; sipping@ietf.org > Subject: Re: [Sipping] Re: [Sip] Music On Hold >=20 > inline. >=20 > Christian Stredicke wrote: >=20 >=20 > >>A lot of commercial product also our HW > >>phones(http://netphone.intracom.gr/) > >>support this approach with no problem > >> > > > > [Christian Stredicke] We also support this, but I can't say "no problem". > > It's easy to get it working in the lab, but the real world shows us = a > > different picture. Calls get lost (people just plug the cable), = transfer > > fails, people are sitting behind NAT, media server running out of > resources, > > media server and negotiated codec don't find a common codec (cause = only > the > > answer is available). Maybe is a question of the pain level, but for = us > it's > > a "problem". > > > > Of course, anything can be solved, but what I am trying to say is = the > > Alert-Info model would be much simpler. We could have the same > discussion in > > ring tones!!! >=20 > Its not clear to me that many of the problems you list above would go > away with an Alert-Info style approach. Certainly, those calls can get > lost, there can be nat problems, the server can still run out of > resources, etc. >=20 > You also indicate that there is a problem finding a common codec. Of > course, if there are simply no codecs in common no signaling in the > world will help. However, I don't think thats what you mean. In the = flow > in the service examples draft, the user placing the call on hold > (b-party) issues an invite to the music on hold server with no sdp. = That > triggers the music on hold server to issue an offer with a full codec > list. That is passed to the A-party, which picks the one(s) it wants. > Thus, the music on hold can use different codecs than what is = negotiated > in the call between A and B. So, I dont see a specific problem. Can = you > elaborate on the difficulty you see? >=20 >=20 > >> > >>I think we should consider security issues check this link with a > >>discussions with alert info stuff > >>(http://www.atm.tut.fi/list-archive/sip/msg01278.html) > >> > > > > [Christian Stredicke] There are also (bigger?) security problems = with > the > > 3PCC model. And the Alert-Info security problem has to be solved = anyway > (or > > has been solved already). >=20 > 3pcc in this specific case is not so hard, since (presumably) there is = a > relationship between the b-party and the music on hold server. If the > B-party rather tells the A-party to contact the music on hold server > directly (using an alert-info kind of approach), now there needs to be = a > security relationship between the A-party on the music on hold server, > which doesnt exist. Relaying signaling through the B-party makes the > security more tenable, I think. >=20 > -Jonathan R. >=20 > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 10 13:13:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00742 for ; Tue, 10 Feb 2004 13:13:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcNf-0004x5-EM for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 13:13:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AID71b019031 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 13:13:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcNf-0004ws-AQ for sipping-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 13:13:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00716 for ; Tue, 10 Feb 2004 13:13:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqcNd-0005Eu-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 13:13:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqcMg-00058e-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 13:12:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqcLu-00052s-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 13:11:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcLe-0004gj-L4; Tue, 10 Feb 2004 13:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcKe-0004aZ-EO for sipping@optimus.ietf.org; Tue, 10 Feb 2004 13:10:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00627 for ; Tue, 10 Feb 2004 13:09:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqcKc-0004wO-00 for sipping@ietf.org; Tue, 10 Feb 2004 13:09:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqcJh-0004rn-00 for sipping@ietf.org; Tue, 10 Feb 2004 13:09:01 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AqcJ0-0004hu-00 for sipping@ietf.org; Tue, 10 Feb 2004 13:08:18 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1AI7kuA028933; Tue, 10 Feb 2004 10:07:46 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQD71813; Tue, 10 Feb 2004 10:07:44 -0800 (PST) In-Reply-To: <4028CE7A.4050207@ericsson.com> References: <4028CE7A.4050207@ericsson.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0F085EFB-5BF4-11D8-AEF8-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: sipping , Dean Willis From: Rohan Mahy Subject: Re: [Sipping] more on ... Agenda Requests Date: Tue, 10 Feb 2004 19:07:58 +0100 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A few more things about Agenda Requests. This IETF I will provide a printable, pretty, properly-paginated PDF file of the reading list on softarmor. (Options for 1-up double sided and 2-up double sided for both US-Letter and A4 paper will be available). If you are requesting agenda time, your draft(s) need to be properly formatted (I strongly recommend using xml2rfc). I will send your draft back to you for reformatting if they do not print properly. Also, if you *did* use xml2rfc, please attach a copy of the HTML version in your request. thanks, -rohan On Feb 10, 2004, at 1:28 PM, Gonzalo Camarillo wrote: > Folks, > > we will be gathering agenda requests for Seoul under the following > link: > > http://www.softarmor.com/sipping/meets/ietf59/requests.html > > As usual, if you use the template provided at the end of this email to > submit your agenda request , it will make this task easier. Agenda > requests are submitted in an email addressed to the chairs. > > Regarding the requests we will be accepting and rejecting, this time, > we intend to use a big part of the meeting to discuss issues related > to WG items. We will only discuss individual contributions that have > received considerable attention since the last meeting. > > > > > Gonzalo Camarillo > Exploders >
5
> > href="http://www.ietf.org/internet-drafts/draft-camarillo-sipping- > exploders-02.txt"> > draft-camarillo-sipping-exploders-02.txt > > > > Thanks, > > Gonzalo > SIPPING co-chair > > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we > only send and receive e-mails on the basis that we are not liable for > any such corruption, interception, amendment, tampering or viruses or > any consequences thereof. > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 10 15:23:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09780 for ; Tue, 10 Feb 2004 15:23:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqePV-0001KY-Pw for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 15:23:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AKN9BD005113 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 15:23:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqePV-0001KO-La for sipping-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 15:23:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09463 for ; Tue, 10 Feb 2004 15:23:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqePS-0004H4-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 15:23:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqeOc-0004BH-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 15:22:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqeNi-00043q-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 15:21:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeNT-0000Nm-O8; Tue, 10 Feb 2004 15:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeMi-0008OS-Gd for sipping@optimus.ietf.org; Tue, 10 Feb 2004 15:20:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08432 for ; Tue, 10 Feb 2004 15:20:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqeMh-0003vY-00 for sipping@ietf.org; Tue, 10 Feb 2004 15:20:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqeLr-0003nj-00 for sipping@ietf.org; Tue, 10 Feb 2004 15:19:24 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AqeKq-0003Xr-00 for sipping@ietf.org; Tue, 10 Feb 2004 15:18:21 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1AKHtNr002108; Tue, 10 Feb 2004 15:17:56 -0500 (EST) Message-ID: <40293C6B.4060404@dynamicsoft.com> Date: Tue, 10 Feb 2004 15:17:47 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: sipping@ietf.org Subject: Re: [Sipping] Conference policy URI References: <2038BCC78B1AD641891A0D1AE133DBB701797704@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797704@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for doing this. Some comments. Firstly, on the registry itself. You need to give clearer guidance to IANA on the registry. I would suggest including a table that shows how it should look like. You need to tell IANA what information needs to be provided in future RFCs that register additional values (value, RFC number, registrant, etc.). Please take a look at rfc2434 (ftp://ftp.rfc-editor.org/in-notes/rfc2434.txt). Secondly, on the "policy-uri" value - you need to specify, I think, what the URI type is, and what the content is at that URI (at least a mandatory to implement one) in order to get interoperability. Unlike the other stuff, which is just rendered for user information, this resource is processed by an automata, and I think you need to say more about it. Thanks, Jonathan R. hisham.khartabil@nokia.com wrote: > Thanks Jonathan. A draft has been submitted to the SIP WG. > > http://www.ietf.org/internet-drafts/draft-khartabil-sip-policy-uri-call-info-purpose-00.txt > > Regards, > Hisham > > >>-----Original Message----- >>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: 24.January.2004 04:44 >>To: Khartabil Hisham (Nokia-TP/Helsinki) >>Cc: sipping@ietf.org >>Subject: Re: [Sipping] Conference policy URI >> >> >>I think this is a reasonable usage of Call-Info. However, it can only >>be done if a "purpose" tag value is registered with IANA, as >>indicated >>by section 20.9. However, it ocurred to me, when reading >>this, that we >>never set up an IANA registry for call-info purpose tokens! Oops! >>Thats easily rectifiable; when the draft defining the >>'policy-uri' (or >>whatever its called) purpose tag is written, it should also >>create the >>registry and register the other tokens defined in rfc3261. >> >>-Jonathan R. >> >>hisham.khartabil@nokia.com wrote: >> >> >>>Hi, >>> >>>There was consensus on the XCON mailing list that the conference >>>state event package needs to include in the notification the >>>conference policy URI. >>> >>>There was also consensus that some participants may not want to >>>subscribe to the conference package but would still like to learn >>>the conference policy URI. In this case, it was suggested that the >>>Call-info header carries such information. Perhaps the >>>cc-conferencing draft can include examples of that. >>> >>>Thanks, Hisham >>> >>>_______________________________________________ Sipping mailing >>>list https://www1.ietf.org/mailman/listinfo/sipping This list is >>>for NEW development of the application of SIP Use >>>sip-implementors@cs.columbia.edu for questions on current sip Use >>>sip@ietf.org for new developments of core SIP >>> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 10 16:10:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16091 for ; Tue, 10 Feb 2004 16:10:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf9E-0006xi-TE for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 16:10:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALAOBi026756 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 16:10:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf9E-0006xT-ML for sipping-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:10:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15972 for ; Tue, 10 Feb 2004 16:10:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf9C-0001mJ-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 16:10:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqf89-0001Yd-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 16:09:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf7D-0001PP-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 16:08:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf6y-0005vN-AD; Tue, 10 Feb 2004 16:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf6p-0005sc-D7 for sipping@optimus.ietf.org; Tue, 10 Feb 2004 16:07:55 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15362; Tue, 10 Feb 2004 16:07:52 -0500 (EST) Message-Id: <200402102107.QAA15362@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 10 Feb 2004 16:07:52 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-sos-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Emergency Services URI for the Session Initiation Protocol Author(s) : H. Schulzrinne Filename : draft-ietf-sipping-sos-00.txt Pages : 17 Date : 2004-2-10 As part of an overall architecture for supporting emergency calling for the Session Initiation Protocol (SIP), this document defines universal emergency SIP URIs, sip:sos@domain and sips:sos@domain, that allows SIP user agents to contact the local emergency call center. It also defines conventions that increase the high probability of reaching the appropriate emergency call center. The document does not define any SIP protocol extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-sos-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-sos-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-sos-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-10154944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-sos-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-sos-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10154944.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 10 17:01:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22849 for ; Tue, 10 Feb 2004 17:01:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfwY-0006B4-SU for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 17:01:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AM1MZ7023740 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 17:01:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfwY-0006Ap-Nu for sipping-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 17:01:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22816 for ; Tue, 10 Feb 2004 17:01:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfwW-00040h-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 17:01:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfvK-0003rJ-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 17:00:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqfuP-0003jd-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 16:59:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfuI-0005g3-Nz; Tue, 10 Feb 2004 16:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqftq-0005de-K1 for sipping@optimus.ietf.org; Tue, 10 Feb 2004 16:58:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22412 for ; Tue, 10 Feb 2004 16:58:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqfto-0003bI-00 for sipping@ietf.org; Tue, 10 Feb 2004 16:58:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqfsb-0003NU-00 for sipping@ietf.org; Tue, 10 Feb 2004 16:57:18 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AqfrM-0002xk-00 for sipping@ietf.org; Tue, 10 Feb 2004 16:56:00 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Feb 2004 14:03:35 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1ALtRu5023203 for ; Tue, 10 Feb 2004 13:55:27 -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 NAA07461 for ; Tue, 10 Feb 2004 13:55:27 -0800 (PST) Message-Id: <4.3.2.7.2.20040210153149.02512af8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Feb 2004 15:55:01 -0600 To: sipping@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sipping] Concern within sos ID - user addresses reserved Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I have an concern within the new sos ID, and that concern is in section 4.1 - which reserves the following additional user addresses: sos.fire fire brigade sos.rescue ambulance (rescue) sos.marine marine guard sos.police police (law enforcement) sos.mountain mountain rescue as I have little confidence that Joe Citizen will be generally capable to choose the correct one given their emergency experience. If these addresses are intended for between two ERCs (for a call transfer, for example) - I don't see the text stating that here. My issue is not really with the reservation of the user addresses, but with the lack of semantics and potential drawbacks surrounding using one of these when more than one should have been contacted (that a multipurpose ERC could determine by asking the right questions) or if the wrong one was dispatched because not enough was asked of the person in distress. I think that if Joe Citizen is educated enough to call the *right* response center (say fire vs. mountain rescue) - then I retract this concern cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 10 17:18:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24687 for ; Tue, 10 Feb 2004 17:18:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgCn-0008Ro-T5 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 17:18:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AMI9Gp032466 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 17:18:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgCn-0008RZ-PB for sipping-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 17:18:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24666 for ; Tue, 10 Feb 2004 17:18:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqgCl-0006zU-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 17:18:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgBp-0006sz-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 17:17:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqgAp-0006kJ-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 17:16:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgAk-0007tj-4O; Tue, 10 Feb 2004 17:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqg9s-0007qk-9f for sipping@optimus.ietf.org; Tue, 10 Feb 2004 17:15:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24349 for ; Tue, 10 Feb 2004 17:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqg9p-0006Zo-00 for sipping@ietf.org; Tue, 10 Feb 2004 17:15:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqg8o-0006IL-00 for sipping@ietf.org; Tue, 10 Feb 2004 17:14:03 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1Aqg7R-0005xN-00 for sipping@ietf.org; Tue, 10 Feb 2004 17:12:37 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSC2JRZ>; Tue, 10 Feb 2004 17:12:07 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63DA@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'James M. Polk'" , sipping@ietf.org Subject: RE: [Sipping] Concern within sos ID - user addresses reserved Date: Tue, 10 Feb 2004 17:12:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Suppose that we assume that Joe Citizen is actually pretty good at figuring out what he needs, but isn't always thinking about ancilliary issues, like a big fire requires police to direct traffic, and perhaps ambulances. A fire is a fire. Suppose that he calls "sos.fire" for a fire which: Causes an automatic dispatch to the closest available fire brigade Connects him to the brigade captain Bridges him to an emergency response center operator Joe explains the exact situation. It may be that the call is cancelled. It may be that additional units are needed. It is unlikely that if he calls "sos.fire" that he doesn't need a fire company but does need a mountain rescue team In any jurisdiction, it could easily be arranged that all calls to sos.* are answered at one ERC with a visual indication of what the caller asked for. I don't see a downside, and I see a potential upside. Of course the original idea was that in some jurisdictions, there is no coordinated emergency response center. You HAVE to call the specific service. Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Tuesday, February 10, 2004 4:55 PM > To: sipping@ietf.org > Subject: [Sipping] Concern within sos ID - user addresses reserved > > > I have an concern within the new sos ID, and that concern is > in section 4.1 > - which reserves the following additional user addresses: > > sos.fire fire brigade > sos.rescue ambulance (rescue) > sos.marine marine guard > sos.police police (law enforcement) > sos.mountain mountain rescue > > as I have little confidence that Joe Citizen will be > generally capable to > choose the correct one given their emergency experience. If > these addresses > are intended for between two ERCs (for a call transfer, for > example) - I > don't see the text stating that here. > > My issue is not really with the reservation of the user > addresses, but with > the lack of semantics and potential drawbacks surrounding > using one of > these when more than one should have been contacted (that a > multipurpose > ERC could determine by asking the right questions) or if the > wrong one was > dispatched because not enough was asked of the person in distress. > > I think that if Joe Citizen is educated enough to call the > *right* response > center (say fire vs. mountain rescue) - then I retract this concern > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 10 17:18:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24719 for ; Tue, 10 Feb 2004 17:18:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgCw-0008Sq-Sp for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 17:18:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AMIItn032530 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 17:18:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgCw-0008Sb-Pc for sipping-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 17:18:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24682 for ; Tue, 10 Feb 2004 17:18:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqgCu-00070j-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 17:18:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgC2-0006ux-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 17:17:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqgBh-0006oT-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 17:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgBj-000885-8p; Tue, 10 Feb 2004 17:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgB4-00080n-Oj for sipping@optimus.ietf.org; Tue, 10 Feb 2004 17:16:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24535 for ; Tue, 10 Feb 2004 17:16:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqgB2-0006lr-00 for sipping@ietf.org; Tue, 10 Feb 2004 17:16:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgAC-0006bw-00 for sipping@ietf.org; Tue, 10 Feb 2004 17:15:29 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqg9B-0006HI-00 for sipping@ietf.org; Tue, 10 Feb 2004 17:14:26 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 10 Feb 2004 14:21:21 +0000 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 i1AMDru5012828; Tue, 10 Feb 2004 14:13:54 -0800 (PST) Received: from [10.32.245.153] (stealth-10-32-245-153.cisco.com [10.32.245.153]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMG07941; Tue, 10 Feb 2004 14:13:52 -0800 (PST) Date: Tue, 10 Feb 2004 17:13:52 -0500 From: David Oran To: "James M. Polk" , sipping@ietf.org Subject: Re: [Sipping] Concern within sos ID - user addresses reserved Message-ID: <2147483647.1076433232@[10.32.245.153]> In-Reply-To: <4.3.2.7.2.20040210153149.02512af8@localhost> References: <4.3.2.7.2.20040210153149.02512af8@localhost> X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Tuesday, February 10, 2004 3:55 PM -0600 "James M. Polk" wrote: > I have an concern within the new sos ID, and that concern is in section > 4.1 - which reserves the following additional user addresses: > > sos.fire fire brigade > sos.rescue ambulance (rescue) > sos.marine marine guard > sos.police police (law enforcement) > sos.mountain mountain rescue > > as I have little confidence that Joe Citizen will be generally capable to > choose the correct one given their emergency experience. If these > addresses are intended for between two ERCs (for a call transfer, for > example) - I don't see the text stating that here. > I thought this was just to reflect current practice in places that already have different numbers for the different emergency services. Is your concern that the *current* numbers are understood by joe citizen but these are not? If so, the UA can just do the mapping as it has to do already for 911->sos@domain. > My issue is not really with the reservation of the user addresses, but > with the lack of semantics and potential drawbacks surrounding using one > of these when more than one should have been contacted (that a > multipurpose ERC could determine by asking the right questions) or if the > wrong one was dispatched because not enough was asked of the person in > distress. > If these were all we had and there were no generic sos@domain I think this would be a fairly large concern. Also concerning would be a deployment in a geography that only had the generic sos@domain and there was no AoR mapping of sos.*@domain -> sos@domain. > I think that if Joe Citizen is educated enough to call the *right* > response center (say fire vs. mountain rescue) - then I retract this > concern > I doubt this is a good assumption, but what's the alternative in places that have already decided to have separate AoRs (service codes in PSTN-speak) for separate emergency service classes? Dave. > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 10 17:57:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27798 for ; Tue, 10 Feb 2004 17:57:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgod-0003Nt-0e for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 17:57:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AMvETJ013003 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 17:57:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgoc-0003Ne-SX for sipping-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 17:57:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27724 for ; Tue, 10 Feb 2004 17:57:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgoa-0004R4-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 17:57:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgnY-0004JN-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 17:56:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqgmZ-0004BZ-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 17:55:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgmT-00030i-UI; Tue, 10 Feb 2004 17:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqglj-0002yt-DG for sipping@optimus.ietf.org; Tue, 10 Feb 2004 17:54:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27562 for ; Tue, 10 Feb 2004 17:54:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqglg-000451-00 for sipping@ietf.org; Tue, 10 Feb 2004 17:54:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqgkj-0003z6-00 for sipping@ietf.org; Tue, 10 Feb 2004 17:53:14 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqgk3-0003nb-00 for sipping@ietf.org; Tue, 10 Feb 2004 17:52:31 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Feb 2004 15:00:08 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1AMpxu5022610; Tue, 10 Feb 2004 14:52:00 -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 OAA00965; Tue, 10 Feb 2004 14:51:59 -0800 (PST) Message-Id: <4.3.2.7.2.20040210164701.040bc3a8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Feb 2004 16:52:13 -0600 To: "Rosen, Brian" , sipping@ietf.org From: "James M. Polk" Subject: RE: [Sipping] Concern within sos ID - user addresses reserved In-Reply-To: <313680C9A886D511A06000204840E1CF070B63DA@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Suppose there is a fire on a boat near a harbor - which do you call? But seriously, suppose there is a fire and the fire department is called only. They show up and a person (who set the fire) is there showing his gun. The fire department won't go near that situation until the police show up. This happens in big cities. Should the fire department now place a new call to the police department for each of its sos@fire calls? At 05:12 PM 2/10/2004 -0500, Rosen, Brian wrote: >Suppose that we assume that Joe Citizen is actually pretty good at figuring >out what he needs, but isn't always thinking about ancilliary issues, like >a big fire requires police to direct traffic, and perhaps ambulances. >A fire is a fire. > >Suppose that he calls "sos.fire" for a fire which: > Causes an automatic dispatch to the closest available fire brigade > Connects him to the brigade captain > Bridges him to an emergency response center operator > >Joe explains the exact situation. >It may be that the call is cancelled. >It may be that additional units are needed. >It is unlikely that if he calls "sos.fire" that he doesn't need > a fire company but does need a mountain rescue team > >In any jurisdiction, it could easily be arranged that all calls to sos.* >are answered at one ERC with a visual indication of what the caller asked >for. > >I don't see a downside, and I see a potential upside. > >Of course the original idea was that in some jurisdictions, there is no >coordinated emergency response center. You HAVE to call the specific >service. > >Brian > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Tuesday, February 10, 2004 4:55 PM > > To: sipping@ietf.org > > Subject: [Sipping] Concern within sos ID - user addresses reserved > > > > > > I have an concern within the new sos ID, and that concern is > > in section 4.1 > > - which reserves the following additional user addresses: > > > > sos.fire fire brigade > > sos.rescue ambulance (rescue) > > sos.marine marine guard > > sos.police police (law enforcement) > > sos.mountain mountain rescue > > > > as I have little confidence that Joe Citizen will be > > generally capable to > > choose the correct one given their emergency experience. If > > these addresses > > are intended for between two ERCs (for a call transfer, for > > example) - I > > don't see the text stating that here. > > > > My issue is not really with the reservation of the user > > addresses, but with > > the lack of semantics and potential drawbacks surrounding > > using one of > > these when more than one should have been contacted (that a > > multipurpose > > ERC could determine by asking the right questions) or if the > > wrong one was > > dispatched because not enough was asked of the person in distress. > > > > I think that if Joe Citizen is educated enough to call the > > *right* response > > center (say fire vs. mountain rescue) - then I retract this concern > > > > cheers, > > James > > > > ******************* > > Truth is not to be argued... it is to be presented > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 10 18:05:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28205 for ; Tue, 10 Feb 2004 18:05:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgwO-0006K9-L2 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 18:05:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AN5GqP024306 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 18:05:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgwO-0006JQ-Du for sipping-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 18:05:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28159 for ; Tue, 10 Feb 2004 18:05:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqgwL-0005C5-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 18:05:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgvQ-00056j-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 18:04:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqgvB-00051P-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 18:04:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgvB-0005qv-OT; Tue, 10 Feb 2004 18:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqguN-0005GQ-LC for sipping@optimus.ietf.org; Tue, 10 Feb 2004 18:03:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28022 for ; Tue, 10 Feb 2004 18:03:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqguK-00050g-00 for sipping@ietf.org; Tue, 10 Feb 2004 18:03:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgtR-0004w7-00 for sipping@ietf.org; Tue, 10 Feb 2004 18:02:14 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgsw-0004q4-00 for sipping@ietf.org; Tue, 10 Feb 2004 18:01:42 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSC2KYM>; Tue, 10 Feb 2004 18:01:12 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63DB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'James M. Polk'" , sipping@ietf.org Subject: RE: [Sipping] Concern within sos ID - user addresses reserved Date: Tue, 10 Feb 2004 18:01:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Of course we are speculating. In most coastal areas, fireboats are part of the fire department, and not the coast guard. If you are far enough out to sea, then your location will cause the Coast Guard to respond no matter what. An appropriately smart system would have rules for such things as "do not enter unguarded", and do the right thing. I expect the ERC operator will always answer; the only question is does the responder get going earlier, with the possibility of increased callout cancellations. We'll see. Having it is better than not having it methinks. Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Tuesday, February 10, 2004 5:52 PM > To: Rosen, Brian; sipping@ietf.org > Subject: RE: [Sipping] Concern within sos ID - user addresses reserved > > > Suppose there is a fire on a boat near a harbor - which do you call? > > But seriously, suppose there is a fire and the fire > department is called > only. They show up and a person (who set the fire) is there > showing his > gun. The fire department won't go near that situation until > the police show > up. This happens in big cities. > > Should the fire department now place a new call to the police > department > for each of its sos@fire calls? > > At 05:12 PM 2/10/2004 -0500, Rosen, Brian wrote: > >Suppose that we assume that Joe Citizen is actually pretty > good at figuring > >out what he needs, but isn't always thinking about > ancilliary issues, like > >a big fire requires police to direct traffic, and perhaps ambulances. > >A fire is a fire. > > > >Suppose that he calls "sos.fire" for a fire which: > > Causes an automatic dispatch to the closest > available fire brigade > > Connects him to the brigade captain > > Bridges him to an emergency response center operator > > > >Joe explains the exact situation. > >It may be that the call is cancelled. > >It may be that additional units are needed. > >It is unlikely that if he calls "sos.fire" that he doesn't need > > a fire company but does need a mountain rescue team > > > >In any jurisdiction, it could easily be arranged that all > calls to sos.* > >are answered at one ERC with a visual indication of what the > caller asked > >for. > > > >I don't see a downside, and I see a potential upside. > > > >Of course the original idea was that in some jurisdictions, > there is no > >coordinated emergency response center. You HAVE to call the specific > >service. > > > >Brian > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: Tuesday, February 10, 2004 4:55 PM > > > To: sipping@ietf.org > > > Subject: [Sipping] Concern within sos ID - user addresses reserved > > > > > > > > > I have an concern within the new sos ID, and that concern is > > > in section 4.1 > > > - which reserves the following additional user addresses: > > > > > > sos.fire fire brigade > > > sos.rescue ambulance (rescue) > > > sos.marine marine guard > > > sos.police police (law enforcement) > > > sos.mountain mountain rescue > > > > > > as I have little confidence that Joe Citizen will be > > > generally capable to > > > choose the correct one given their emergency experience. If > > > these addresses > > > are intended for between two ERCs (for a call transfer, for > > > example) - I > > > don't see the text stating that here. > > > > > > My issue is not really with the reservation of the user > > > addresses, but with > > > the lack of semantics and potential drawbacks surrounding > > > using one of > > > these when more than one should have been contacted (that a > > > multipurpose > > > ERC could determine by asking the right questions) or if the > > > wrong one was > > > dispatched because not enough was asked of the person in distress. > > > > > > I think that if Joe Citizen is educated enough to call the > > > *right* response > > > center (say fire vs. mountain rescue) - then I retract > this concern > > > > > > cheers, > > > James > > > > > > ******************* > > > Truth is not to be argued... it is to be > presented > > > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 10 18:15:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29240 for ; Tue, 10 Feb 2004 18:15:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqh6B-0001C1-Qy for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 18:15:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ANFNQI004579 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 18:15:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqh6B-0001Ba-Nb for sipping-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 18:15:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29195 for ; Tue, 10 Feb 2004 18:15:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqh68-00065p-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 18:15:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqh52-000611-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 18:14:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqh4r-0005wJ-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 18:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqh4r-0000cC-Dz; Tue, 10 Feb 2004 18:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqh4C-0000TE-1Z for sipping@optimus.ietf.org; Tue, 10 Feb 2004 18:13:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28917 for ; Tue, 10 Feb 2004 18:13:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqh49-0005vd-00 for sipping@ietf.org; Tue, 10 Feb 2004 18:13:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqh37-0005qX-00 for sipping@ietf.org; Tue, 10 Feb 2004 18:12:14 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Aqh2T-0005fs-00 for sipping@ietf.org; Tue, 10 Feb 2004 18:11:33 -0500 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 i1ANB14U018584; Tue, 10 Feb 2004 15:11:02 -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 PAA07555; Tue, 10 Feb 2004 15:11:00 -0800 (PST) Message-Id: <4.3.2.7.2.20040210170242.041b63d8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Feb 2004 17:11:15 -0600 To: David Oran , sipping@ietf.org From: "James M. Polk" Subject: Re: [Sipping] Concern within sos ID - user addresses reserved In-Reply-To: <2147483647.1076433232@[10.32.245.153]> References: <4.3.2.7.2.20040210153149.02512af8@localhost> <4.3.2.7.2.20040210153149.02512af8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Comments in-line At 05:13 PM 2/10/2004 -0500, David Oran wrote: >--On Tuesday, February 10, 2004 3:55 PM -0600 "James M. Polk" > wrote: > >>I have an concern within the new sos ID, and that concern is in section >>4.1 - which reserves the following additional user addresses: >> >> sos.fire fire brigade >> sos.rescue ambulance (rescue) >> sos.marine marine guard >> sos.police police (law enforcement) >> sos.mountain mountain rescue >> >>as I have little confidence that Joe Citizen will be generally capable to >>choose the correct one given their emergency experience. If these >>addresses are intended for between two ERCs (for a call transfer, for >>example) - I don't see the text stating that here. >I thought this was just to reflect current practice in places that already >have different numbers for the different emergency services. This was not articulated, if intended >Is your concern that the *current* numbers are understood by joe citizen >but these are not? If so, the UA can just do the mapping as it has to do >already for 911->sos@domain. I'm concerned that, for example in the US, that Joe Citizen needs to learn 911 as general purpose, 912 is police, 913 is fire, etc... How is someone to dial into numeric keypad anything other than 911 in the US (and I'm picking on the US here)? >>My issue is not really with the reservation of the user addresses, but >>with the lack of semantics and potential drawbacks surrounding using one >>of these when more than one should have been contacted (that a >>multipurpose ERC could determine by asking the right questions) or if the >>wrong one was dispatched because not enough was asked of the person in >>distress. >If these were all we had and there were no generic sos@domain I think this >would be a fairly large concern. I'm not as much saying that the additional user addresses need necessarily be removed, just would like more usage text on how/when/where this could be used, with a potentially a "pitfall considerations" section for the ramifications of if the wrong organization was contacted and that delayed the proper help... that is, unless I'm the lone voice with this opinion. >Also concerning would be a deployment in a geography that only had the >generic sos@domain and there was no AoR mapping of sos.*@domain -> sos@domain. > >>I think that if Joe Citizen is educated enough to call the *right* >>response center (say fire vs. mountain rescue) - then I retract this >>concern >I doubt this is a good assumption, but what's the alternative in places >that have already decided to have separate AoRs (service codes in >PSTN-speak) for separate emergency service classes? Add the text saying this, and this thread wouldn't have been started.... >Dave. >>cheers, >>James >> >> ******************* >> Truth is not to be argued... it is to be presented >> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP > > > > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 10 18:39:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00282 for ; Tue, 10 Feb 2004 18:39:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqhTR-0004hS-Kz for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 18:39:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ANdPmG018060 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 18:39:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqhTR-0004hD-GS for sipping-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 18:39:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00278 for ; Tue, 10 Feb 2004 18:39:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqhTO-0000ce-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 18:39:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqhSb-0000WX-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 18:38:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqhS6-0000Oo-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 18:38:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqhS5-0004Cl-PW; Tue, 10 Feb 2004 18:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqhRY-00042b-69 for sipping@optimus.ietf.org; Tue, 10 Feb 2004 18:37:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00110 for ; Tue, 10 Feb 2004 18:37:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqhRU-0000Ms-00 for sipping@ietf.org; Tue, 10 Feb 2004 18:37:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqhQV-0000F8-00 for sipping@ietf.org; Tue, 10 Feb 2004 18:36:23 -0500 Received: from mail3.pi.se ([195.7.64.137] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AqhPY-00006O-00 for sipping@ietf.org; Tue, 10 Feb 2004 18:35:24 -0500 Received: from vit (h161n2fls31o265.telia.com [217.208.189.161]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id i1ANXQkd003019; Wed, 11 Feb 2004 00:33:29 +0100 (CET) From: "Gunnar Hellstrom" To: "'Sipping@Ietf. Org'" Date: Wed, 11 Feb 2004 00:35:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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.1165 In-Reply-To: <200402102056.PAA13748@ietf.org> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id i1ANXQkd003019 Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: I-D ACTION:draft-schulzrinne-sipping-emergency-arch-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Henning, I have a couple of small comments to your good emergency access spec. Section 2 Paragraph 7. TDD is a local US name on text telephony. So, replace "TDD text" with "text telephony" Section 10.1 Add detail on the real time text medium Interactive text: RTP according to RFC 2793. Section "Normative References" Add: [RFC2793] Hellstrom, G, "RTP Payload for Text Conversation", RFC 2793, May 2000 -------------------------------------------------------------- Regards Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, February 10, 2004 9:56 PM To: IETF-Announce: Subject: I-D ACTION:draft-schulzrinne-sipping-emergency-arch-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Emergency Services for Internet Telephony Systems Author(s) : H. Schulzrinne, B. Rosen Filename : draft-schulzrinne-sipping-emergency-arch-00.txt Pages : 22 Date : 2004-2-10 Summoning emergency help is a core feature of telephone networks. This document describes how the Session Initiation Protocol (SIP) can be used = to provide advanced emergency services for voice-over-IP (VoIP). The architecture employs standard SIP features and requires no new protocol mechanisms. DNS is used to map civil and geospatial locations to the appropriate emergency call center. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-emergency-a= rch -00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the messag= e. Internet-Drafts are also available by anonymous FTP. Login with the usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schulzrinne-sipping-emergency-arch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schulzrinne-sipping-emergency-arch-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 10 19:57:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06965 for ; Tue, 10 Feb 2004 19:57:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqigr-0001Xs-0d for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 19:57:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B0vKp8005934 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 19:57:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqigq-0001Xd-S1 for sipping-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 19:57:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06836 for ; Tue, 10 Feb 2004 19:57:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqigo-00045X-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 19:57:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqieO-0003Vq-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 19:54:49 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqict-0003BP-05 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 19:53:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqiV5-0005PF-Sf for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 19:45:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqiUx-0000M3-88; Tue, 10 Feb 2004 19:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqiUQ-0000IL-33 for sipping@optimus.ietf.org; Tue, 10 Feb 2004 19:44:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05464 for ; Tue, 10 Feb 2004 19:44:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqiUO-0001sL-00 for sipping@ietf.org; Tue, 10 Feb 2004 19:44:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqiTT-0001iw-00 for sipping@ietf.org; Tue, 10 Feb 2004 19:43:32 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AqiSe-0001UX-00 for sipping@ietf.org; Tue, 10 Feb 2004 19:42:40 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1B0g7D11961 for ; Tue, 10 Feb 2004 18:42:08 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 11 Feb 2004 00:42:06 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00B1B1BEC@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "James M. Polk" , sipping@ietf.org Subject: RE: [Sipping] Concern within sos ID - user addresses reserved Date: Wed, 11 Feb 2004 00:42:05 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Well stop trying to think US. These auxiliary addresses surely only have a direct impact on which to use when there are multiple PSAPs, one for each distinguished entity already. If there is only one general service, then presumably 911 will translate to the general uri rather than any of the specifics, and USA citizen Joe Public will be told to use the general URI in the USA. In countries that use multiple telephone numbers to go to different service PSAPs, then Joe Public will be told the appropriate information, as the same rules will apply for any interservice cooperation where multiple services are needed. After all, we are not defining the emergency services here, only a means of directing a call to an appropriate PSAP, where an existing emergency service methodology already exists. regards Keith > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: 10 February 2004 23:11 > To: David Oran; sipping@ietf.org > Subject: Re: [Sipping] Concern within sos ID - user addresses reserved > > > Comments in-line > > At 05:13 PM 2/10/2004 -0500, David Oran wrote: > > > >--On Tuesday, February 10, 2004 3:55 PM -0600 "James M. Polk" > > wrote: > > > >>I have an concern within the new sos ID, and that concern > is in section > >>4.1 - which reserves the following additional user addresses: > >> > >> sos.fire fire brigade > >> sos.rescue ambulance (rescue) > >> sos.marine marine guard > >> sos.police police (law enforcement) > >> sos.mountain mountain rescue > >> > >>as I have little confidence that Joe Citizen will be > generally capable to > >>choose the correct one given their emergency experience. If these > >>addresses are intended for between two ERCs (for a call > transfer, for > >>example) - I don't see the text stating that here. > >I thought this was just to reflect current practice in > places that already > >have different numbers for the different emergency services. > > This was not articulated, if intended > > >Is your concern that the *current* numbers are understood by > joe citizen > >but these are not? If so, the UA can just do the mapping as > it has to do > >already for 911->sos@domain. > > I'm concerned that, for example in the US, that Joe Citizen > needs to learn > 911 as general purpose, 912 is police, 913 is fire, etc... > > How is someone to dial into numeric keypad anything other > than 911 in the > US (and I'm picking on the US here)? > > > > >>My issue is not really with the reservation of the user > addresses, but > >>with the lack of semantics and potential drawbacks > surrounding using one > >>of these when more than one should have been contacted (that a > >>multipurpose ERC could determine by asking the right > questions) or if the > >>wrong one was dispatched because not enough was asked of > the person in > >>distress. > >If these were all we had and there were no generic > sos@domain I think this > >would be a fairly large concern. > > I'm not as much saying that the additional user addresses > need necessarily > be removed, just would like more usage text on how/when/where > this could be > used, with a potentially a "pitfall considerations" section for the > ramifications of if the wrong organization was contacted and > that delayed > the proper help... that is, unless I'm the lone voice with > this opinion. > > >Also concerning would be a deployment in a geography that > only had the > >generic sos@domain and there was no AoR mapping of > sos.*@domain -> sos@domain. > > > >>I think that if Joe Citizen is educated enough to call the *right* > >>response center (say fire vs. mountain rescue) - then I retract this > >>concern > >I doubt this is a good assumption, but what's the > alternative in places > >that have already decided to have separate AoRs (service codes in > >PSTN-speak) for separate emergency service classes? > > Add the text saying this, and this thread wouldn't have been > started.... > > > >Dave. > >>cheers, > >>James > >> > >> ******************* > >> Truth is not to be argued... it is to be presented > >> > >> > >>_______________________________________________ > >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >>This list is for NEW development of the application of SIP > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > >_______________________________________________ > >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >This list is for NEW development of the application of SIP > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sip@ietf.org for new developments of core SIP > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 10 20:19:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08891 for ; Tue, 10 Feb 2004 20:19:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqj25-0003h1-Rz for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 20:19:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B1JHnF014189 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 20:19:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqj25-0003gm-OM for sipping-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 20:19:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08867 for ; Tue, 10 Feb 2004 20:19:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqj23-0007SQ-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 20:19:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqj1A-0007NM-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 20:18:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqj0t-0007Hn-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 20:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqj0r-0003UI-Nf; Tue, 10 Feb 2004 20:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqj09-0003Pu-82 for sipping@optimus.ietf.org; Tue, 10 Feb 2004 20:17:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08798 for ; Tue, 10 Feb 2004 20:17:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqj07-0007G6-00 for sipping@ietf.org; Tue, 10 Feb 2004 20:17:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqizC-0007AT-00 for sipping@ietf.org; Tue, 10 Feb 2004 20:16:19 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AqiyJ-0006yf-00 for sipping@ietf.org; Tue, 10 Feb 2004 20:15:23 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 10 Feb 2004 17:23:00 +0000 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 i1B1Ep4U014209; Tue, 10 Feb 2004 17:14:51 -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 RAA01930; Tue, 10 Feb 2004 17:14:50 -0800 (PST) Message-Id: <4.3.2.7.2.20040210191248.03eb4e28@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Feb 2004 19:15:04 -0600 To: "Drage, Keith (Keith)" , sipping@ietf.org From: "James M. Polk" Subject: RE: [Sipping] Concern within sos ID - user addresses reserved In-Reply-To: <475FF955A05DD411980D00508B6D5FB00B1B1BEC@en0033exch001u.uk .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 12:42 AM 2/11/2004 +0000, Drage, Keith (Keith) wrote: >Well stop trying to think US. sorry ;-) >These auxiliary addresses surely only have a direct impact on which to use >when there are multiple PSAPs, one for each distinguished entity already. for sure >If there is only one general service, then presumably 911 will translate >to the general uri rather than any of the specifics, and USA citizen Joe >Public will be told to use the general URI in the USA. I agree >In countries that use multiple telephone numbers to go to different >service PSAPs, then Joe Public will be told the appropriate information, >as the same rules will apply for any interservice cooperation where >multiple services are needed. true enough >After all, we are not defining the emergency services here, only a means >of directing a call to an appropriate PSAP, where an existing emergency >service methodology already exists. I guess then I just want some text that gives the above (most of what you wrote) as explanation. I am willing to "send text" here. >regards > >Keith > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: 10 February 2004 23:11 > > To: David Oran; sipping@ietf.org > > Subject: Re: [Sipping] Concern within sos ID - user addresses reserved > > > > > > Comments in-line > > > > At 05:13 PM 2/10/2004 -0500, David Oran wrote: > > > > > > >--On Tuesday, February 10, 2004 3:55 PM -0600 "James M. Polk" > > > wrote: > > > > > >>I have an concern within the new sos ID, and that concern > > is in section > > >>4.1 - which reserves the following additional user addresses: > > >> > > >> sos.fire fire brigade > > >> sos.rescue ambulance (rescue) > > >> sos.marine marine guard > > >> sos.police police (law enforcement) > > >> sos.mountain mountain rescue > > >> > > >>as I have little confidence that Joe Citizen will be > > generally capable to > > >>choose the correct one given their emergency experience. If these > > >>addresses are intended for between two ERCs (for a call > > transfer, for > > >>example) - I don't see the text stating that here. > > >I thought this was just to reflect current practice in > > places that already > > >have different numbers for the different emergency services. > > > > This was not articulated, if intended > > > > >Is your concern that the *current* numbers are understood by > > joe citizen > > >but these are not? If so, the UA can just do the mapping as > > it has to do > > >already for 911->sos@domain. > > > > I'm concerned that, for example in the US, that Joe Citizen > > needs to learn > > 911 as general purpose, 912 is police, 913 is fire, etc... > > > > How is someone to dial into numeric keypad anything other > > than 911 in the > > US (and I'm picking on the US here)? > > > > > > > > >>My issue is not really with the reservation of the user > > addresses, but > > >>with the lack of semantics and potential drawbacks > > surrounding using one > > >>of these when more than one should have been contacted (that a > > >>multipurpose ERC could determine by asking the right > > questions) or if the > > >>wrong one was dispatched because not enough was asked of > > the person in > > >>distress. > > >If these were all we had and there were no generic > > sos@domain I think this > > >would be a fairly large concern. > > > > I'm not as much saying that the additional user addresses > > need necessarily > > be removed, just would like more usage text on how/when/where > > this could be > > used, with a potentially a "pitfall considerations" section for the > > ramifications of if the wrong organization was contacted and > > that delayed > > the proper help... that is, unless I'm the lone voice with > > this opinion. > > > > >Also concerning would be a deployment in a geography that > > only had the > > >generic sos@domain and there was no AoR mapping of > > sos.*@domain -> sos@domain. > > > > > >>I think that if Joe Citizen is educated enough to call the *right* > > >>response center (say fire vs. mountain rescue) - then I retract this > > >>concern > > >I doubt this is a good assumption, but what's the > > alternative in places > > >that have already decided to have separate AoRs (service codes in > > >PSTN-speak) for separate emergency service classes? > > > > Add the text saying this, and this thread wouldn't have been > > started.... > > > > > > >Dave. > > >>cheers, > > >>James > > >> > > >> ******************* > > >> Truth is not to be argued... it is to be presented > > >> > > >> > > >>_______________________________________________ > > >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > >>This list is for NEW development of the application of SIP > > >>Use sip-implementors@cs.columbia.edu for questions on current sip > > >>Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > > > > > >_______________________________________________ > > >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > >This list is for NEW development of the application of SIP > > >Use sip-implementors@cs.columbia.edu for questions on current sip > > >Use sip@ietf.org for new developments of core SIP > > > > > > cheers, > > James > > > > ******************* > > Truth is not to be argued... it is to be presented > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 10 23:10:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16187 for ; Tue, 10 Feb 2004 23:10:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqlgv-0007SY-Qf for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 23:09:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B49bmp028659 for sipping-archive@odin.ietf.org; Tue, 10 Feb 2004 23:09:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqlgv-0007Rs-4q for sipping-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 23:09:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16145 for ; Tue, 10 Feb 2004 23:09:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqlgq-0003Ze-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 23:09:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqlfc-0003Qa-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 23:08:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqleS-0003I6-00 for sipping-web-archive@ietf.org; Tue, 10 Feb 2004 23:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqleP-0006u4-OJ; Tue, 10 Feb 2004 23:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqldv-0006t4-Ki for sipping@optimus.ietf.org; Tue, 10 Feb 2004 23:06:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16071 for ; Tue, 10 Feb 2004 23:06:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqldq-0003H3-00 for sipping@ietf.org; Tue, 10 Feb 2004 23:06:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqlcv-0003BV-00 for sipping@ietf.org; Tue, 10 Feb 2004 23:05:30 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Aqlbu-00035R-00 for sipping@ietf.org; Tue, 10 Feb 2004 23:04:26 -0500 Received: from bear.cs.columbia.edu (IDENT:+JhpLm5FMlM9y2IhrfhLBOMWRgm0t9MN@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1B44Nwo026168 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 10 Feb 2004 23:04:23 -0500 (EST) Received: from cs.columbia.edu (pool-141-153-198-80.mad.east.verizon.net [141.153.198.80]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1B44Mmi024088 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Feb 2004 23:04:23 -0500 Message-ID: <4029A9BE.3040603@cs.columbia.edu> Date: Tue, 10 Feb 2004 23:04:14 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: "James M. Polk" CC: David Oran , sipping@ietf.org Subject: Re: [Sipping] Concern within sos ID - user addresses reserved References: <4.3.2.7.2.20040210153149.02512af8@localhost> <4.3.2.7.2.20040210153149.02512af8@localhost> <4.3.2.7.2.20040210170242.041b63d8@localhost> In-Reply-To: <4.3.2.7.2.20040210170242.041b63d8@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > This was not articulated, if intended I added This convention is not meant to encourage end users to select emergency services where a uniform ECC address for all such services exist. Rather, these identifiers reflect current practice in jurisdictions that already have different numbers for the different emergency services. Hope that helps. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 09:53:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03117 for ; Wed, 11 Feb 2004 09:53:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqvjO-0008CC-E2 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 09:52:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BEqo5K031505 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 09:52:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqvjN-0008C4-PT for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 09:52:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03089 for ; Wed, 11 Feb 2004 09:52:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqvjL-00049i-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 09:52:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqviL-00043q-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 09:51:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqvhl-0003yF-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 09:51:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqvhe-00080z-NI; Wed, 11 Feb 2004 09:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqvhP-0007yh-3P for sipping@optimus.ietf.org; Wed, 11 Feb 2004 09:50:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03014 for ; Wed, 11 Feb 2004 09:50:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqvhN-0003xZ-00 for sipping@ietf.org; Wed, 11 Feb 2004 09:50:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqvgU-0003sJ-00 for sipping@ietf.org; Wed, 11 Feb 2004 09:49:51 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1Aqvg3-0003m0-00 for sipping@ietf.org; Wed, 11 Feb 2004 09:49:23 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSC2Z03>; Wed, 11 Feb 2004 09:48:53 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63E0@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sipping@ietf.org'" Date: Wed, 11 Feb 2004 09:48:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] New ID on Emergency Calling Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This draft is proposed as part of how emergency calls will be routed. It explains how you find the appropriate Emergency Response Center, and how you convert geo to civil for dispatch. Probably, this will be pursued in DNSEXT, but comments on sipping are appropriate with respect to how the draft solves the problem. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Emergency Call Information in the Domain Name System Author(s) : B. Rosen Filename : draft-rosen-dns-sos-00.txt Pages : 20 Date : 2004-2-10 Location of a caller is essential to processing an emergency call. Location is needed to correctly route the call, and to correctly dispatch help to the right place. Location can be specified in geographic (lat/lon/altitude) or civil (country/provin ce/city/ street/floor/room) forms. Determining which Emergency Response Center (ERC) should receive the call requires comparing the callers location to a service area boundary description, which may require location in geo form. Dispatching a call generally requires a civil location. There is a need for a way to translate a civil to a geo or vice versa to the resolution of a room. There is also a need to publish the service area boundary of the ERC and the emergency responders. Further, there is a need for a database of legal civil addresses (sometimes called a Master Street Address Guide) that civil locations may be verified against to assure correctness, and uniformity of naming so that dispatch is accurate. The memo proposes a new DDDS application and a new POLY RR to assist emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 10:50:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06109 for ; Wed, 11 Feb 2004 10:50:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqwca-0001n5-LP for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 10:49:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BFnqq7006884 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 10:49:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqwca-0001mx-E0 for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 10:49:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06088 for ; Wed, 11 Feb 2004 10:49:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqwcX-0001zH-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 10:49:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqwbh-0001sK-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 10:48:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqwao-0001lf-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 10:48:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqwam-0001UF-QD; Wed, 11 Feb 2004 10:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqwab-0001Th-Ro for sipping@optimus.ietf.org; Wed, 11 Feb 2004 10:47:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06023 for ; Wed, 11 Feb 2004 10:47:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqwaZ-0001kN-00 for sipping@ietf.org; Wed, 11 Feb 2004 10:47:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqwZl-0001eW-00 for sipping@ietf.org; Wed, 11 Feb 2004 10:46:58 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1AqwYs-0001QB-00 for sipping@ietf.org; Wed, 11 Feb 2004 10:46:02 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 11 Feb 2004 07:44:02 -0800 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 i1BFjUT4015603 for ; Wed, 11 Feb 2004 10:45:30 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-118.cisco.com [64.100.229.118]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AWX56848; Wed, 11 Feb 2004 07:45:29 -0800 (PST) Message-Id: <4.3.2.7.2.20040211103340.00b312c0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Feb 2004 10:45:29 -0500 To: sipping@ietf.org From: Michael Hammer Subject: Re: [Sipping] Concern within sos ID - user addresses reserved In-Reply-To: <4.3.2.7.2.20040210153149.02512af8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 03:55 PM 2/10/2004 -0600, James M. Polk wrote: > sos.fire fire brigade > sos.rescue ambulance (rescue) > sos.marine marine guard > sos.police police (law enforcement) > sos.mountain mountain rescue The second sub-address seems vague to me. Rescue could mean many things. Perhaps, I need to be rescued from a fashion emergency. :) Would something like: sos.medic medical (doctor, nurse, paramedic team) be more descriptive? Also, with respect to registrations, I could see commercial interests wanting to get into the act, such as an sos.fashion that I hinted at above. Is there some guidance necessary to IANA? Do we expect that the IETF WGs will act as arbiters for this? Second, wrt location information reporting, is there any need for a convention for providing a URL to which a receiving ECC can SUBSCRIBE to get location updates from either the UA or a network element that is doing triangulation. I am wondering if something like the following can be inserted into the emergency INVITE: Call-Info: ;purpose=location Mike _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 11:28:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07886 for ; Wed, 11 Feb 2004 11:28:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxDz-0004zB-Bl for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 11:28:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BGSV57019159 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 11:28:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxDz-0004yw-6J for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 11:28:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07746 for ; Wed, 11 Feb 2004 11:28:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxDx-0006Yp-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:28:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxBj-00066a-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:26:13 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqxAX-0005vs-02 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:24:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aqx5t-0002em-9w for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:20:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqx5o-0004LO-Hk; Wed, 11 Feb 2004 11:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqx5I-0004GK-M9 for sipping@optimus.ietf.org; Wed, 11 Feb 2004 11:19:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07186 for ; Wed, 11 Feb 2004 11:19:30 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqx5H-0005Gz-00 for sipping@ietf.org; Wed, 11 Feb 2004 11:19:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqx3Z-000527-00 for sipping@ietf.org; Wed, 11 Feb 2004 11:17:47 -0500 Received: from imo-m28.mx.aol.com ([64.12.137.9]) by ietf-mx with esmtp (Exim 4.12) id 1Aqx2W-0004nt-00 for sipping@ietf.org; Wed, 11 Feb 2004 11:16:40 -0500 Received: from Mpierce1@aol.com by imo-m28.mx.aol.com (mail_out_v36_r4.12.) id c.1e7.19440e19 (4196); Wed, 11 Feb 2004 11:15:56 -0500 (EST) Message-ID: <1e7.19440e19.2d5baf3c@aol.com> Date: Wed, 11 Feb 2004 11:15:56 EST Subject: [Sipping] Other concerns within sos ID To: oran@cisco.com, jmpolk@cisco.com, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1e7.19440e19.2d5baf3c_boundary" X-Mailer: 6.0 for Windows XP sub 51 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 --part1_1e7.19440e19.2d5baf3c_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/10/2004 5:18:03 PM Eastern Standard Time, oran@cisco.com writes: > --On Tuesday, February 10, 2004 3:55 PM -0600 "James M. Polk" > wrote: > > > I have an concern within the new sos ID, and that concern is in section > > 4.1 - which reserves the following additional user addresses: > > > > sos.fire fire brigade > > sos.rescue ambulance (rescue) > > sos.marine marine guard > > sos.police police (law enforcement) > > sos.mountain mountain rescue > > > > as I have little confidence that Joe Citizen will be generally capable to > > choose the correct one given their emergency experience. If these > > addresses are intended for between two ERCs (for a call transfer, for > > example) - I don't see the text stating that here. > > > I thought this was just to reflect current practice in places that already > have different numbers for the different emergency services. Is your > concern that the *current* numbers are understood by joe citizen but these > are not? If so, the UA can just do the mapping as it has to do already for > 911->sos@domain. > So, where in the world are different numbers used to access these different emergency services? Not in the US where we use English. If they are used in some other country, then why aren't the "reserved" user addresses in the language of that country? Joe Citizen may be able to choose the correct one, but I don't think Heinrich Staatsangehoeriger or Pierre citoyen should be expected to choose the correct English word. We have to stop relying on English for everything. My major concern with this whole plan is the presumption that the user's terminal would be able to figure out to use the SOS URI as well as the sub-address based on the number the person dials. There are fundamental, unanswered questions regarding if and how the terminal would know the local dialing plan. Further, I have a serious concern with the desciption in 4.2 that a terminal must recognize many different digits strings and generate an SOS, independent of where it is located, if it "has no knowledge of local emergency numbers". This would result in many invalid calls to an emergency center, since many of these numbers could be valid (non-emergency) numbers (see note about 118 in Finland). Again, this relates to the question of how the terminal knows the local dial plan. Unless a method can be defined so that a terminal generates an SOS only for the specific emergency number or numbers valid for the place it is physically located (or for the place that the user thinks they are in, that is, their virtual location), this entire scheme is faulty and can not be used. Section 6 covers the issue of Identifying the Local Emergency Number. There should be a statement that some method of doing this identification is required, or else the terminal can not generate an SOS based on dialed numbers. (Note the statement in Section 9 about being able to "clearly and unambiguously identity emergency calls".) The 3rd requirement (in Section 3) is incorrect. When someone is travelling, and getting service in a foreign country, there is no requirement that they be able to dial their "familiar" home emergency identifier (presuming this refers to the emergency "number"). This is contradictory in many places. As noted, 118 is directory assistance in Finland and a "familiar" emergency number elsewhere. This case is proof that this requirement is impossible to meet. On the other hand, if a person is travelling and getting service from their proxy back at the company office, they can't expect to get any emergency service from that proxy. The 4th requirement is misleading. It is not acceptable to have "restricted functionality" regarding access to emergency services due to user agents not being aware of this document. There is clearly "restricted functionality" concerning generation of the SOS URI, but that does not need to be stated. The final sentence should state: "User agents conforming to the SIP specification [RFC3261], but unaware of this document, must be able to place emergency calls without any restriction using entry of normal emergency numbers, although they will not generate the SOS URI." The following requirement is missing: "It MUST be possible for a user of a SIP device to dial a local emergency number in the normal manner and properly reach the emergency service." The statement in Section 5 that an "outbound proxy server MUST recognize all local emergency numbers ..." is incorrect (and impossible). (Possibly this sentence was meant to say " ... all local emergency numbers listed in Section 4.2...", but this is still impossible). An outbound proxy only needs to recognize those emergency numbers applicable to the local areas for which it is providing service. An outbound proxy located in and providing service for callers in the US certainly does not have to recognize the emergency number used in some country in Africa. A visitor from that country must dial 911 for an emergency if they are in the US and receiving service from a service provider in the US. If the person from Africa is travelling in Asia and uses the proxy in the US for service, they can't expect it to correctly handle emergency service. The proxy could not possibly distinguish between the emergency numbers for Asia, Africa, US, and all the other local dialing plans that the user might know about. This is an application that must be limited to entry of E.164 numbers (which does not include any emergency numbers or local dialing plans). Further, in Section 5, it is unclear how to interpret the phrase "as well as the tel URIs enumerated in Section Section 4.2" (as a requirement). Section 4.2 listed two tel URIs (911 and 112) as examples ("such as"), not as an exhaustive list. Did this intend to say "as well as tel URIs formed from all the emergency numbers enumerated in the first paragraph of Section 4.2"? The Security Considerations in Section 9 has several problems. Emergency calls are not more sensitive than normal calls, so do not have a greater need for confidentiality. If "sips" itself may "cause the call to fail", then it can not be used. The requirement for the user agent to "reveal a different amount of information to the callee when making an emergency call" also applies to those calls dialed with the traditional emergency number when the user agent does not know the dial plan and therefore can not "clearly and unambiguously identity emergency calls". This function of revealing information must be possible without the SOS mechanism. If based on the SOS capability, then this makes it even more important for the user agent to correctly identify emergency calls (and not mistakenly trigger off of numbers assigned as emergency in other countries). Conclusion: The draft needs to make it clear how the SOS uri can be used in specific 3 cases: 1. User dials the traditional emergency number, the terminal recognizes it, and send the SOS URI. 2. User enter the SOS uri directly (types on a keyboard). 3. User presses a button or icon that causes the appropriate SOS URI to be sent. and cannot be used in the following case: 4. User dials the traditional emergency number, the terminal does not recognize it, and does not send the SOS URI. Case 1 can only occur if the terminal knows the "local" dial plan. ("Local" is with respect to where the user perceives they are getting service from.) Case 2 requires support for the local language. Case 3 is a machine-to-machine communication and does not require recognizable words. It can use the reserved English words since no foreign speaker sees them. Case 4 is used when the terminal does not know the local dial plan. It depends on a proxy to interpret the number, just as for any other dialed number. Mike Pierce Artel --part1_1e7.19440e19.2d5baf3c_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/10/2004 5:18:03 PM Eastern Standard Time, oran@cisco.com writes:


--On Tuesday, February 10,=20= 2004 3:55 PM -0600 "James M. Polk"=20
<jmpolk@cisco.com> wrote:

> I have an concern within the new sos ID, and that concern is in sec= tion
> 4.1 - which reserves the following additional user addresses:
>
>     sos.fire    fire brigade
>     sos.rescue    ambulance (res= cue)
>     sos.marine    marine guard
>     sos.police    police (law en= forcement)
>     sos.mountain     mounta= in rescue
>
> as I have little confidence that Joe Citizen will be generally capa= ble to
> choose the correct one given their emergency experience. If these
> addresses are intended for between two ERCs (for a call transfer, f= or
> example) - I don't see the text stating that here.
>
I thought this was just to reflect current practice in places that alrea= dy=20
have different numbers for the different emergency services. Is your=20
concern that the *current* numbers are understood by joe citizen but the= se=20
are not? If so, the UA can just do the mapping as it has to do already f= or=20
911->sos@domain.




So, where in the world are different numbers used to access these differ= ent emergency services? Not in the US where we use English. If they are used= in some other country, then why aren't the "reserved" user addresses in the= language of that country? Joe Citizen may be able to choose the correct one= , but I don't think Heinrich Staatsangehoeriger or Pierre citoyen should be=20= expected to choose the correct English word. We have to stop relying on Engl= ish for everything.

My major concern with this whole plan is the presumption that the user's= terminal would be able to figure out to use the SOS URI as well as the sub-= address based on the number the person dials. There are fundamental, unanswe= red questions regarding if and how the terminal would know the local dialing= plan.

Further, I have a serious concern with the desciption in 4.2 that a term= inal must recognize many different digits strings and generate an SOS, indep= endent of where it is located, if it "has no knowledge of local emergency nu= mbers". This would result in many invalid calls to an emergency center, sinc= e many of these numbers could be valid (non-emergency) numbers (see note abo= ut 118 in Finland). Again, this relates to the question of how the terminal=20= knows the local dial plan. Unless a method can be defined so that a terminal= generates an SOS only for the specific emergency number or numbers valid fo= r the place it is physically located (or for the place that the user thinks=20= they are in, that is, their virtual location), this entire scheme is faulty=20= and can not be used. Section 6 covers the issue of Identifying the Local Eme= rgency Number. There should be a statement that some method of doing this id= entification is required, or else the terminal can not generate an SOS based= on dialed numbers. (Note the statement in Section 9 about being able to "cl= early and unambiguously identity emergency calls".)

The 3rd requirement (in Section 3) is incorrect. When someone is travell= ing, and getting service in a foreign country, there is no requirement that=20= they be able to dial their "familiar" home emergency identifier (presuming t= his refers to the emergency "number"). This is contradictory in many places.= As noted, 118 is directory assistance in Finland and a "familiar" emergency= number elsewhere. This case is proof that this requirement is impossible to= meet.

On the other hand, if a person is travelling and getting service from th= eir proxy back at the company office, they can't expect to get any emergency= service from that proxy.

The 4th requirement is misleading. It is not acceptable to have "restric= ted functionality" regarding access to emergency services due to user agents= not being aware of this document. There is clearly "restricted functionalit= y" concerning generation of the SOS URI, but that does not need to be stated= . The final sentence should state: "User agents conforming to the SIP specif= ication [RFC3261], but unaware of this document, must be able to place emerg= ency calls without any restriction using entry of normal emergency numbers,=20= although they will not generate the SOS URI."

The following requirement is missing: "It MUST be possible for a user of= a SIP device to dial a local emergency number in the normal manner and prop= erly reach the emergency service."

The statement in Section 5 that an "outbound proxy server MUST recognize= all local emergency numbers ..." is incorrect (and impossible). (Possibly t= his sentence was meant to say " ... all local emergency numbers listed in Se= ction 4.2...", but this is still impossible). An outbound proxy only needs t= o recognize those emergency numbers applicable to the local areas for which=20= it is providing service. An outbound proxy located in and providing service=20= for callers in the US certainly does not have to recognize the emergency num= ber used in some country in Africa. A visitor from that country must dial 91= 1 for an emergency if they are in the US and receiving service from a servic= e provider in the US. If the person from Africa is travelling in Asia and us= es the proxy in the US for service, they can't expect it to correctly handle= emergency service. The proxy could not possibly distinguish between the eme= rgency numbers for Asia, Africa, US, and all the other local dialing plans t= hat the user might know about. This is an application that must be limited t= o entry of E.164 numbers (which does not include any emergency numbers or lo= cal dialing plans).

Further, in Section 5, it is unclear how to interpret the phrase "as wel= l as the tel URIs enumerated in Section Section 4.2" (as a requirement). Sec= tion 4.2 listed two tel URIs (911 and 112) as examples ("such as"), not as a= n exhaustive list. Did this intend to say "as well as tel URIs formed from a= ll the emergency numbers enumerated in the first paragraph of Section 4.2"?

The Security Considerations in Section 9 has several problems. Emergency= calls are not more sensitive than normal calls, so do not have a greater ne= ed for confidentiality. If "sips" itself may "cause the call to fail", then=20= it can not be used.

The requirement for the user agent to "reveal a different amount of info= rmation to the callee when making an emergency call" also applies to those c= alls dialed with the traditional emergency number when the user agent does n= ot know the dial plan and therefore can not "clearly and unambiguously ident= ity emergency calls". This function of revealing information must be possibl= e without the SOS mechanism. If based on the SOS capability, then this makes= it even more important for the user agent to correctly identify emergency c= alls (and not mistakenly trigger off of numbers assigned as emergency in oth= er countries).

Conclusion:

The draft needs to make it clear how the SOS uri can be used in specific= 3 cases:

1. User dials the traditional emergency number, the terminal recognizes=20= it, and send the SOS URI.
2. User enter the SOS uri directly (types on a keyboard).
3. User presses a button or icon that causes the appropriate SOS URI to=20= be sent.

and cannot be used in the following case:

4. User dials the traditional emergency number, the terminal does not re= cognize it, and does not send the SOS URI.

Case 1 can only occur if the terminal knows the "local" dial plan. ("Loc= al" is with respect to where the user perceives they are getting service fro= m.)
Case 2 requires support for the local language.
Case 3 is a machine-to-machine communication and does not require recogn= izable words. It can use the reserved English words since no foreign speaker= sees them.
Case 4 is used when the terminal does not know the local dial plan. It d= epends on a proxy to interpret the number, just as for any other dialed numb= er.

Mike Pierce
Artel

--part1_1e7.19440e19.2d5baf3c_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 11:29:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07961 for ; Wed, 11 Feb 2004 11:29:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxE9-00050u-Ja for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 11:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BGSfRh019266 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 11:28:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxE9-00050f-FA for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 11:28:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07797 for ; Wed, 11 Feb 2004 11:28:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxE8-0006ap-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:28:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxC0-00069G-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:26:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqxAc-0005vs-01 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:25:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aqx2y-0002ch-H7 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:17:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqx2s-0003zx-O6; Wed, 11 Feb 2004 11:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqx2a-0003yA-C0 for sipping@optimus.ietf.org; Wed, 11 Feb 2004 11:16:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07027 for ; Wed, 11 Feb 2004 11:16:42 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqx2Z-0004sp-00 for sipping@ietf.org; Wed, 11 Feb 2004 11:16:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqx1Z-0004lH-00 for sipping@ietf.org; Wed, 11 Feb 2004 11:15:43 -0500 Received: from imo-r02.mx.aol.com ([152.163.225.98]) by ietf-mx with esmtp (Exim 4.12) id 1Aqx0c-0004bb-00 for sipping@ietf.org; Wed, 11 Feb 2004 11:14:42 -0500 Received: from Mpierce1@aol.com by imo-r02.mx.aol.com (mail_out_v36_r4.12.) id c.4f.3a2f7b25 (4426); Wed, 11 Feb 2004 11:13:55 -0500 (EST) Message-ID: <4f.3a2f7b25.2d5baec3@aol.com> Date: Wed, 11 Feb 2004 11:13:55 EST Subject: [Sipping] Other concerns within sos ID To: oran@cisco.com, jmpolk@cisco.com, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_4f.3a2f7b25.2d5baec3_boundary" X-Mailer: 6.0 for Windows XP sub 51 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 --part1_4f.3a2f7b25.2d5baec3_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/10/2004 5:18:03 PM Eastern Standard Time, oran@cisco.com writes: > --On Tuesday, February 10, 2004 3:55 PM -0600 "James M. Polk" > wrote: > > > I have an concern within the new sos ID, and that concern is in section > > 4.1 - which reserves the following additional user addresses: > > > > sos.fire fire brigade > > sos.rescue ambulance (rescue) > > sos.marine marine guard > > sos.police police (law enforcement) > > sos.mountain mountain rescue > > > > as I have little confidence that Joe Citizen will be generally capable to > > choose the correct one given their emergency experience. If these > > addresses are intended for between two ERCs (for a call transfer, for > > example) - I don't see the text stating that here. > > > I thought this was just to reflect current practice in places that already > have different numbers for the different emergency services. Is your > concern that the *current* numbers are understood by joe citizen but these > are not? If so, the UA can just do the mapping as it has to do already for > 911->sos@domain. > So, where in the world are different numbers used to access these different emergency services? Not in the US where we use English. If they are used in some other country, then why aren't the "reserved" user addresses in the language of that country? Joe Citizen may be able to choose the correct one, but I don't think Heinrich Staatsangehoeriger or Pierre citoyen should be expected to choose the correct English word. We have to stop relying on English for everything. My major concern with this whole plan is the presumption that the user's terminal would be able to figure out to use the SOS URI as well as the sub-address based on the number the person dials. There are fundamental, unanswered questions regarding if and how the terminal would know the local dialing plan. Further, I have a serious concern with the desciption in 4.2 that a terminal must recognize many different digits strings and generate an SOS, independent of where it is located, if it "has no knowledge of local emergency numbers". This would result in many invalid calls to an emergency center, since many of these numbers could be valid (non-emergency) numbers (see note about 118 in Finland). Again, this relates to the question of how the terminal knows the local dial plan. Unless a method can be defined so that a terminal generates an SOS only for the specific emergency number or numbers valid for the place it is physically located (or for the place that the user thinks they are in, that is, their virtual location), this entire scheme is faulty and can not be used. Section 6 covers the issue of Identifying the Local Emergency Number. There should be a statement that some method of doing this identification is required, or else the terminal can not generate an SOS based on dialed numbers. (Note the statement in Section 9 about being able to "clearly and unambiguously identity emergency calls".) The 3rd requirement (in Section 3) is incorrect. When someone is travelling, and getting service in a foreign country, there is no requirement that they be able to dial their "familiar" home emergency identifier (presuming this refers to the emergency "number"). This is contradictory in many places. As noted, 118 is directory assistance in Finland and a "familiar" emergency number elsewhere. This case is proof that this requirement is impossible to meet. On the other hand, if a person is travelling and getting service from their proxy back at the company office, they can't expect to get any emergency service from that proxy. The 4th requirement is misleading. It is not acceptable to have "restricted functionality" regarding access to emergency services due to user agents not being aware of this document. There is clearly "restricted functionality" concerning generation of the SOS URI, but that does not need to be stated. The final sentence should state: "User agents conforming to the SIP specification [RFC3261], but unaware of this document, must be able to place emergency calls without any restriction using entry of normal emergency numbers, although they will not generate the SOS URI." The following requirement is missing: "It MUST be possible for a user of a SIP device to dial a local emergency number in the normal manner and properly reach the emergency service." The statement in Section 5 that an "outbound proxy server MUST recognize all local emergency numbers ..." is incorrect (and impossible). (Possibly this sentence was meant to say " ... all local emergency numbers listed in Section 4.2...", but this is still impossible). An outbound proxy only needs to recognize those emergency numbers applicable to the local areas for which it is providing service. An outbound proxy located in and providing service for callers in the US certainly does not have to recognize the emergency number used in some country in Africa. A visitor from that country must dial 911 for an emergency if they are in the US and receiving service from a service provider in the US. If the person from Africa is travelling in Asia and uses the proxy in the US for service, they can't expect it to correctly handle emergency service. The proxy could not possibly distinguish between the emergency numbers for Asia, Africa, US, and all the other local dialing plans that the user might know about. This is an application that must be limited to entry of E.164 numbers (which does not include any emergency numbers or local dialing plans). Further, in Section 5, it is unclear how to interpret the phrase "as well as the tel URIs enumerated in Section Section 4.2" (as a requirement). Section 4.2 listed two tel URIs (911 and 112) as examples ("such as"), not as an exhaustive list. Did this intend to say "as well as tel URIs formed from all the emergency numbers enumerated in the first paragraph of Section 4.2"? The Security Considerations in Section 9 has several problems. Emergency calls are not more sensitive than normal calls, so do not have a greater need for confidentiality. If "sips" itself may "cause the call to fail", then it can not be used. The requirement for the user agent to "reveal a different amount of information to the callee when making an emergency call" also applies to those calls dialed with the traditional emergency number when the user agent does not know the dial plan and therefore can not "clearly and unambiguously identity emergency calls". This function of revealing information must be possible without the SOS mechanism. If based on the SOS capability, then this makes it even more important for the user agent to correctly identify emergency calls (and not mistakenly trigger off of numbers assigned as emergency in other countries). Conclusion: The draft needs to make it clear how the SOS uri can be used in specific 3 cases: 1. User dials the traditional emergency number, the terminal recognizes it, and send the SOS URI. 2. User enter the SOS uri directly (types on a keyboard). 3. User presses a button or icon that causes the appropriate SOS URI to be sent. and cannot be used in the following case: 4. User dials the traditional emergency number, the terminal does not recognize it, and does not send the SOS URI. Case 1 can only occur if the terminal knows the "local" dial plan. ("Local" is with respect to where the user perceives they are getting service from.) Case 2 requires support for the local language. Case 3 is a machine-to-machine communication and does not require recognizable words. It can use the reserved English words since no foreign speaker sees them. Case 4 is used when the terminal does not know the local dial plan. It depends on a proxy to interpret the number, just as for any other dialed number. Mike Pierce Artel --part1_4f.3a2f7b25.2d5baec3_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/10/2004 5:18:03 PM Eastern Standard Time, oran@cisco.com writes:


--On Tuesday, February 10,=20= 2004 3:55 PM -0600 "James M. Polk"=20
<jmpolk@cisco.com> wrote:

> I have an concern within the new sos ID, and that concern is in sec= tion
> 4.1 - which reserves the following additional user addresses:
>
>     sos.fire    fire brigade
>     sos.rescue    ambulance (res= cue)
>     sos.marine    marine guard
>     sos.police    police (law en= forcement)
>     sos.mountain     mounta= in rescue
>
> as I have little confidence that Joe Citizen will be generally capa= ble to
> choose the correct one given their emergency experience. If these
> addresses are intended for between two ERCs (for a call transfer, f= or
> example) - I don't see the text stating that here.
>
I thought this was just to reflect current practice in places that alrea= dy=20
have different numbers for the different emergency services. Is your=20
concern that the *current* numbers are understood by joe citizen but the= se=20
are not? If so, the UA can just do the mapping as it has to do already f= or=20
911->sos@domain.




So, where in the world are different numbers used to access these differ= ent emergency services? Not in the US where we use English. If they are used= in some other country, then why aren't the "reserved" user addresses in the= language of that country? Joe Citizen may be able to choose the correct one= , but I don't think Heinrich Staatsangehoeriger or Pierre citoyen should be=20= expected to choose the correct English word. We have to stop relying on Engl= ish for everything.

My major concern with this whole plan is the presumption that the user's= terminal would be able to figure out to use the SOS URI as well as the sub-= address based on the number the person dials. There are fundamental, unanswe= red questions regarding if and how the terminal would know the local dialing= plan.

Further, I have a serious concern with the desciption in 4.2 that a term= inal must recognize many different digits strings and generate an SOS, indep= endent of where it is located, if it "has no knowledge of local emergency nu= mbers". This would result in many invalid calls to an emergency center, sinc= e many of these numbers could be valid (non-emergency) numbers (see note abo= ut 118 in Finland). Again, this relates to the question of how the terminal=20= knows the local dial plan. Unless a method can be defined so that a terminal= generates an SOS only for the specific emergency number or numbers valid fo= r the place it is physically located (or for the place that the user thinks=20= they are in, that is, their virtual location), this entire scheme is faulty=20= and can not be used. Section 6 covers the issue of Identifying the Local Eme= rgency Number. There should be a statement that some method of doing this id= entification is required, or else the terminal can not generate an SOS based= on dialed numbers. (Note the statement in Section 9 about being able to "cl= early and unambiguously identity emergency calls".)

The 3rd requirement (in Section 3) is incorrect. When someone is travell= ing, and getting service in a foreign country, there is no requirement that=20= they be able to dial their "familiar" home emergency identifier (presuming t= his refers to the emergency "number"). This is contradictory in many places.= As noted, 118 is directory assistance in Finland and a "familiar" emergency= number elsewhere. This case is proof that this requirement is impossible to= meet.

On the other hand, if a person is travelling and getting service from th= eir proxy back at the company office, they can't expect to get any emergency= service from that proxy.

The 4th requirement is misleading. It is not acceptable to have "restric= ted functionality" regarding access to emergency services due to user agents= not being aware of this document. There is clearly "restricted functionalit= y" concerning generation of the SOS URI, but that does not need to be stated= . The final sentence should state: "User agents conforming to the SIP specif= ication [RFC3261], but unaware of this document, must be able to place emerg= ency calls without any restriction using entry of normal emergency numbers,=20= although they will not generate the SOS URI."

The following requirement is missing: "It MUST be possible for a user of= a SIP device to dial a local emergency number in the normal manner and prop= erly reach the emergency service."

The statement in Section 5 that an "outbound proxy server MUST recognize= all local emergency numbers ..." is incorrect (and impossible). (Possibly t= his sentence was meant to say " ... all local emergency numbers listed in Se= ction 4.2...", but this is still impossible). An outbound proxy only needs t= o recognize those emergency numbers applicable to the local areas for which=20= it is providing service. An outbound proxy located in and providing service=20= for callers in the US certainly does not have to recognize the emergency num= ber used in some country in Africa. A visitor from that country must dial 91= 1 for an emergency if they are in the US and receiving service from a servic= e provider in the US. If the person from Africa is travelling in Asia and us= es the proxy in the US for service, they can't expect it to correctly handle= emergency service. The proxy could not possibly distinguish between the eme= rgency numbers for Asia, Africa, US, and all the other local dialing plans t= hat the user might know about. This is an application that must be limited t= o entry of E.164 numbers (which does not include any emergency numbers or lo= cal dialing plans).

Further, in Section 5, it is unclear how to interpret the phrase "as wel= l as the tel URIs enumerated in Section Section 4.2" (as a requirement). Sec= tion 4.2 listed two tel URIs (911 and 112) as examples ("such as"), not as a= n exhaustive list. Did this intend to say "as well as tel URIs formed from a= ll the emergency numbers enumerated in the first paragraph of Section 4.2"?

The Security Considerations in Section 9 has several problems. Emergency= calls are not more sensitive than normal calls, so do not have a greater ne= ed for confidentiality. If "sips" itself may "cause the call to fail", then=20= it can not be used.

The requirement for the user agent to "reveal a different amount of info= rmation to the callee when making an emergency call" also applies to those c= alls dialed with the traditional emergency number when the user agent does n= ot know the dial plan and therefore can not "clearly and unambiguously ident= ity emergency calls". This function of revealing information must be possibl= e without the SOS mechanism. If based on the SOS capability, then this makes= it even more important for the user agent to correctly identify emergency c= alls (and not mistakenly trigger off of numbers assigned as emergency in oth= er countries).

Conclusion:

The draft needs to make it clear how the SOS uri can be used in specific= 3 cases:

1. User dials the traditional emergency number, the terminal recognizes=20= it, and send the SOS URI.
2. User enter the SOS uri directly (types on a keyboard).
3. User presses a button or icon that causes the appropriate SOS URI to=20= be sent.

and cannot be used in the following case:

4. User dials the traditional emergency number, the terminal does not re= cognize it, and does not send the SOS URI.

Case 1 can only occur if the terminal knows the "local" dial plan. ("Loc= al" is with respect to where the user perceives they are getting service fro= m.)
Case 2 requires support for the local language.
Case 3 is a machine-to-machine communication and does not require recogn= izable words. It can use the reserved English words since no foreign speaker= sees them.
Case 4 is used when the terminal does not know the local dial plan. It d= epends on a proxy to interpret the number, just as for any other dialed numb= er.

Mike Pierce
Artel

--part1_4f.3a2f7b25.2d5baec3_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 11:29:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08171 for ; Wed, 11 Feb 2004 11:29:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxEp-0005A9-Ih for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 11:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BGTNGf019839 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 11:29:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxEp-00059u-F2 for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 11:29:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08041 for ; Wed, 11 Feb 2004 11:29:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxEo-0006ln-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:29:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxD9-0006LX-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:27:40 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqxAr-0005vs-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:25:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aqwx7-0002Tl-Pz for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:11:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqwx4-0003c5-Rh; Wed, 11 Feb 2004 11:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqwwo-0003bN-0e for sipping@optimus.ietf.org; Wed, 11 Feb 2004 11:10:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06932 for ; Wed, 11 Feb 2004 11:10:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqwwl-0004LN-00 for sipping@ietf.org; Wed, 11 Feb 2004 11:10:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqwvy-0004Gk-00 for sipping@ietf.org; Wed, 11 Feb 2004 11:09:55 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AqwvO-00048M-00 for sipping@ietf.org; Wed, 11 Feb 2004 11:09:18 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSC281J>; Wed, 11 Feb 2004 11:08:48 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63E5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Michael Hammer'" , sipping@ietf.org Subject: RE: [Sipping] Concern within sos ID - user addresses reserved Date: Wed, 11 Feb 2004 11:08:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 We can't get into semantic arguments about what the best word choice is; many of the users won't understand the subtleties, and we expect that in most cases the phone (or a proxy) will have a locally meaningful way to invoke the call. I do understand the concern for explosion of names in the registry. The "real" criteria is whether an ERC dispatches (directly or indirectly) such an agency. More wording needed, for sure. An RFC to add one is a pretty high burden. The doc discusses the issues on how to update location, and subscribe is one of them. I think we first have to agree on whether proxies can insert location, which influences the kind of mechanism you are suggesting. There are privacy issues associated with that. I personally think we're going to have to do it, but at the moment, the agreement with geopriv is that it's UA only. Brian > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Wednesday, February 11, 2004 10:45 AM > To: sipping@ietf.org > Subject: Re: [Sipping] Concern within sos ID - user addresses reserved > > > At 03:55 PM 2/10/2004 -0600, James M. Polk wrote: > > sos.fire fire brigade > > sos.rescue ambulance (rescue) > > sos.marine marine guard > > sos.police police (law enforcement) > > sos.mountain mountain rescue > > The second sub-address seems vague to me. Rescue could mean many > things. Perhaps, I need to be rescued from a fashion > emergency. :) Would > something like: > > sos.medic medical (doctor, nurse, paramedic team) > > be more descriptive? > > Also, with respect to registrations, I could see commercial interests > wanting to get into the act, such as an sos.fashion that I hinted at > above. Is there some guidance necessary to IANA? Do we > expect that the > IETF WGs will act as arbiters for this? > > Second, wrt location information reporting, is there any need for a > convention for providing a URL to which a receiving ECC can > SUBSCRIBE to > get location updates from either the UA or a network element > that is doing > triangulation. I am wondering if something like the following can be > inserted into the emergency INVITE: > > Call-Info: > ;purpose=location > > Mike > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 11:56:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09244 for ; Wed, 11 Feb 2004 11:56:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxeM-0007fm-RE for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 11:55:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BGtkv4029488 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 11:55:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxeM-0007fX-NE for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 11:55:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09241 for ; Wed, 11 Feb 2004 11:55:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxeL-0001va-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:55:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxdP-0001qL-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:54:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqxcm-0001lO-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:54:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqxcf-0007Te-BU; Wed, 11 Feb 2004 11:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxcU-0007T2-Hx for sipping@optimus.ietf.org; Wed, 11 Feb 2004 11:53:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09189 for ; Wed, 11 Feb 2004 11:53:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxcT-0001ku-00 for sipping@ietf.org; Wed, 11 Feb 2004 11:53:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxbW-0001fa-00 for sipping@ietf.org; Wed, 11 Feb 2004 11:52:51 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1AqxbK-0001Zt-00 for sipping@ietf.org; Wed, 11 Feb 2004 11:52:38 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 11 Feb 2004 08:50:35 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1BGq5hu024794; Wed, 11 Feb 2004 11:52:05 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-118.cisco.com [64.100.229.118]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AWX62975; Wed, 11 Feb 2004 08:52:03 -0800 (PST) Message-Id: <4.3.2.7.2.20040211114231.00b29e68@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Feb 2004 11:52:03 -0500 To: Mpierce1@aol.com From: Michael Hammer Subject: Re: [Sipping] Other concerns within sos ID Cc: oran@cisco.com, jmpolk@cisco.com, sipping@ietf.org In-Reply-To: <4f.3a2f7b25.2d5baec3@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 One additional question that was touched on in this email: If an sos URI contains a domain name, I presume that a proxy will forward the request based on that domain name and never look at the local part containing the "sos.xxx". Is that correct? If so, does that mean that the proxy in that domain is expected to look at the location information and forward to the appropriate ECC proxy? As for internationalization, that could get out of hand. Was the intent that these URIs are machine readable only? I suspect that some internationally recognized icons on the user agents that translate into these URIs will be needed. But, that could be tricky as well: sos.fire picture of flames sos.rescue picture of Red Cross/Crescent? sos.police picture of badge/police belt? sos.marine picture of boat + cross/crescent? sos.mountain picture of mountain + cross/crescent? But those icons are phone implementation details. Mike At 11:13 AM 2/11/2004 -0500, Mpierce1@aol.com wrote: >In a message dated 2/10/2004 5:18:03 PM Eastern Standard Time, >oran@cisco.com writes: > > >>--On Tuesday, February 10, 2004 3:55 PM -0600 "James M. Polk" >> wrote: >> >> > I have an concern within the new sos ID, and that concern is in section >> > 4.1 - which reserves the following additional user addresses: >> > >> > sos.fire fire brigade >> > sos.rescue ambulance (rescue) >> > sos.marine marine guard >> > sos.police police (law enforcement) >> > sos.mountain mountain rescue >> > >> > as I have little confidence that Joe Citizen will be generally capable to >> > choose the correct one given their emergency experience. If these >> > addresses are intended for between two ERCs (for a call transfer, for >> > example) - I don't see the text stating that here. >> > >>I thought this was just to reflect current practice in places that already >>have different numbers for the different emergency services. Is your >>concern that the *current* numbers are understood by joe citizen but these >>are not? If so, the UA can just do the mapping as it has to do already for >>911->sos@domain. > > > > >So, where in the world are different numbers used to access these >different emergency services? Not in the US where we use English. If they >are used in some other country, then why aren't the "reserved" user >addresses in the language of that country? Joe Citizen may be able to >choose the correct one, but I don't think Heinrich Staatsangehoeriger or >Pierre citoyen should be expected to choose the correct English word. We >have to stop relying on English for everything. > >My major concern with this whole plan is the presumption that the user's >terminal would be able to figure out to use the SOS URI as well as the >sub-address based on the number the person dials. There are fundamental, >unanswered questions regarding if and how the terminal would know the >local dialing plan. > >Further, I have a serious concern with the desciption in 4.2 that a >terminal must recognize many different digits strings and generate an SOS, >independent of where it is located, if it "has no knowledge of local >emergency numbers". This would result in many invalid calls to an >emergency center, since many of these numbers could be valid >(non-emergency) numbers (see note about 118 in Finland). Again, this >relates to the question of how the terminal knows the local dial plan. >Unless a method can be defined so that a terminal generates an SOS only >for the specific emergency number or numbers valid for the place it is >physically located (or for the place that the user thinks they are in, >that is, their virtual location), this entire scheme is faulty and can not >be used. Section 6 covers the issue of Identifying the Local Emergency >Number. There should be a statement that some method of doing this >identification is required, or else the terminal can not generate an SOS >based on dialed numbers. (Note the statement in Section 9 about being able >to "clearly and unambiguously identity emergency calls".) > >The 3rd requirement (in Section 3) is incorrect. When someone is >travelling, and getting service in a foreign country, there is no >requirement that they be able to dial their "familiar" home emergency >identifier (presuming this refers to the emergency "number"). This is >contradictory in many places. As noted, 118 is directory assistance in >Finland and a "familiar" emergency number elsewhere. This case is proof >that this requirement is impossible to meet. > >On the other hand, if a person is travelling and getting service from >their proxy back at the company office, they can't expect to get any >emergency service from that proxy. > >The 4th requirement is misleading. It is not acceptable to have >"restricted functionality" regarding access to emergency services due to >user agents not being aware of this document. There is clearly "restricted >functionality" concerning generation of the SOS URI, but that does not >need to be stated. The final sentence should state: "User agents >conforming to the SIP specification [RFC3261], but unaware of this >document, must be able to place emergency calls without any restriction >using entry of normal emergency numbers, although they will not generate >the SOS URI." > >The following requirement is missing: "It MUST be possible for a user of a >SIP device to dial a local emergency number in the normal manner and >properly reach the emergency service." > >The statement in Section 5 that an "outbound proxy server MUST recognize >all local emergency numbers ..." is incorrect (and impossible). (Possibly >this sentence was meant to say " ... all local emergency numbers listed in >Section 4.2...", but this is still impossible). An outbound proxy only >needs to recognize those emergency numbers applicable to the local areas >for which it is providing service. An outbound proxy located in and >providing service for callers in the US certainly does not have to >recognize the emergency number used in some country in Africa. A visitor >from that country must dial 911 for an emergency if they are in the US and >receiving service from a service provider in the US. If the person from >Africa is travelling in Asia and uses the proxy in the US for service, >they can't expect it to correctly handle emergency service. The proxy >could not possibly distinguish between the emergency numbers for Asia, >Africa, US, and all the other local dialing plans that the user might know >about. This is an application that must be limited to entry of E.164 >numbers (which does not include any emergency numbers or local dialing plans). > >Further, in Section 5, it is unclear how to interpret the phrase "as well >as the tel URIs enumerated in Section Section 4.2" (as a requirement). >Section 4.2 listed two tel URIs (911 and 112) as examples ("such as"), not >as an exhaustive list. Did this intend to say "as well as tel URIs formed >from all the emergency numbers enumerated in the first paragraph of >Section 4.2"? > >The Security Considerations in Section 9 has several problems. Emergency >calls are not more sensitive than normal calls, so do not have a greater >need for confidentiality. If "sips" itself may "cause the call to fail", >then it can not be used. > >The requirement for the user agent to "reveal a different amount of >information to the callee when making an emergency call" also applies to >those calls dialed with the traditional emergency number when the user >agent does not know the dial plan and therefore can not "clearly and >unambiguously identity emergency calls". This function of revealing >information must be possible without the SOS mechanism. If based on the >SOS capability, then this makes it even more important for the user agent >to correctly identify emergency calls (and not mistakenly trigger off of >numbers assigned as emergency in other countries). > >Conclusion: > >The draft needs to make it clear how the SOS uri can be used in specific 3 >cases: > >1. User dials the traditional emergency number, the terminal recognizes >it, and send the SOS URI. >2. User enter the SOS uri directly (types on a keyboard). >3. User presses a button or icon that causes the appropriate SOS URI to be >sent. > >and cannot be used in the following case: > >4. User dials the traditional emergency number, the terminal does not >recognize it, and does not send the SOS URI. > >Case 1 can only occur if the terminal knows the "local" dial plan. >("Local" is with respect to where the user perceives they are getting >service from.) >Case 2 requires support for the local language. >Case 3 is a machine-to-machine communication and does not require >recognizable words. It can use the reserved English words since no foreign >speaker sees them. >Case 4 is used when the terminal does not know the local dial plan. It >depends on a proxy to interpret the number, just as for any other dialed >number. > >Mike Pierce >Artel _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 12:01:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09482 for ; Wed, 11 Feb 2004 12:01:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxjE-0008M2-M8 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 12:00:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BH0mN4032108 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 12:00:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxjE-0008Ln-Ig for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 12:00:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09455 for ; Wed, 11 Feb 2004 12:00:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxjD-0002RF-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 12:00:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxiI-0002L3-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:59:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqxhV-0002FF-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 11:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxhV-0007mY-Vm; Wed, 11 Feb 2004 11:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxhI-0007m3-8T for sipping@optimus.ietf.org; Wed, 11 Feb 2004 11:58:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09375 for ; Wed, 11 Feb 2004 11:58:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxhG-0002E3-00 for sipping@ietf.org; Wed, 11 Feb 2004 11:58:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxgL-00028i-00 for sipping@ietf.org; Wed, 11 Feb 2004 11:57:49 -0500 Received: from c243101.rim.net ([216.9.243.101] helo=mhs99ykf.rim.net) by ietf-mx with esmtp (Exim 4.12) id 1Aqxfx-00023T-00 for sipping@ietf.org; Wed, 11 Feb 2004 11:57:25 -0500 Received: from ngw04ykf.rim.net (ngw04ykf.rim.net [10.102.100.115]) by mhs99ykf.rim.net (Postfix) with SMTP id 691BABF09A for ; Wed, 11 Feb 2004 11:57:19 -0500 (EST) Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw04ykf.rim.net (NAVGW 2.5.2.9) with SMTP id M2004021111571928549 ; Wed, 11 Feb 2004 11:57:19 -0500 Received: from xch15ykf.rim.net ([10.101.21.36]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Feb 2004 11:57:19 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: Re: [Sipping] Concern within sos ID - user addresses reserved Date: Wed, 11 Feb 2004 11:57:18 -0500 Message-ID: Thread-Topic: [Sipping] Concern within sos ID - user addresses reserved Thread-Index: AcPwtnX4KF51+xQIQXejXj+hfOEwYAACaXnP From: "Andrew Allen" To: , X-OriginalArrivalTime: 11 Feb 2004 16:57:19.0301 (UTC) FILETIME=[1C23EF50:01C3F0C0] Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable How about sos.medical then since that outlines the type of emergency. I = agree that rescue may be confused with the others. Andrew -------------------------- Andrew Allen Manager Standards Research In Motion Ltd BlackBerry Mobile +1 847 809 8636 European Mobile +358 50 467 5870 http://www.rim.com/ Sent from my BlackBerry Wireless Handheld -----Original Message----- From: Michael Hammer To: sipping@ietf.org Sent: Wed Feb 11 10:45:29 2004 Subject: Re: [Sipping] Concern within sos ID - user addresses reserved At 03:55 PM 2/10/2004 -0600, James M. Polk wrote: > sos.fire fire brigade > sos.rescue ambulance (rescue) > sos.marine marine guard > sos.police police (law enforcement) > sos.mountain mountain rescue The second sub-address seems vague to me. Rescue could mean many=20 things. Perhaps, I need to be rescued from a fashion emergency. :) = Would=20 something like: sos.medic medical (doctor, nurse, paramedic team) be more descriptive? Also, with respect to registrations, I could see commercial interests=20 wanting to get into the act, such as an sos.fashion that I hinted at=20 above. Is there some guidance necessary to IANA? Do we expect that the = IETF WGs will act as arbiters for this? Second, wrt location information reporting, is there any need for a=20 convention for providing a URL to which a receiving ECC can SUBSCRIBE to = get location updates from either the UA or a network element that is = doing=20 triangulation. I am wondering if something like the following can be=20 inserted into the emergency INVITE: Call-Info: = ;purpose=3Dlocation Mike _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 13:51:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13521 for ; Wed, 11 Feb 2004 13:51:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzRw-00008E-RA for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 13:51:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BIp4G0000500 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 13:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzRw-00007z-Lu for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 13:51:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13432 for ; Wed, 11 Feb 2004 13:51:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzRu-0005jp-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 13:51:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzQm-0005ds-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 13:49:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqzQ4-0005YM-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 13:49:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzPx-00085Q-Dd; Wed, 11 Feb 2004 13:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzPm-00082d-Pg for sipping@optimus.ietf.org; Wed, 11 Feb 2004 13:48:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13335 for ; Wed, 11 Feb 2004 13:48:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzPk-0005XW-00 for sipping@ietf.org; Wed, 11 Feb 2004 13:48:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzOp-0005SP-00 for sipping@ietf.org; Wed, 11 Feb 2004 13:47:52 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AqzO9-0005I7-00 for sipping@ietf.org; Wed, 11 Feb 2004 13:47:09 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCJC0H>; Wed, 11 Feb 2004 13:46:38 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63E7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Mpierce1@aol.com'" , oran@cisco.com, jmpolk@cisco.com, sipping@ietf.org Subject: RE: [Sipping] Other concerns within sos ID Date: Wed, 11 Feb 2004 13:46:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Thanks for your comments. While I have some replies, in line, you do raise a pretty important issue, which deserves attention. The fundamental idea that this draft proposes is that emergency calls get special attention. The special attention is that location is included on the call. There are also routing implications, but the inclusion of location is the key issue. The draft proposes that, one way or another, the call is determined to be an emergency call, and as a consequence, location is included. You point out the problem that if you have some address (phone number), which neither the UA or the outbound proxy recognizes as an emergency number, then it will not get special attention. The issue you raise with local emergency numbers is complicated by VPN tunnels. My usual example is the patron of a cafe in Chicago seeing an accident while connected via a hotspot through a VPN tunnel to an employer's VoIP system in Sierra Leone. In this example, dialing the Sierra Leone emergency number would not be an emergency call, but 9-1-1 would be. The answer that works is that the PHONE knows its location, and the PHONE knows the local emergency number (or the phone has some other way to determine an emergency call). If that is uniformly true, then it works. If that's not true, then the outbound proxy has a problem. It has to know the location of the phone to determine the "local" (to the phone) emergency number. So far, we haven't dealt with how we do that, but there are proposals that location is added by the outbound proxy when it can determine location, but the phone cannot. If the outbound proxy knows the location of the phone, then it could, in theory, determine the local (to the phone) emergency number, and then it could do the right thing. That seems to work also. The thing that wouldn't work is the cross cases, where the phone knows its location, but cannot recognize local numbers (didn't have a dialing plan), or where the phone has dialing plans, but know way to be told the local emergency number. The latter is probably fixable. The former is more difficult. We either have to fix it, or prohibit it somehow. I also realized that there is a dialing plan conflict. In my example, the employer in Sierra Leone has a local dialing plan. If it has a conflict with the local (to the phone) emergency number, there is a problem. That problem exists whether the phone or the proxy interprets the dialing plan. The same problem would exist today for someone calling into an access number for a PBX which allowed dialing within the PBX dial plan. If they were in a different continent, the local=to-the-phone) emergency number would not work, the local-to-the-pbx emergency number would get them to an ERC, but not the right one. There is no real solution that I can think of to this problem. You could always force the local-to-the-phone emergency number to override the local-to-the-pbx dial plan, but that is not very satisfactory. Better to not use a number to reach emergency services (use some other key sequence). More inline. ...snip... >So, where in the world are different numbers used to access these >different emergency services? Not in the US where we use English. >If they are used in some other country, then why aren't the "reserved" >user addresses in the language of that country? Joe Citizen may be able >to choose the correct one, but I don't think Heinrich Staatsangehoeriger >or Pierre citoyen should be expected to choose the correct English word. >We have to stop relying on English for everything. The assumption is that the phone presents an appropriate interface for initiating an emergency call, and the result is a call to one of these URLs. You don't normally type them. >My major concern with this whole plan is the presumption that the user's >terminal would be able to figure out to use the SOS URI as well as the >sub-address based on the number the person dials. There are fundamental, >unanswered questions regarding if and how the terminal would know the >local dialing plan. Covered above, noting that it might be a proxy, and not the phone, that has the dialing plan > >Further, I have a serious concern with the description in 4.2 that a terminal >must recognize many different digits strings and generate an SOS, independent >of where it is located, if it "has no knowledge of local emergency numbers". >This would result in many invalid calls to an emergency center, since many >of these numbers could be valid (non-emergency) numbers (see note about 118 >in Finland). Again, this relates to the question of how the terminal knows >the local dial plan. Unless a method can be defined so that a terminal >generates an SOS only for the specific emergency number or numbers valid for >the place it is physically located (or for the place that the user thinks >they are in, that is, their virtual location), this entire scheme is faulty >and can not be used. Section 6 covers the issue of Identifying the Local >Emergency Number. There should be a statement that some method of doing this >identification is required, or else the terminal can not generate an SOS >based on dialed numbers. (Note the statement in Section 9 about being able >to "clearly and unambiguously identity emergency calls".) Generally, I think you are right; the only emergency numbers are the ones local-to-the-phone. Either the phone, or the proxy has to know where the phone is, both to determine what the local emergency number is, and to correctly route. >The 3rd requirement (in Section 3) is incorrect. When someone is traveling, >and getting service in a foreign country, there is no requirement that they >be able to dial their "familiar" home emergency identifier (presuming this >refers to the emergency "number"). This is contradictory in many places. >As noted, 118 is directory assistance in Finland and a "familiar" emergency >number elsewhere. This case is proof that this requirement is impossible to >meet. Again, generally I agree. It's a very unfortunate situation, because if you are a visitor, your awareness of the local emergency number is not very good, while you clearly know your home emergency number. >On the other hand, if a person is traveling and getting service from their >proxy back at the company office, they can't expect to get any emergency >service from that proxy. No, the architecture is designed to make this work. The local-at-the-pbx proxy will find the location of the roaming party and route it to the correct ERC >The 4th requirement is misleading. It is not acceptable to have "restricted >functionality" regarding access to emergency services due to user agents not >being aware of this document. There is clearly "restricted functionality" >concerning generation of the SOS URI, but that does not need to be stated. There are phones out there now. What would you have us do with them? I think this is a reasonable backwards compatibility specification >The final sentence should state: "User agents conforming to the SIP >specification [RFC3261], but unaware of this document, must be able to place >emergency calls without any restriction using entry of normal emergency >numbers, although they will not generate the SOS URI." I think this is incorrect. First of all, a proxy can redirect to sos. Secondly, you can't get "without restriction" because you don't get location. >The following requirement is missing: "It MUST be possible for a user of a >SIP device to dial a local emergency number in the normal manner and properly >reach the emergency service." I don't understand what this adds to the requirements. We have to address some issues, but if we do, then this should be superfluous. >The statement in Section 5 that an "outbound proxy server MUST recognize >all local emergency numbers ..." is incorrect (and impossible). (Possibly >this sentence was meant to say " ... all local emergency numbers listed in >Section 4.2...", but this is still impossible). An outbound proxy only needs Rewording is required, I agree, but it has to refer to local-to-the-phone. >to recognize those emergency numbers applicable to the local areas for which >it is providing service. An outbound proxy located in and providing service >for callers in the US certainly does not have to recognize the emergency number >used in some country in Africa. A visitor from that country must dial 911 for >an emergency if they are in the US and receiving service from a service >provider in the US. If the person from Africa is traveling in Asia and uses >the proxy in the US for service, they can't expect it to correctly handle >emergency service. The proxy could not possibly distinguish between the >emergency numbers for Asia, Africa, US, and all the other local dialing plans >that the user might know about. This is an application that must be limited to >entry of E.164 numbers (which does not include any emergency numbers or local >dialing plans). Not correct, as above, the outbound proxy can provide emergency call routing even if the caller is roaming >Further, in Section 5, it is unclear how to interpret the phrase "as well as >the tel URIs enumerated in Section Section 4.2" (as a requirement). Section >4.2 listed two tel URIs (911 and 112) as examples ("such as"), not as an >exhaustive list. Did this intend to say "as well as tel URIs formed from all >the emergency numbers enumerated in the first paragraph of Section 4.2"? We can improve the wording here >The Security Considerations in Section 9 has several problems. Emergency calls >are not more sensitive than normal calls, so do not have a greater need for >confidentiality. If "sips" itself may "cause the call to fail", then it can >not be used. There are those who don't agree with you about confidentiality. I agree that calls can't fail if sips fails. There is text in the location requirements for sip document about this. >The requirement for the user agent to "reveal a different amount of information >to the callee when making an emergency call" also applies to those calls dialed >with the traditional emergency number when the user agent does not know the >dial plan and therefore can not "clearly and unambiguously identity emergency >calls". This function of revealing information must be possible without the SOS >mechanism. If based on the SOS capability, then this makes it even more >important for the user agent to correctly identify emergency calls (and not >mistakenly trigger off of numbers assigned as emergency in other countries). I think you propose something impossible. If the call is recognized as an emergency call, and routed as such, it will be routed as sos@localdomain, and have location. If it is not recognized, it will be treated per the local-to-the-pbx dial plan, and will not have location. While we may want to consider failure cases (you might reach some ERC, without location, which is better than nothing), the goal is to not ever have this happen. >Conclusion: > >The draft needs to make it clear how the SOS uri can be used in specific 3 >cases: > >1. User dials the traditional emergency number, the terminal recognizes it, >and send the SOS URI. >2. User enter the SOS uri directly (types on a keyboard). >3. User presses a button or icon that causes the appropriate SOS URI to be sent. > >and cannot be used in the following case: > >4. User dials the traditional emergency number, the terminal does not >recognize it, and does not send the SOS URI. The design is that a proxy can recognize the call as an emergency call and cause the correct treatment for it. >Case 1 can only occur if the terminal knows the "local" dial plan. ("Local" >is with respect to where the user perceives they are getting service from.) Or the proxy >Case 2 requires support for the local language. Agreed. Text needed. >Case 3 is a machine-to-machine communication and does not require recognizable >words. It can use the reserved English words since no foreign speaker sees them. Agreed >Case 4 is used when the terminal does not know the local dial plan. It depends >on a proxy to interpret the number, just as for any other dialed number. Disagree, as above Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 14:20:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15618 for ; Wed, 11 Feb 2004 14:20:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzuG-00040F-O3 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 14:20:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BJKJw9015380 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 14:20:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzuE-0003zt-0g for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 14:20:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15596 for ; Wed, 11 Feb 2004 14:20:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzuB-0001c6-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 14:20:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqzt1-0001U3-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 14:19:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqzsL-0001NB-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 14:18:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzs1-0003jj-Ft; Wed, 11 Feb 2004 14:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzr3-0003iI-BR for sipping@optimus.ietf.org; Wed, 11 Feb 2004 14:17:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15454 for ; Wed, 11 Feb 2004 14:16:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzr0-0001FJ-00 for sipping@ietf.org; Wed, 11 Feb 2004 14:16:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzqC-00018y-00 for sipping@ietf.org; Wed, 11 Feb 2004 14:16:09 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AqzpR-00011M-00 for sipping@ietf.org; Wed, 11 Feb 2004 14:15:21 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1BJFEkD029582; Wed, 11 Feb 2004 14:15:15 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1BJFAH03493; Wed, 11 Feb 2004 14:15:14 -0500 Message-ID: <402A7F3A.5030800@cs.columbia.edu> Date: Wed, 11 Feb 2004 14:15:06 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Mpierce1@aol.com'" , oran@cisco.com, jmpolk@cisco.com, sipping@ietf.org Subject: Re: [Sipping] Other concerns within sos ID References: <313680C9A886D511A06000204840E1CF070B63E7@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B63E7@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > The draft proposes that, one way or another, the call is determined to > be an emergency call, and as a consequence, location is included. > You point out the problem that if you have some address (phone number), > which neither the UA or the outbound proxy recognizes as an emergency > number, > then it will not get special attention. > > The issue you raise with local emergency numbers is complicated by VPN > tunnels. My usual example is the patron of a cafe in Chicago seeing an > accident while connected via a hotspot through a VPN tunnel to an employer's > > VoIP system in Sierra Leone. In this example, dialing the Sierra Leone > emergency number would not be an emergency call, but 9-1-1 would be. > > The answer that works is that the PHONE knows its location, and the PHONE > knows the local emergency number (or the phone has some other way to > determine an emergency call). If that is uniformly true, then it works. > If that's not true, then the outbound proxy has a problem. It has to know > the location of the phone to determine the "local" (to the phone) emergency > number. So far, we haven't dealt with how we do that, but there are > proposals that location is added by the outbound proxy when it can determine > > location, but the phone cannot. > > If the outbound proxy knows the location of the phone, then it could, > in theory, determine the local (to the phone) emergency number, and then it > could do > the right thing. That seems to work also. > > The thing that wouldn't work is the cross cases, where the phone knows its > location, but cannot recognize local numbers (didn't have a dialing plan), > or where the phone has dialing plans, but know way to be told the local > emergency number. The latter is probably fixable. The former is more > difficult. We either have to fix it, or prohibit it somehow. > > I also realized that there is a dialing plan conflict. In my example, > the employer in Sierra Leone has a local dialing plan. If it has a conflict > > with the local (to the phone) emergency number, there is a problem. > That problem exists whether the phone or the proxy interprets the dialing > plan. The same problem would exist today for someone calling into an access > > number for a PBX which allowed dialing within the PBX dial plan. > If they were in a different continent, the local=to-the-phone) > emergency number would not work, the local-to-the-pbx emergency number > would get them to an ERC, but not the right one. > > There is no real solution that I can think of to this problem. > You could always force the local-to-the-phone emergency number to override > the local-to-the-pbx dial plan, but that is not very satisfactory. > Better to not use a number to reach emergency services (use some other key > sequence). > In general, I think the correct long-term user interface solution is to have a hotkey or address book entry *with user confirmation* rather than having users trying to remember digit strings. The digit string model currently works rather badly for the PSTN - do you know, without looking at the hotel phone card insert, whether you need to dial 9-911, 0, 911, 0-911 or some other combination to get emergency help in a US hotel, let alone in some hotel in a foreign country? > Again, generally I agree. It's a very unfortunate situation, because if you > are a visitor, your awareness of the local emergency number is not very > good, > while you clearly know your home emergency number. This is a trade-off with no provably 'right' solution, so we need to make choices. GSM cell phone users expect that 112 works everywhere (which it apparently does, even in the US), for example. My hunch is that the collisions for traveling users are at best a nuisance (and outweighed by the safety advantages), but that's a hunch. > There are those who don't agree with you about confidentiality. And I think there's a reasonable case to be made that, on average, calling 911 is probably more security-relevant than calling your dry cleaner, for a variety of reasons. The document makes no quantitative claim, so I just don't see the harm. > I agree that calls can't fail if sips fails. There is text in the location > requirements for sip document about this. Among many of the topics discussed here, this has all been discussed before, with the current text trying to reflect the earlier consensus. We can't make progress if we re-open the same issues again and again. We should probably split the discussion into separate issues as the mail messages are getting far too long. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 15:39:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21022 for ; Wed, 11 Feb 2004 15:39:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar18h-0003UT-8Q for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 15:39:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKdJsb013413 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 15:39:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar18h-0003UD-3K for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 15:39:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20984 for ; Wed, 11 Feb 2004 15:39:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar18f-0002EL-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 15:39:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar17i-000253-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 15:38:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar16t-0001vz-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 15:37:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar16U-0002gd-T8; Wed, 11 Feb 2004 15:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar15n-0002bp-TR for sipping@optimus.ietf.org; Wed, 11 Feb 2004 15:36:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20684 for ; Wed, 11 Feb 2004 15:36:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar15m-0001nJ-00 for sipping@ietf.org; Wed, 11 Feb 2004 15:36:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar14p-0001eU-00 for sipping@ietf.org; Wed, 11 Feb 2004 15:35:19 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar13p-0001Ne-00 for sipping@ietf.org; Wed, 11 Feb 2004 15:34:18 -0500 Received: from softarmor.com (dhcp216-12-250-244.dfwb.dal.wayport.net [216.12.250.244]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i1BKZIsb029858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Feb 2004 14:35:19 -0600 Message-ID: <402A9198.5050008@softarmor.com> Date: Wed, 11 Feb 2004 14:33:28 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] IPR notice on KPML filed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: IPR Notice Date: Tue, 10 Feb 2004 18:07:08 -0500 (EST) From: IESG Secretary To: rohan@cisco.com, , CC: mankin@psg.com, , Dear Working Group Chairs: An IPR Notice has been posted that pertains to a document from the SIPPING Working Group. The title of the IPR Notice is "SnowShore's Statement about IPR Cliamed in draft-ietf-sipping-kpml" (http://www.ietf.org/ietf/IPR/snowshore-ipr-draft-ietf-sipping-kpml.txt). The IETF Secretariat _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 16:03:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23530 for ; Wed, 11 Feb 2004 16:03:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1VY-0005do-14 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 16:02:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BL2trM021678 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 16:02:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1VX-0005dZ-Td for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 16:02:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23474 for ; Wed, 11 Feb 2004 16:02:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1VW-00054L-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 16:02:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1Ua-0004wy-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 16:01:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1To-0004qm-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 16:01:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Ti-0005Kv-T6; Wed, 11 Feb 2004 16:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Sq-0005GU-GO for sipping@optimus.ietf.org; Wed, 11 Feb 2004 16:00:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23338 for ; Wed, 11 Feb 2004 16:00:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1So-0004it-00 for sipping@ietf.org; Wed, 11 Feb 2004 16:00:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1S0-0004bk-00 for sipping@ietf.org; Wed, 11 Feb 2004 15:59:17 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1RJ-0004SP-00 for sipping@ietf.org; Wed, 11 Feb 2004 15:58:37 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1BKvnu21500; Wed, 11 Feb 2004 15:57:49 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1FNH7LCH; Wed, 11 Feb 2004 15:57:50 -0500 Received: from nortelnetworks.com (acart1du.ca.nortel.com [47.129.129.103]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DBDZJGK1; Wed, 11 Feb 2004 15:57:49 -0500 Message-ID: <402A974C.2050304@nortelnetworks.com> Date: Wed, 11 Feb 2004 15:57:48 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: Mpierce1@aol.com, oran@cisco.com, jmpolk@cisco.com, sipping@ietf.org Subject: Re: [Sipping] Other concerns within sos ID References: <4.3.2.7.2.20040211114231.00b29e68@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20040211114231.00b29e68@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The human factors aspect of this stuff has traditionally been the domain of the ITU-T. I have a feeling they should be brought into the discussion. I would have to check, but the relevant experts used to be located in Study Group 2. Michael Hammer wrote: > One additional question that was touched on in this email: > > If an sos URI contains a domain name, I presume that a proxy will > forward the request based on that domain name and never look at the > local part containing the "sos.xxx". Is that correct? > > If so, does that mean that the proxy in that domain is expected to look > at the location information and forward to the appropriate ECC proxy? > > As for internationalization, that could get out of hand. Was the intent > that these URIs are machine readable only? I suspect that some > internationally recognized icons on the user agents that translate into > these URIs will be needed. But, that could be tricky as well: > > sos.fire picture of flames > sos.rescue picture of Red Cross/Crescent? > sos.police picture of badge/police belt? > sos.marine picture of boat + cross/crescent? > sos.mountain picture of mountain + cross/crescent? > > But those icons are phone implementation details. > > Mike > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 18:55:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11632 for ; Wed, 11 Feb 2004 18:55:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4Bp-0004HZ-S4 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 18:54:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BNsjHK016452 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 18:54:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4Bp-0004Gt-KI for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 18:54:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11626 for ; Wed, 11 Feb 2004 18:54:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4Bm-0000CS-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 18:54:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar4Aq-00006W-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 18:53:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4AX-000016-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 18:53:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4AA-00042a-0U; Wed, 11 Feb 2004 18:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar49s-00042H-Nw for sipping@optimus.ietf.org; Wed, 11 Feb 2004 18:52:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11589 for ; Wed, 11 Feb 2004 18:52:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar49p-00000Q-00 for sipping@ietf.org; Wed, 11 Feb 2004 18:52:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar48t-0007jY-00 for sipping@ietf.org; Wed, 11 Feb 2004 18:51:44 -0500 Received: from qfe5.f4cc49-01.broomfield1.level3.net ([209.245.18.95] helo=f4cc49-01.idc1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar48A-0007eq-00 for sipping@ietf.org; Wed, 11 Feb 2004 18:50:58 -0500 Received: from scanner1.level3.com (qfe0.f4gg49-02.idc1.oss.level3.com [10.1.156.106]) by f4cc49-01.idc1.level3.com (8.12.10/8.12.10) with ESMTP id i1BNoRNw018874; Wed, 11 Feb 2004 23:50:31 GMT Received: from scanner1.level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 55C7E78AC85; Wed, 11 Feb 2004 23:50:27 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.7.194]) by scanner1.level3.com (Postfix) with SMTP id 286FF78AC84; Wed, 11 Feb 2004 23:50:27 +0000 (GMT) Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 11 Feb 2004 16:50:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] TCAP tunneling Date: Wed, 11 Feb 2004 16:50:26 -0700 Message-ID: <3F75233A2E57CC468B35F3B1FAF71EC013AB37@idc1exc0004.corp.global.level3.com> Thread-Topic: [Sipping] TCAP tunneling Thread-Index: AcPqHzF405t/1C/pTiKkGOBuVHyZ7gG2Onjg From: "Hearty, John" To: "Jonathan Rosenberg" Cc: , "Peterson, Jon" X-OriginalArrivalTime: 11 Feb 2004 23:50:26.0838 (UTC) FILETIME=[D2A9EB60:01C3F0F9] Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable In looking at the ENUM RFC, it looks like NAPTR records are used, and they convert E.164 numbers to URIs. The syntax for the URIs does not appear to allow for Display Names, which is what I believe needs to be populated when forwarding SIP messages. I suppose we could still do TXT type DNS records for this, but can't find any standards specific to CNAM. The alternate idea similar to the yu draft seems to contradict the statement that SIP isn't a database query protocol. If anyone is already doing something like this or has plans I'd love to hear about it. John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, February 02, 2004 11:29 PM > To: Hearty, John > Cc: sipping@ietf.org; Peterson, Jon > Subject: Re: [Sipping] TCAP tunneling >=20 > SIP isnt a database query protocol, and cnam is just a DB query service. > As such, I would think that enum would be an appropriate technique for > this. Any other DB query mechanism will do as well. >=20 > Another idea would be to use a redirect service, similar to what has > been proposed in the past for LNP: >=20 > http://www.watersprings.org/pub/id/draft-yu-sip-np-02.txt >=20 > except that a request for a number would be redirected to a Contact > which contains that number plus the display name, representing the > calling name. >=20 > -Jonathan R. >=20 > Hearty, John wrote: > > Other than the miller draft below, is there any SIP standard proposed to > > carry cnam queries? > > > > John Hearty > > Level3 > > > > > >>-----Original Message----- > >>From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf > > > > Of > > > >>Arjun Roychowdhury > >>Sent: Monday, February 02, 2004 7:25 AM > >>To: Banibrata Dutta > >>Cc: kagarwal@cedarpointcom.com; ranjit.avasarala@wipro.com; > >>sipping@ietf.org; sipping-admin@ietf.org > >>Subject: RE: [Sipping] TCAP tunneling > >> > >>Actually, there _is_ an independant draft on how to carry TCAP in SIP. > >>http://www.ietf.org/internet-drafts/draft-miller-sip-tcap-00.txt > >> > >>Its another matter whether this is the right thing to do or not > > > > (please > > > >>refer to old archives for the debates). > >>Kaitaki, you may want to read the above draft as well as the > > > > discussions > > > >>on it to conclude for yourself which is the preferred method in your > >>deployment scenario. > >> > >>regds > >>arjun > >> > >> > >>-- > >>Arjun Roychowdhury @ Hughes Software Systems > >>11717 Exploration Lane, Germantown MD 20876 > >>(O): 301 212 7860 > >>VOIP: (SIP) 10303@fwd.pulver.com (PSTN alias:360-207-0467) > >> > >> > >> > >> > >>"Banibrata Dutta" > >>Sent by: sipping-admin@ietf.org > >>02/02/2004 12:25 AM > >> > >> > >> To: , > > > > , > > > >> > >> cc: > >> Subject: RE: [Sipping] TCAP tunneling > >> > >> > >>hi, > >> > >>franly, i'd say that, it depends on your motivation/reason to use SIP > >>for > >>tunneling TCAP. of course you can tunnel TCAP, but why you'd want to, > > > > is > > > >>a justification you'd have to work out. AFAIK, there's not ietf-draft > >>that > >>says, how. > >> > >>you can obviously tunnel TCAP query in an INVITE or INFO for that > > > > matter > > > >>(ideally in INVITE s.t. a SIP-dialog is also created which may be used > >>to > >>model the TCAP dialog as well, perhaps!). the ASN.1 BER encoded TCAP > >>messages may then reside within the body of a multi-part (MIME) enc, > >>INVITE. > >> > >>infact 1 reason i see where this may make sense is that you would > > > > rather > > > >>not have two stacks s.a. SIGTRAN and SIP for signalling transport, and > >>use > >>SIP as the *only* signalling solution, i.e. for the signalling > >>application > >>as well as for signalling transport, and support legacy/TCAP apps by > >>tunneling > >>them within SIP. but then, you generally have the constraints of > >>not-enough- > >>space, (for 2 stacks) only on resource-limited devices, s.a. > > > > hand-sets, > > > >>embedded devices etc., but i am unable see (yet), how TCAP can be > >>related to > >>such devices. > >> > >>my 2 cents, > >>Banibrata Dutta, > >> Hewlett-Packard ISO (P) Ltd, > >> 29, Cunningham Road, > >> Bangalore - 560052 > >> Ph: +91-80-22051796 > >> > >> > >>>-----Original Message----- > >>>From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > >>>On Behalf Of ranjit.avasarala@wipro.com > >>>Sent: Monday, February 02, 2004 10:20 AM > >>>To: kagarwal@cedarpointcom.com; sipping@ietf.org > >>>Subject: RE: [Sipping] TCAP tunneling > >>> > >>> > >>>Hi > >>> TCAP is used for Transaction Capabilities i.e database > >>>related while SIP with ISUP tunneling is used between MGCs. > >>>So I don't think TCAP can be tunneled in SIP. > >>> > >>>Ranjit > >>>Ph: 8520408/16 extn: 2173 > >>> > >>> > >>> > >>> > >>>-----Original Message----- > >>>From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > >>>On Behalf Of Kaitki Agarwal > >>>Sent: Monday, February 02, 2004 8:28 AM > >>>To: sipping@ietf.org > >>>Subject: [Sipping] TCAP tunneling > >>> > >>> > >>>Hi > >>> Can we tunnel tcap message in SIP as we do ISUP. If not why. > >>> > >>>Thanks > >>>Kaitki > >>>Jj~Yzy=3Di~Rz}y > >>> > >>>_______________________________________________ > >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >>>This list is for NEW development of the application of SIP > >>>Use sip-implementors@cs.columbia.edu for questions on current > >>>sip Use sip@ietf.org for new developments of core SIP > >>> > >> > >> > >>_______________________________________________ > >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >>This list is for NEW development of the application of SIP > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sip@ietf.org for new developments of core SIP > >> > >> > >> > >> > >>_______________________________________________ > >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >>This list is for NEW development of the application of SIP > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sip@ietf.org for new developments of core SIP > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > >=20 > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 19:11:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12556 for ; Wed, 11 Feb 2004 19:11:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4RT-0006Fs-16 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 19:10:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C0AsFI024038 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 19:10:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4RS-0006Fd-Tz for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 19:10:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12515 for ; Wed, 11 Feb 2004 19:10:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4RP-00024p-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 19:10:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar4QQ-0001xG-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 19:09:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4Pe-0001r3-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 19:09:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4Pe-0005lV-3T; Wed, 11 Feb 2004 19:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar4PQ-0005iI-J3 for sipping@optimus.ietf.org; Wed, 11 Feb 2004 19:08:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12419 for ; Wed, 11 Feb 2004 19:08:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4PN-0001qK-00 for sipping@ietf.org; Wed, 11 Feb 2004 19:08:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar4OW-0001l5-00 for sipping@ietf.org; Wed, 11 Feb 2004 19:07:52 -0500 Received: from [147.6.42.146] (helo=filter2.kt.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1Ar4Nq-0001XI-00 for sipping@ietf.org; Wed, 11 Feb 2004 19:07:10 -0500 Received: from external ([147.6.42.22]) by filter2 (1.0) id i1C066l11544; Thu, 12 Feb 2004 09:06:06 +0900 Received: from MAIL01CL ([147.6.42.211]) by smtp02.oasys.kt.co.kr with Microsoft SMTPSVC(5.0.2195.6713); Thu, 12 Feb 2004 09:11:34 +0900 Received: from mail01a ([147.6.42.214]) by MAIL01CL with Microsoft SMTPSVC(5.0.2195.6713); Thu, 12 Feb 2004 09:11:34 +0900 Priority: normal Thread-Topic: [sipping]New I-D on INFO usage thread-index: AcPw/MZ4+J+jLZCtRpyDI5H6AHnFUA== Reply-To: =?ks_c_5601-1987?B?sejD4bHU?= From: =?ks_c_5601-1987?B?sejD4bHU?= To: Date: Thu, 12 Feb 2004 09:11:34 +0900 Message-ID: <390b901c3f0fc$c678b490$d32a0693@oasys.kt.co.kr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_390BA_01C3F148.36605C90" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-OriginalArrivalTime: 12 Feb 2004 00:11:34.0873 (UTC) FILETIME=[C678B490:01C3F0FC] Subject: [Sipping] [sipping]New I-D on INFO usage Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, MIME_BASE64_TEXT,MIME_HTML_NO_CHARSET autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_390BA_01C3F148.36605C90 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable This document describes the INFO usage for IP-surveillance=0A= application. SIP is used as a means of incorporating terminals of=0A= different vendors. In this draft, mid-control commands, for example,=0A= retrieving server images or saving images in=0A= the server are defined and delivered as session names of INVITE = messages.=0A= IN addition to that, INFO definitions specific to the=0A= application are described. For example, camera control like PTZ(Pen,=0A= Tilt, Zoom) information is defined for the purpose of=0A= standardization of controls. =0A= =0A= A URL for this draft is =0A= =0A= http://www.ietf.org/internet-drafts/draft-cgkim-sipping-info-00.txt ------=_NextPart_000_390BA_01C3F148.36605C90 Content-Type: text/html Content-Transfer-Encoding: base64 PERJViBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4siI+CjxESVY+Jm5i c3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBJTkZPIHVzYWdlIGZvciBJUC1z dXJ2ZWlsbGFuY2U8QlI+Jm5ic3A7Jm5ic3A7IGFwcGxpY2F0aW9uLiBTSVAgaXMgdXNlZCBhcyBh IG1lYW5zIG9mIGluY29ycG9yYXRpbmcgdGVybWluYWxzIG9mPEJSPiZuYnNwOyZuYnNwOyBkaWZm ZXJlbnQgdmVuZG9ycy4gSW4gdGhpcyBkcmFmdCwgbWlkLWNvbnRyb2wmbmJzcDtjb21tYW5kcywg Zm9yIGV4YW1wbGUsPC9ESVY+CjxESVY+Jm5ic3A7ICZuYnNwO3JldHJpZXZpbmcgc2VydmVyIGlt YWdlcyBvciBzYXZpbmcgaW1hZ2VzIGluPEJSPiZuYnNwOyZuYnNwOyB0aGUgc2VydmVyIGFyZSBk ZWZpbmVkIGFuZCBkZWxpdmVyZWQgYXMgc2Vzc2lvbiBuYW1lcyBvZiBJTlZJVEUgbWVzc2FnZXMu PEJSPiZuYnNwOyZuYnNwOyBJTiBhZGRpdGlvbiB0byB0aGF0LCBJTkZPIGRlZmluaXRpb25zIHNw ZWNpZmljIHRvIHRoZTxCUj4mbmJzcDsmbmJzcDsgYXBwbGljYXRpb24gYXJlIGRlc2NyaWJlZC4g Rm9yIGV4YW1wbGUsIGNhbWVyYSBjb250cm9sIGxpa2UgUFRaKFBlbiw8QlI+Jm5ic3A7Jm5ic3A7 IFRpbHQsIFpvb20pIGluZm9ybWF0aW9uIGlzIGRlZmluZWQgZm9yIHRoZSBwdXJwb3NlIG9mPEJS PiZuYnNwOyZuYnNwOyBzdGFuZGFyZGl6YXRpb24gb2YgY29udHJvbHMuJm5ic3A7PEJSPiZuYnNw OzwvRElWPgo8RElWPiZuYnNwOyZuYnNwOyBBIFVSTCBmb3IgdGhpcyBkcmFmdCBpcyA8QlI+PEJS PiZuYnNwOyZuYnNwOzxBIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWNna2ltLXNpcHBpbmctaW5mby0wMC50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWNna2ltLXNpcHBpbmctaW5mby0wMC50eHQ8L0E+PC9ESVY+PC9E SVY+PEJSPg== ------=_NextPart_000_390BA_01C3F148.36605C90-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 19:49:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15198 for ; Wed, 11 Feb 2004 19:49:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar52B-0000uQ-Ux for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 19:48:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C0mpjg003488 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 19:48:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar52B-0000uB-Pl for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 19:48:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15183 for ; Wed, 11 Feb 2004 19:48:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar529-0007EP-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 19:48:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar51C-00078L-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 19:47:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar50R-00072i-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 19:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar50O-0000iQ-79; Wed, 11 Feb 2004 19:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar50H-0000hu-0H for sipping@optimus.ietf.org; Wed, 11 Feb 2004 19:46:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15131 for ; Wed, 11 Feb 2004 19:46:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar50F-00071t-00 for sipping@ietf.org; Wed, 11 Feb 2004 19:46:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar4zQ-0006vm-00 for sipping@ietf.org; Wed, 11 Feb 2004 19:46:01 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Ar4yY-0006hp-00 for sipping@ietf.org; Wed, 11 Feb 2004 19:45:06 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 11 Feb 2004 16:45:22 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1C0iXvV000102; Wed, 11 Feb 2004 16:44:34 -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 QAA20214; Wed, 11 Feb 2004 16:44:33 -0800 (PST) Message-Id: <4.3.2.7.2.20040211183604.039f9200@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Feb 2004 18:44:32 -0600 To: Henning Schulzrinne , "Rosen, Brian" From: "James M. Polk" Subject: Re: [Sipping] Other concerns within sos ID Cc: "'Mpierce1@aol.com'" , oran@cisco.com, sipping@ietf.org In-Reply-To: <402A7F3A.5030800@cs.columbia.edu> References: <313680C9A886D511A06000204840E1CF070B63E7@whq-msgusr-02.pit.comms.marconi.com> <313680C9A886D511A06000204840E1CF070B63E7@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 02:15 PM 2/11/2004 -0500, Henning Schulzrinne wrote: >In general, I think the correct long-term user interface solution is to >have a hotkey or address book entry *with user confirmation* rather than >having users trying to remember digit strings. This is something that the wireless industry used for a while with less than desirable affects (too many unintentional calls by hitting the one button accidentally). The PSAPs in the US (and I am only speaking for them in this comment) are quite opposed right now to this hotkey/button idea resurfacing. >The digit string model currently works rather badly for the PSTN - do you >know, without looking at the hotel phone card insert, whether you need to >dial 9-911, 0, 911, 0-911 or some other combination to get emergency help >in a US hotel, this is a good point - it changes based on the TDM switch configuration for that phone >let alone in some hotel in a foreign country? > > >>Again, generally I agree. It's a very unfortunate situation, because if you >>are a visitor, your awareness of the local emergency number is not very >>good, >>while you clearly know your home emergency number. > >This is a trade-off with no provably 'right' solution, so we need to make >choices. GSM cell phone users expect that 112 works everywhere (which it >apparently does, even in the US), for example. My hunch is that the >collisions for traveling users are at best a nuisance (and outweighed by >the safety advantages), but that's a hunch. curiosity question, if 112 works in the US, does 911 work anywhere in Europe? >Henning cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 19:58:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15661 for ; Wed, 11 Feb 2004 19:58:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5B0-0001b8-6t for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 19:57:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C0vwo1006136 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 19:57:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5B0-0001at-3g for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 19:57:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15636 for ; Wed, 11 Feb 2004 19:57:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5Ay-0000Zl-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 19:57:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar59x-0000TN-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 19:56:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar597-0000NB-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 19:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar598-0001Br-6D; Wed, 11 Feb 2004 19:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar58r-0001AJ-UH for sipping@optimus.ietf.org; Wed, 11 Feb 2004 19:55:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15522 for ; Wed, 11 Feb 2004 19:55:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar58q-0000L7-00 for sipping@ietf.org; Wed, 11 Feb 2004 19:55:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar57r-0000EH-00 for sipping@ietf.org; Wed, 11 Feb 2004 19:54:44 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Ar56x-00005v-00 for sipping@ietf.org; Wed, 11 Feb 2004 19:53:47 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1C0rHkD010682; Wed, 11 Feb 2004 19:53:22 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1C0rHH28240; Wed, 11 Feb 2004 19:53:17 -0500 Message-ID: <402ACE7A.2040302@cs.columbia.edu> Date: Wed, 11 Feb 2004 19:53:14 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" CC: sipping@ietf.org Subject: Re: [Sipping] Other concerns within sos ID References: <313680C9A886D511A06000204840E1CF070B63E7@whq-msgusr-02.pit.comms.marconi.com> <313680C9A886D511A06000204840E1CF070B63E7@whq-msgusr-02.pit.comms.marconi.com> <4.3.2.7.2.20040211183604.039f9200@localhost> In-Reply-To: <4.3.2.7.2.20040211183604.039f9200@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > This is something that the wireless industry used for a while with less > than desirable affects (too many unintentional calls by hitting the one > button accidentally). The PSAPs in the US (and I am only speaking for > them in this comment) are quite opposed right now to this hotkey/button > idea resurfacing. I guess my ** were not bold enough. I'm well aware of the hotkey issues and that's why I said "with user confirmation". That would eliminate the nuisance calls. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 21:37:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19902 for ; Wed, 11 Feb 2004 21:37:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6ik-0000Vf-Sx for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 21:36:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C2asCL001955 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 21:36:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6ik-0000VC-Nn for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 21:36:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19891 for ; Wed, 11 Feb 2004 21:36:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar6ii-000352-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 21:36:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar6hp-0002z2-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 21:35:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar6hD-0002t2-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 21:35:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6gx-0000JL-Kr; Wed, 11 Feb 2004 21:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar6gi-0000I1-W7 for sipping@optimus.ietf.org; Wed, 11 Feb 2004 21:34:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19780 for ; Wed, 11 Feb 2004 21:34:46 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar6gg-0002qM-00 for sipping@ietf.org; Wed, 11 Feb 2004 21:34:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar6fh-0002j2-00 for sipping@ietf.org; Wed, 11 Feb 2004 21:33:47 -0500 Received: from imo-m28.mx.aol.com ([64.12.137.9]) by ietf-mx with esmtp (Exim 4.12) id 1Ar6ek-0002Vc-00 for sipping@ietf.org; Wed, 11 Feb 2004 21:32:46 -0500 Received: from Mpierce1@aol.com by imo-m28.mx.aol.com (mail_out_v36_r4.12.) id e.1e9.18b32891 (17228); Wed, 11 Feb 2004 21:32:12 -0500 (EST) Message-ID: <1e9.18b32891.2d5c3fac@aol.com> Date: Wed, 11 Feb 2004 21:32:12 EST Subject: Re: [Sipping] Other concerns within sos ID To: Brian.Rosen@marconi.com, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1e9.18b32891.2d5c3fac_boundary" X-Mailer: 6.0 for Windows XP sub 51 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 --part1_1e9.18b32891.2d5c3fac_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/11/2004 1:50:25 PM Eastern Standard Time, Brian.Rosen@marconi.com writes: The fundamental idea that this draft proposes is that emergency calls get special attention. The special attention is that location is included on the call. There are also routing implications, but the inclusion of location is the key issue. [MAP] The point I'm trying to make is that the requirement to provide location for emergency calls has nothing to do with this draft (SOS URI). It must be accepted as a requirement and solved even if this SOS URI disappeared today. It can not be the SOS URI which enables the location to be provided. In a message dated 2/11/2004 1:50:25 PM Eastern Standard Time, Brian.Rosen@marconi.com writes: The issue you raise with local emergency numbers is complicated by VPN tunnels. My usual example is the patron of a cafe in Chicago seeing an accident while connected via a hotspot through a VPN tunnel to an employer's VoIP system in Sierra Leone. In this example, dialing the Sierra Leone emergency number would not be an emergency call, but 9-1-1 would be. [MAP] If the proxy at the emplyees home office wants to try to handle an emergency call and contact the emergency bureau at the location where it thinks the person is located, and has all the data to define such things, then let it. But I doubt that any regulatory agency would touch this, and any requirement they try to place on it would be a mess, since it's so dependent on lots of things out of anyone's control. I would say it's not a case we're trying to solve. In a message dated 2/11/2004 1:50:25 PM Eastern Standard Time, Brian.Rosen@marconi.com writes: Again, generally I agree. It's a very unfortunate situation, because if you are a visitor, your awareness of the local emergency number is not very good, while you clearly know your home emergency number. [MAP] True, but that doesn't mean one should use their home emergency number, just because they know it better. I know how to drive on the right better, but if I'm in England, I still have to drive on the left. In a message dated 2/11/2004 1:50:25 PM Eastern Standard Time, Brian.Rosen@marconi.com writes: >[MAP] The final sentence should state: "User agents conforming to the SIP >specification [RFC3261], but unaware of this document, must be able to place >emergency calls without any restriction using entry of normal emergency >numbers, although they will not generate the SOS URI." I think this is incorrect. First of all, a proxy can redirect to sos. Secondly, you can't get "without restriction" because you don't get location. [MAP] I think what I wrote above is a regulatory requirement. The UA must be able to place an emergency call "without restriction". Of course the proxy can generate an SOS URI. I didn't say it couldn't. As noted above, "location" is another issue not dependent on the SOS URI and not made possible by this document. In a message dated 2/11/2004 1:50:25 PM Eastern Standard Time, Brian.Rosen@marconi.com writes: >[MAP] Case 4 is used when the terminal does not know the local dial plan. It depends >on a proxy to interpret the number, just as for any other dialed number. Disagree, as above [MAP] I'm not sure why you said "disagreed", since your other comments seem to agree with the point I'm making in case 4 (terminal doesn't understand dial plan so it depends on a proxy to "recognize the call as an emergcncy call"). I'm just trying to be explicit by enumerating the case which this document does not cover. Mike Pierce --part1_1e9.18b32891.2d5c3fac_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/11/2004 1:50:25 PM Eastern Standard Time, Brian.Rosen@marconi.com wr= ites:

The fundamental idea that this draft proposes is that emergency calls=20
get special attention.  The special attention is that location is i= ncluded=20
on the call.  There are also routing implications, but the inclusio= n of=20
location is the key issue.

[MAP] The point I'm trying to make is that the requirement to provide lo= cation for emergency calls has nothing to do with this draft (SOS URI). It m= ust be accepted as a requirement and solved even if this SOS URI disappeared= today. It can not be the SOS URI which enables the location to be provided.


In a message dated 2/11/2004 1:50:25 PM Eastern Standard Time, Brian.Ros= en@marconi.com writes:

The issue you raise with local emergency numbers is complicated by VPN=20
tunnels.  My usual example is the patron of a cafe in Chicago seein= g an=20
accident while connected via a hotspot through a VPN tunnel to an employ= er's
VoIP system in Sierra Leone.  In this example, dialing the Sierra L= eone=20
emergency number would not be an emergency call, but 9-1-1 would be. &nb= sp;

[MAP] If the proxy at the emplyees home office wants to try to handle an= emergency call and contact the emergency bureau at the location where it th= inks the person is located, and has all the data to define such things, then= let it. But I doubt that any regulatory agency would touch this, and any re= quirement they try to place on it would be a mess, since it's so dependent o= n lots of things out of anyone's control. I would say it's not a case we're=20= trying to solve.


In a message dated 2/11/2004 1:50:25 PM Eastern Standard Time, Brian.Ros= en@marconi.com writes:

Again, generally I agree.  It's a very unfortunate situation, becau= se if you
are a visitor, your awareness of the local emergency number is not very=20= good,
while you clearly know your home emergency number.  

[MAP] True, but that doesn't mean one should use their  home emerge= ncy number, just because they know it better. I know how to drive on the rig= ht better, but if I'm in England, I still have to drive on the left.


In a message dated 2/11/2004 1:50:25 PM Eastern Standard Time, Brian.Ros= en@marconi.com writes:

>[MAP] The final sentence should state: "User agents conforming to th= e SIP=20
>specification [RFC3261], but unaware of this document, must be able=20= to place=20
>emergency calls without any restriction using entry of normal emerge= ncy=20
>numbers, although they will not generate the SOS URI."=20
I think this is incorrect.  First of all, a proxy can redirect to s= os.
Secondly, you can't get "without restriction" because you don't get
location.=20

[MAP] I think what I wrote above is a regulatory requirement. The UA mus= t be able to place an emergency call "without restriction". Of course the pr= oxy can generate an SOS URI. I didn't say it couldn't. As noted above, "loca= tion" is another issue not dependent on the SOS URI and not made possible by= this document.


In a message dated 2/11/2004 1:50:25 PM Eastern Standard Time, Brian.Ros= en@marconi.com writes:

>[MAP] Case 4 is used when the terminal does not know the local dial=20= plan. It depends=20
>on a proxy to interpret the number, just as for any other dialed num= ber.=20
Disagree, as above

[MAP] I'm not sure why you said "disagreed", since your other comments s= eem to agree with the point I'm making in case 4 (terminal doesn't understan= d dial plan so it depends on a proxy to "recognize the call as an emergcncy=20= call"). I'm just trying to be explicit by enumerating the case which this do= cument does not cover.


Mike Pierce
--part1_1e9.18b32891.2d5c3fac_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 22:42:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21632 for ; Wed, 11 Feb 2004 22:42:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar7ji-0005oo-QC for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 22:41:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C3fwkh022360 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 22:41:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar7ji-0005oZ-J7 for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 22:41:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21613 for ; Wed, 11 Feb 2004 22:41:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar7jf-0001aM-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 22:41:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar7ig-0001U0-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 22:40:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar7hx-0001Of-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 22:40:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar7hs-0005TZ-Lx; Wed, 11 Feb 2004 22:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar7hk-0005Sb-BD for sipping@optimus.ietf.org; Wed, 11 Feb 2004 22:39:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21547 for ; Wed, 11 Feb 2004 22:39:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar7hh-0001NN-00 for sipping@ietf.org; Wed, 11 Feb 2004 22:39:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar7gj-0001I7-00 for sipping@ietf.org; Wed, 11 Feb 2004 22:38:54 -0500 Received: from [147.6.42.146] (helo=filter2.kt.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1Ar7gD-0001Bi-00 for sipping@ietf.org; Wed, 11 Feb 2004 22:38:21 -0500 Received: from external ([147.6.9.113]) by filter2 (1.0) id i1C3bF028785; Thu, 12 Feb 2004 12:37:15 +0900 Message-ID: <00a101c3f119$99ac2ce0$71090693@ROMEO> From: =?ks_c_5601-1987?B?yLLB+LDm?= To: References: <390b901c3f0fc$c678b490$d32a0693@oasys.kt.co.kr> Date: Thu, 12 Feb 2004 12:37:54 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009E_01C3F165.09676DB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Sipping] [Sipping]New I-D on INFO-midcall Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FORGED_OUTLOOK_TAGS, MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_009E_01C3F165.09676DB0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQpUaXRsZTogSU5GTyBVc2FnZSBFeGFtcGxlcyBmb3IgTmV0d29yay1iYXNlZCBNaWQtQ2FsbCBT ZXJ2aWNlIA0KQXV0aG9yOiBKaW5reXVuZyBId2FuZyAoS1QpDQoNCkFic3RyYWN0Og0KDQogIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBJTkZPIHVzYWdlIGV4YW1wbGVzIGZvciBuZXR3b3Jr IGJhc2VkIA0KICBtaWQtY2FsbCBzZXJ2aWNlLiBNaWQtY2FsbCBiYXNlZCBzZXJ2aWNlcyBhcmUg Zm9yIGV4YW1wbGUsIENhbGwgDQogIFRyYW5zZmVyLCBDYWxsIFdhaXRpbmcsIGFuZCBUaHJlZS1X YXkgQ2FsbGluZy4gT3RoZXIgcG9zc2libGUgbWlkLQ0KICBjYWxsIHNlcnZpY2VzIGFyZSB1c2Vm dWwgYW5kIGltcG9ydGFudCwgZXZlbiBtb3JlIGluIElQIG11bHRpbWVkaWEgDQogIG5ldHdvcmsu IFRoZSBjYXNlcyBkZXNjcmliZWQgaW4gU0lQIHNlcnZpY2UgZXhhbXBsZXMgKGRyYWZ0LWlldGYt DQogIHNpcHBpbmctc2VydmljZS1leGFtcGxlcy0wNSkgYXJlIFRlcm1pbmFsLWJhc2lzLiBTaW5j ZSB0aGUgc2VydmljZSANCiAgcHJvY2VkdXJlcyBhcmUgZml4ZWQgaW4gdGhlIFRlcm1pbmFsLCB0 aGUgZmVhdHVyZXMgYXJlIG5vdCBleHRlbnNpYmxlLiANCiAgVGhpcyBkb2N1bWVudCBwcm9wb3Nl cyBuZXR3b3JrLWJhc2VkIG1pZC1jYWxsIGNvbnRyb2wgbWVjaGFuaXNtIHdpdGggDQogIElORk8g YW5kIHNob3dzIGV4YW1wbGVzIHRoYXQgc2ltcGxlIG1pZC1jYWxsIHJlcXVlc3QgKElORk8pIGZy b20gdGhlIA0KICBUZXJtaW5hbCwgdGhlbiB0aGUgbmV0d29yayBhcHBsaWNhdGlvbiBzZXJ2ZXIg cHJvdmlkZSB2YXJpb3VzIG1pZC1jYWxsIA0KICBzZXJ2aWNlcyBieSBwcm9tcHRpbmcgdXNlciB0 aHJvdWdoIHRoZSBNZWRpYSBTZXJ2ZXIsIGFjY29yZGluZyB0byB0aGUgDQogIHN1YnNjcmlwdGlv biBpbmZvcm1hdGlvbiBvZiB0aGUgdXNlci4gDQoNCkEgVVJMIGZvciB0aGlzIGRyYWZ0IGlzIA0K DQogaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaHdhbmctc2lwcGlu Zy1pbmZvbWlkY2FsbC0wMC50eHQNCg== ------=_NextPart_000_009E_01C3F165.09676DB0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTI3NiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRp dGxlOiBJTkZPIFVzYWdlIEV4YW1wbGVzIGZvciBOZXR3b3JrLWJhc2VkIE1pZC1DYWxsIFNlcnZp Y2UgPC9ESVY+DQo8RElWPkF1dGhvcjogSmlua3l1bmcgSHdhbmcgKEtUKTwvRElWPg0KPERJVj48 Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPkFic3Ry YWN0OjxCUj48L0RJVj4NCjxESVY+Jm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBJ TkZPIHVzYWdlIGV4YW1wbGVzIGZvciBuZXR3b3JrIA0KYmFzZWQmbmJzcDs8QlI+Jm5ic3A7Jm5i c3A7bWlkLWNhbGwgc2VydmljZS4gTWlkLWNhbGwgYmFzZWQgc2VydmljZXMgYXJlIGZvciANCmV4 YW1wbGUsIENhbGwmbmJzcDs8QlI+Jm5ic3A7Jm5ic3A7VHJhbnNmZXIsIENhbGwgV2FpdGluZywg YW5kIFRocmVlLVdheSANCkNhbGxpbmcuIE90aGVyIHBvc3NpYmxlIG1pZC08QlI+Jm5ic3A7Jm5i c3A7Y2FsbCBzZXJ2aWNlcyBhcmUgdXNlZnVsIGFuZCANCmltcG9ydGFudCwgZXZlbiBtb3JlIGlu IElQIG11bHRpbWVkaWEmbmJzcDs8QlI+Jm5ic3A7Jm5ic3A7bmV0d29yay4gVGhlIGNhc2VzIA0K ZGVzY3JpYmVkIGluIFNJUCBzZXJ2aWNlIGV4YW1wbGVzIA0KKGRyYWZ0LWlldGYtPEJSPiZuYnNw OyZuYnNwO3NpcHBpbmctc2VydmljZS1leGFtcGxlcy0wNSkgYXJlIFRlcm1pbmFsLWJhc2lzLiAN ClNpbmNlIHRoZSBzZXJ2aWNlJm5ic3A7PEJSPiZuYnNwOyZuYnNwO3Byb2NlZHVyZXMgYXJlIGZp eGVkIGluIHRoZSBUZXJtaW5hbCwgdGhlIA0KZmVhdHVyZXMgYXJlIG5vdCBleHRlbnNpYmxlLiZu YnNwOzxCUj4mbmJzcDsmbmJzcDtUaGlzIGRvY3VtZW50IHByb3Bvc2VzIA0KbmV0d29yay1iYXNl ZCBtaWQtY2FsbCBjb250cm9sIG1lY2hhbmlzbSB3aXRoJm5ic3A7PEJSPiZuYnNwOyZuYnNwO0lO Rk8gYW5kIA0Kc2hvd3MgZXhhbXBsZXMgdGhhdCBzaW1wbGUgbWlkLWNhbGwgcmVxdWVzdCAoSU5G TykgZnJvbSB0aGUmbmJzcDs8QlI+Jm5ic3A7IA0KVGVybWluYWwsIHRoZW4gdGhlIG5ldHdvcmsg YXBwbGljYXRpb24gc2VydmVyIHByb3ZpZGUgdmFyaW91cyANCm1pZC1jYWxsJm5ic3A7PEJSPiZu YnNwOyZuYnNwO3NlcnZpY2VzIGJ5IHByb21wdGluZyB1c2VyIHRocm91Z2ggdGhlIE1lZGlhIA0K U2VydmVyLCBhY2NvcmRpbmcgdG8gdGhlJm5ic3A7PEJSPiZuYnNwOyZuYnNwO3N1YnNjcmlwdGlv biBpbmZvcm1hdGlvbiBvZiB0aGUgDQp1c2VyLiA8QlI+PC9ESVY+DQo8RElWPkEgVVJMIGZvciB0 aGlzIGRyYWZ0IGlzIDxCUj48QlI+Jm5ic3A7PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTI+PEEg DQpocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1od2FuZy1z aXBwaW5nLWluZm9taWRjYWxsLTAwLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtaHdhbmctc2lwcGluZy1pbmZvbWlkY2FsbC0wMC50eHQ8L0E+PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_009E_01C3F165.09676DB0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 22:43:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21686 for ; Wed, 11 Feb 2004 22:43:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar7kk-0005qH-8b for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 22:43:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C3h2Bm022451 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 22:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar7kk-0005q2-5M for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 22:43:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21660 for ; Wed, 11 Feb 2004 22:42:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar7kg-0001in-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 22:42:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar7jm-0001b0-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 22:42:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar7il-0001UZ-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 22:40:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar7in-0005cJ-Uc; Wed, 11 Feb 2004 22:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar7hp-0005T4-Ai for sipping@optimus.ietf.org; Wed, 11 Feb 2004 22:40:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21552 for ; Wed, 11 Feb 2004 22:39:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar7hm-0001O1-00 for sipping@ietf.org; Wed, 11 Feb 2004 22:39:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar7gl-0001IN-00 for sipping@ietf.org; Wed, 11 Feb 2004 22:38:55 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Ar7gQ-0001Cy-00 for sipping@ietf.org; Wed, 11 Feb 2004 22:38:34 -0500 Received: from bear.cs.columbia.edu (IDENT:RNYm+wzd2K4X89jjLfC44Hrn6Go7VeUS@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1C3cUkE024753 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 11 Feb 2004 22:38:31 -0500 (EST) Received: from cs.columbia.edu (pool-141-153-198-80.mad.east.verizon.net [141.153.198.80]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1C3cTmi020058 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Feb 2004 22:38:29 -0500 Message-ID: <402AF532.1060604@cs.columbia.edu> Date: Wed, 11 Feb 2004 22:38:26 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Mpierce1@aol.com CC: sipping@ietf.org Subject: Re: [Sipping] Other concerns within sos ID References: <1e9.18b32891.2d5c3fac@aol.com> In-Reply-To: <1e9.18b32891.2d5c3fac@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [MAP] The point I'm trying to make is that the requirement to provide > location for emergency calls has nothing to do with this draft (SOS > URI). It must be accepted as a requirement and solved even if this SOS > URI disappeared today. It can not be the SOS URI which enables the > location to be provided. No, but the sos URI allows a downstream proxy to provide the location to the calling user via a redirect response (The caller then re-initiates a location-equipped emergency call as if it had the location itself). Whether the SOS URI is the *only* mechanism for the calling UA to request location information is another question. > [MAP] If the proxy at the emplyees home office wants to try to handle an > emergency call and contact the emergency bureau at the location where it > thinks the person is located, and has all the data to define such > things, then let it. But I doubt that any regulatory agency would touch > this, and any requirement they try to place on it would be a mess, since > it's so dependent on lots of things out of anyone's control. I would say > it's not a case we're trying to solve. In our architecture, this just works and is no more difficult than solving any other problem. If you have a concrete concern, please share it, but general regulation fear mongering isn't going to help much. > > [MAP] True, but that doesn't mean one should use their home emergency > number, just because they know it better. I know how to drive on the > right better, but if I'm in England, I still have to drive on the left. The problem is that driving on the wrong side gets you killed, while being able to dial a number that you remember while in panic quickly saves your life. Thus, the analogy is a rather poor one, in my opinion. The only drawback is that, in rather rare circumstances, your back-home emergency number is a valid service number at your current location. This seems, at worst, a minor nuisance. Since you're familiar with your home emergency number, if you find that the Easter Island use 911 for their directory service, there could be a user interface override ('escape'). One solution is to make this behavior configurable. If you'd rather use a device that does not remember your home dial plan, be my guest. Given that this is new and improved behavior compared to today's system, making this optional is not a big deal. > [MAP] I think what I wrote above is a regulatory requirement. The UA > must be able to place an emergency call "without restriction". Of course > the proxy can generate an SOS URI. I didn't say it couldn't. As noted > above, "location" is another issue not dependent on the SOS URI and not > made possible by this document. There are two cases: (1) Your UA recognizes the digits you dial as an emergency number and translates the digits into sos@something. (2) It doesn't. In the former case, the call will be placed correctly, assuming that (crude) location information is available. We should make sure that case (1) is the high-probability event. With the mechanisms described in the emergency-arch document, finding the local emergency number is not hard. That document suggests two different approaches (DNS and XCAP). In case (2), two things can happen: the call gets placed as a tel:XXX call and your local outbound proxy routes it to a gateway that does the right thing. This should be the common scenario, leaving odd VPN cases aside. (A well-maintained VPN will always get you to case (1).) Thus, I don't see the problem. > an emergcncy call"). I'm just trying to be explicit by enumerating the > case which this document does not cover. Which I still don't understand. Getting the geographically local dial plan is beyond the scope of this document, but is part of the emergency-arch document. > > > Mike Pierce _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 22:53:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22086 for ; Wed, 11 Feb 2004 22:53:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar7uN-0006Vj-BL for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 22:52:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C3qxjX025021 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 22:52:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar7uN-0006VU-7c for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 22:52:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22033 for ; Wed, 11 Feb 2004 22:52:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar7uJ-0002ux-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 22:52:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar7tN-0002mN-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 22:51:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar7sW-0002eF-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 22:51:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar7sW-0006HH-8o; Wed, 11 Feb 2004 22:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar7sK-0006GF-Ky for sipping@optimus.ietf.org; Wed, 11 Feb 2004 22:50:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21897 for ; Wed, 11 Feb 2004 22:50:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar7sH-0002bm-00 for sipping@ietf.org; Wed, 11 Feb 2004 22:50:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar7rK-0002UG-00 for sipping@ietf.org; Wed, 11 Feb 2004 22:49:51 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Ar7qR-0002Mh-00 for sipping@ietf.org; Wed, 11 Feb 2004 22:48:55 -0500 Received: from bear.cs.columbia.edu (IDENT:vekxnAayfRBEyf6/22uekgy0LwoCcFPn@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1C3mVkE027155 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 11 Feb 2004 22:48:32 -0500 (EST) Received: from cs.columbia.edu (pool-141-153-198-80.mad.east.verizon.net [141.153.198.80]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1C3mTmi020864 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Feb 2004 22:48:30 -0500 Message-ID: <402AF78B.4040801@cs.columbia.edu> Date: Wed, 11 Feb 2004 22:48:27 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Mpierce1@aol.com CC: oran@cisco.com, jmpolk@cisco.com, sipping@ietf.org Subject: Re: [Sipping] Other concerns within sos ID References: <1e7.19440e19.2d5baf3c@aol.com> In-Reply-To: <1e7.19440e19.2d5baf3c@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Further, I have a serious concern with the desciption in 4.2 that a > terminal must recognize many different digits strings and generate an > SOS, independent of where it is located, if it "has no knowledge of > local emergency numbers". This would result in many invalid calls to an > emergency center, since many of these numbers could be valid > (non-emergency) numbers (see note about 118 in Finland). Again, this From my vague recollection from the last iteration of this same discussion, some 3GPP folks claimed that this was the list of default emergency numbers embedded in 3G (or maybe even 2G) phones. That was the reason I added this list; it was specifically requested by somebody else (it was not in the earlier versions of -sos-, for example). If this is not true, I'll gladly remove the default list and rely on explicit configuration only, particularly since we now have, I believe, a better story on configuration than we did when this document was last discussed. (See emergency-arch for some of the details.) > The statement in Section 5 that an "outbound proxy server MUST recognize > all local emergency numbers ..." is incorrect (and impossible). > (Possibly this sentence was meant to say " ... all local emergency > numbers listed in Section 4.2...", but this is still impossible). An > outbound proxy only needs to recognize those emergency numbers > applicable to the local areas for which it is providing service. An > outbound proxy located in and providing service for callers in the US > certainly does not have to recognize the emergency number used in some > country in Africa. A visitor from that country must dial 911 for an If you looked into the emergency-arch document, you'd find that this problem is actually fairly easy to solve. > emergency if they are in the US and receiving service from a service > provider in the US. If the person from Africa is travelling in Asia and I'm not assuming the existence of a 'service provider'. > uses the proxy in the US for service, they can't expect it to correctly > handle emergency service. The proxy could not possibly distinguish > between the emergency numbers for Asia, Africa, US, and all the other > local dialing plans that the user might know about. This is an > application that must be limited to entry of E.164 numbers (which does > not include any emergency numbers or local dialing plans). > > Further, in Section 5, it is unclear how to interpret the phrase "as > well as the tel URIs enumerated in Section Section 4.2" (as a > requirement). Section 4.2 listed two tel URIs (911 and 112) as examples > ("such as"), not as an exhaustive list. Did this intend to say "as well > as tel URIs formed from all the emergency numbers enumerated in the > first paragraph of Section 4.2"? > The requirement for the user agent to "reveal a different amount of > information to the callee when making an emergency call" also applies to > those calls dialed with the traditional emergency number when the user > agent does not know the dial plan and therefore can not "clearly and > unambiguously identity emergency calls". This function of revealing > information must be possible without the SOS mechanism. If based on the Good luck convincing the GEOPRIV guys. This is a discussion best taken to a different venue. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 23:06:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22803 for ; Wed, 11 Feb 2004 23:06:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar87B-0007ZB-Rp for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 23:06:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C46DV4029079 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 23:06:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar87B-0007Yw-Kw for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 23:06:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22782 for ; Wed, 11 Feb 2004 23:06:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar877-0004Za-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 23:06:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar85k-0004O0-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 23:04:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar84E-0004Hk-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 23:03:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar845-0007CT-CX; Wed, 11 Feb 2004 23:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar843-00079a-FI for sipping@optimus.ietf.org; Wed, 11 Feb 2004 23:02:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22683 for ; Wed, 11 Feb 2004 23:02:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar83z-0004Gs-00 for sipping@ietf.org; Wed, 11 Feb 2004 23:02:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar83B-0004BU-00 for sipping@ietf.org; Wed, 11 Feb 2004 23:02:06 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Ar82a-000458-00 for sipping@ietf.org; Wed, 11 Feb 2004 23:01:28 -0500 Received: from bear.cs.columbia.edu (IDENT:+wHzqOSfzHNg5AfkFYfacFyG0k02EQlw@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1C41KkE029174 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 11 Feb 2004 23:01:21 -0500 (EST) Received: from cs.columbia.edu (pool-141-153-198-80.mad.east.verizon.net [141.153.198.80]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1C40wmi022053 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Feb 2004 23:00:59 -0500 Message-ID: <402AFA74.5020106@cs.columbia.edu> Date: Wed, 11 Feb 2004 23:00:52 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Michael Hammer CC: sipping@ietf.org Subject: Re: [Sipping] Other concerns within sos ID References: <4.3.2.7.2.20040211114231.00b29e68@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20040211114231.00b29e68@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > If an sos URI contains a domain name, I presume that a proxy will > forward the request based on that domain name and never look at the > local part containing the "sos.xxx". Is that correct? We have discussed two options in the past. One is the one you describe (and is normal SIP behavior); on the other hand, an outbound proxy could indeed inspect the URI and treat the call as an emergency call. I'd like to have a separate discussion as to whether such 'early intercept' is desirable. This behavior would need to be specified in the emergency-arch draft. > > If so, does that mean that the proxy in that domain is expected to look > at the location information and forward to the appropriate ECC proxy? Yes. > > As for internationalization, that could get out of hand. Was the intent I don't see how multiple languages could work in practice. Since emergency calls can be routed to strange places, outside the local calling area, every proxy would have to understand every possible variation of 'police' in hundreds of languages. > that these URIs are machine readable only? I suspect that some Mostly machine-generated. But that's a user interface issue that I thought IETF specs generally stayed out of. > internationally recognized icons on the user agents that translate into > these URIs will be needed. But, that could be tricky as well: > > sos.fire picture of flames > sos.rescue picture of Red Cross/Crescent? > sos.police picture of badge/police belt? > sos.marine picture of boat + cross/crescent? > sos.mountain picture of mountain + cross/crescent? > > But those icons are phone implementation details. I would also consider them somewhat unlikely to be visible on most devices, certainly hard phones with plastic buttons. For soft phones, if there is local dial plan discovery, the phone can display the appropriate icons or, easily, a word that means something in the user's native language. In general, I suspect that the use of different numbers is declining. For example, in Germany, due to 112 as the GSM emergency number and the EU common-emergency-number plans, dialing 112 will get you all emergency services, even though 110 is the designated police number. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 11 23:10:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22936 for ; Wed, 11 Feb 2004 23:10:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar8Au-0008AZ-GC for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 23:10:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C4A4GT031397 for sipping-archive@odin.ietf.org; Wed, 11 Feb 2004 23:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar8At-0008AK-Tj for sipping-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 23:10:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22921 for ; Wed, 11 Feb 2004 23:09:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar8Aq-0004yX-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 23:10:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar8A5-0004sF-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 23:09:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar89O-0004mc-00 for sipping-web-archive@ietf.org; Wed, 11 Feb 2004 23:08:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar890-0007pf-Pc; Wed, 11 Feb 2004 23:08:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar88n-0007mr-CX for sipping@optimus.ietf.org; Wed, 11 Feb 2004 23:07:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22857 for ; Wed, 11 Feb 2004 23:07:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar88i-0004h7-00 for sipping@ietf.org; Wed, 11 Feb 2004 23:07:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar86t-0004Z1-00 for sipping@ietf.org; Wed, 11 Feb 2004 23:05:56 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Ar85U-0004NV-00 for sipping@ietf.org; Wed, 11 Feb 2004 23:04:28 -0500 Received: from bear.cs.columbia.edu (IDENT:7/lZnRW14m7kIrhKVTV4q7vctkylhVem@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1C44TkE029886 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 11 Feb 2004 23:04:29 -0500 (EST) Received: from cs.columbia.edu (pool-141-153-198-80.mad.east.verizon.net [141.153.198.80]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1C44Smi022109 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 11 Feb 2004 23:04:29 -0500 Message-ID: <402AFB44.4030007@cs.columbia.edu> Date: Wed, 11 Feb 2004 23:04:20 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: sipping@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] SOS: 'rescue' Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I checked and the delineation of 'fire', 'rescue' and 'police' is quite common, says Google, as in http://www.hinckleytwp.org/fire-rescue-police.html http://www.tunstallfd.org/freqs.htm and thousands more. I'll ask the NENA folks whether something like 'ems' would be preferable. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 00:42:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25850 for ; Thu, 12 Feb 2004 00:42:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9cH-0006F8-1J for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 00:42:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C5gPNo023992 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 00:42:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9cG-0006Et-Ty for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 00:42:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25727 for ; Thu, 12 Feb 2004 00:42:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9cE-0005tJ-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 00:42:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar9bO-0005jL-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 00:41:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar9a1-0005YR-02 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 00:40:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar9Ko-0005h0-Sp for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 00:24:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9Kd-0003M5-EA; Thu, 12 Feb 2004 00:24:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar8bu-000195-0b for sipping@optimus.ietf.org; Wed, 11 Feb 2004 23:37:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23563 for ; Wed, 11 Feb 2004 23:37:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar8br-0007XB-00 for sipping@ietf.org; Wed, 11 Feb 2004 23:37:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar8av-0007S1-00 for sipping@ietf.org; Wed, 11 Feb 2004 23:36:57 -0500 Received: from [129.223.7.7] (helo=ausyd-apimss1.unisys.com.au) by ietf-mx with esmtp (Exim 4.12) id 1Ar8aR-0007M9-00 for sipping@ietf.org; Wed, 11 Feb 2004 23:36:28 -0500 Received: from AUSYD-GTWY1.ap.uis.unisys.com ([192.207.98.202]unverified) by 129.223.7.7 with InterScan Messaging Security Suite; Thu, 12 Feb 2004 15:37:00 +1100 Received: from ausyd-gtwy1.ap.uis.unisys.com ([192.207.98.220]) by AUSYD-GTWY1.ap.uis.unisys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 12 Feb 2004 15:35:50 +1100 Received: from ausyd-gtwy2.ap.uis.unisys.com ([192.207.98.204]) by ausyd-gtwy1.ap.uis.unisys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 12 Feb 2004 15:35:48 +1100 Received: from nzwlg-exch1.ap.uis.unisys.com ([129.223.96.24]) by ausyd-gtwy2.ap.uis.unisys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 12 Feb 2004 14:36:20 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: [Sipping] Other concerns within sos ID Date: Thu, 12 Feb 2004 16:36:22 +1300 Message-ID: <077B0972E8E7DB4D9D5C358B3443EF3912BBA4@nzwlg-exch1.nz.unisys.com> Thread-Topic: Re: [Sipping] Other concerns within sos ID Thread-Index: AcPxGWFsFDTh32mtTM+c5FEGH+YVAQ== From: "Keats, Evan" To: X-OriginalArrivalTime: 12 Feb 2004 03:36:21.0225 (UTC) FILETIME=[61B53D90:01C3F119] Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The Chicago/Sierra Leone scenario reinforces the suggestion of taking = this issue up with the ITU. Regardless of how much effort goes into the = correct routing of emergency calls, it will only be a matter of time = before jurisdictions will find them selves fielding emergency calls from = placed from other jurisdictions. This more than a technology problem, = jurisdictions will need procedures/protocols for handing on emergency = calls to each other.=20 Regards Evan Keats _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 00:42:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25870 for ; Thu, 12 Feb 2004 00:42:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9cK-0006Ft-9o for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 00:42:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C5gSli024039 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 00:42:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9cK-0006Fe-6Z for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 00:42:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25737 for ; Thu, 12 Feb 2004 00:42:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9cH-0005ti-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 00:42:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar9bQ-0005jl-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 00:41:33 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar9a1-0005YR-05 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 00:40:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar9Kk-0005fr-Es for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 00:24:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9Ka-0003KQ-B9; Thu, 12 Feb 2004 00:24:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar8RA-0000Qi-LI for sipping@optimus.ietf.org; Wed, 11 Feb 2004 23:26:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23372 for ; Wed, 11 Feb 2004 23:26:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar8R8-0006bI-00 for sipping@ietf.org; Wed, 11 Feb 2004 23:26:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar8Q9-0006Va-00 for sipping@ietf.org; Wed, 11 Feb 2004 23:25:49 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Ar8PC-0006QF-00 for sipping@ietf.org; Wed, 11 Feb 2004 23:24:50 -0500 Received: from bear.cs.columbia.edu (IDENT:MsDdvCrcBTPCaqkSmMb4fSTTr9vUGu/3@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1C4OkkE003417 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 11 Feb 2004 23:24:47 -0500 (EST) Received: from cs.columbia.edu (pool-141-153-198-80.mad.east.verizon.net [141.153.198.80]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1C4Okmi023837 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Feb 2004 23:24:46 -0500 Message-ID: <402B0008.3010002@cs.columbia.edu> Date: Wed, 11 Feb 2004 23:24:40 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: "Rosen, Brian" CC: sipping@ietf.org Subject: Re: [Sipping] Other concerns within sos ID References: <313680C9A886D511A06000204840E1CF070B63E7@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B63E7@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Picked up one relevant clarification item. Rosen, Brian wrote: >>The statement in Section 5 that an "outbound proxy server MUST recognize >>all local emergency numbers ..." is incorrect (and impossible). (Possibly >>this sentence was meant to say " ... all local emergency numbers listed in >>Section 4.2...", but this is still impossible). An outbound proxy only > > needs > Rewording is required, I agree, but it has to refer to local-to-the-phone. 'Local' has too many meanings - I guess it should always be qualified. I reworded this as referring to a the emergency numbers *local to the outbound proxy*. This is primarily meant to deal with phones that don't understand the conventions in the 'sos' document. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 08:34:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23297 for ; Thu, 12 Feb 2004 08:34:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArGyx-0002yd-Sw for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 08:34:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CDYJWU011437 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 08:34:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArGyx-0002yO-Nr for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 08:34:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23257 for ; Thu, 12 Feb 2004 08:34:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArGys-0004EY-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 08:34:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArGxv-00048e-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 08:33:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArGx0-00043L-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 08:32:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArGwk-0002iT-No; Thu, 12 Feb 2004 08:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArGw4-0002bM-Hj for sipping@optimus.ietf.org; Thu, 12 Feb 2004 08:31:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23122 for ; Thu, 12 Feb 2004 08:31:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArGvz-0003wt-00 for sipping@ietf.org; Thu, 12 Feb 2004 08:31:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArGv9-0003ql-00 for sipping@ietf.org; Thu, 12 Feb 2004 08:30:24 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1ArGuS-0003kS-00 for sipping@ietf.org; Thu, 12 Feb 2004 08:29:40 -0500 Received: from bear.cs.columbia.edu (IDENT:QiMoD5XWxGgJSY3rwcdhADec2YYhwcus@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1CDSUkE024381 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 12 Feb 2004 08:28:31 -0500 (EST) Received: from cs.columbia.edu (pool-141-153-198-80.mad.east.verizon.net [141.153.198.80]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1CDSUmi001651 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Feb 2004 08:28:30 -0500 Message-ID: <402B7F7B.2000409@cs.columbia.edu> Date: Thu, 12 Feb 2004 08:28:27 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: "Keats, Evan" CC: sipping@ietf.org Subject: Re: [Sipping] Other concerns within sos ID References: <077B0972E8E7DB4D9D5C358B3443EF3912BBA4@nzwlg-exch1.nz.unisys.com> In-Reply-To: <077B0972E8E7DB4D9D5C358B3443EF3912BBA4@nzwlg-exch1.nz.unisys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please take a look at the emergency-arch draft (and Brian Rosen's DNS draft). The whole point of this exercise is to make sure that a PSAP in Sierra Leone never has to field an emergency call except those pertaining to its own service area, even if an outbound proxy in Sierra Leone gets an emergency call from a user currently visiting Chicago. The only coordination is the appropriate population of the DNS records. This is not fundamentally different from the action that the Sierra Leonen SMTP MTA has to do if I submit an email addressed to uchicago.edu. This also does not require that the ISP in Sierra Leone contact the ITU to ask for proper diplomatic protocol. Tracking the responsible entity for each country may well be an ITU issue, as it is somewhat related to the ENUM top-level assignment problem. Keats, Evan wrote: > The Chicago/Sierra Leone scenario reinforces the suggestion of taking > this issue up with the ITU. Regardless of how much effort goes into > the correct routing of emergency calls, it will only be a matter of > time before jurisdictions will find them selves fielding emergency > calls from placed from other jurisdictions. This more than a > technology problem, jurisdictions will need procedures/protocols for > handing on emergency calls to each other. > > Regards Evan Keats > > > > _______________________________________________ Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW > development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 08:59:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24122 for ; Thu, 12 Feb 2004 08:59:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHN4-0004lo-EH for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 08:59:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CDxEuL018330 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 08:59:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHN4-0004lZ-3E for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 08:59:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24112 for ; Thu, 12 Feb 2004 08:59:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArHMy-0006dq-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 08:59:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArHM3-0006ZZ-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 08:58:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArHLt-0006VI-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 08:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHLu-0004ab-2N; Thu, 12 Feb 2004 08:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHL7-0004ZV-FB for sipping@optimus.ietf.org; Thu, 12 Feb 2004 08:57:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24087 for ; Thu, 12 Feb 2004 08:57:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArHL2-0006UC-00 for sipping@ietf.org; Thu, 12 Feb 2004 08:57:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArHK7-0006Pv-00 for sipping@ietf.org; Thu, 12 Feb 2004 08:56:12 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ArHJV-0006Gp-00 for sipping@ietf.org; Thu, 12 Feb 2004 08:55:34 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1CDswD17996 for ; Thu, 12 Feb 2004 07:55:00 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 12 Feb 2004 13:54:57 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EFF1@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sipping@ietf.org Subject: RE: [Sipping] Concern within sos ID - user addresses reserved Date: Thu, 12 Feb 2004 13:54:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 With a view of trying to borrow decisions from elsewhere. In 3GPP when the phone recognises that it is an emergency call, and needs to identify the type of emergency call, then it has access to signal categories with the following names (ref 3GPP TS 22.101): ------------------------------ - Police - Ambulance - Fire Brigade - Marine Guard - Mountain Rescue - Spare, at least [three] different types ----------------------------- which results in a coding accompanying the call establishment of (ref 3GPP TS 24.008 table 10.5.135d) -------------------------- Emergency Service Category Value (octet 3) The meaning of the Emergency Category Value is derived from the following settings (Please see 3GPP TS 22.101 clause 8): Bit 1 Police Bit 2 Ambulance Bit 3 Fire Brigade Bit 4 Marine Guard Bit 5 Mountain Rescue Bits 6,7,8 are spare and set to "0" Mobile station may set one or more bits to "1" If more than one bit is set to "1", routing to a combined Emergency centre (e.g. ambulance and fire brigade in Japan) is required. If the MSC can not match the received service category to any of the emergency centres, it shall route the call to an operator defined default emergency centre. If no bit is set to "1", the MSC shall route the Emergency call to an operator defined default emergency centre ------------------------- These terms are at least accepted by multiple SDOs in the international community for transposition into their national standards. I also note that 3GPP does have the capability of signalling multiple preferences - this left me wondering whether we would be better off trying to follow that, possibly with a single emergency uri, but with the possibility of signalling category as a URI parameter with a list of values. Any thoughts on this? regards Keith > -----Original Message----- > From: Andrew Allen [mailto:aallen@rim.net] > Sent: 11 February 2004 16:57 > To: mhammer@cisco.com; sipping@ietf.org > Subject: Re: [Sipping] Concern within sos ID - user addresses reserved > > > > > How about sos.medical then since that outlines the type of > emergency. I agree that rescue may be confused with the others. > > Andrew > -------------------------- > Andrew Allen > Manager Standards > Research In Motion Ltd > BlackBerry Mobile +1 847 809 8636 > European Mobile +358 50 467 5870 > http://www.rim.com/ > > Sent from my BlackBerry Wireless Handheld > > > -----Original Message----- > From: Michael Hammer > To: sipping@ietf.org > Sent: Wed Feb 11 10:45:29 2004 > Subject: Re: [Sipping] Concern within sos ID - user addresses reserved > > At 03:55 PM 2/10/2004 -0600, James M. Polk wrote: > > sos.fire fire brigade > > sos.rescue ambulance (rescue) > > sos.marine marine guard > > sos.police police (law enforcement) > > sos.mountain mountain rescue > > The second sub-address seems vague to me. Rescue could mean many > things. Perhaps, I need to be rescued from a fashion > emergency. :) Would > something like: > > sos.medic medical (doctor, nurse, paramedic team) > > be more descriptive? > > Also, with respect to registrations, I could see commercial interests > wanting to get into the act, such as an sos.fashion that I hinted at > above. Is there some guidance necessary to IANA? Do we > expect that the > IETF WGs will act as arbiters for this? > > Second, wrt location information reporting, is there any need for a > convention for providing a URL to which a receiving ECC can > SUBSCRIBE to > get location updates from either the UA or a network element > that is doing > triangulation. I am wondering if something like the following can be > inserted into the emergency INVITE: > > Call-Info: > ;purpose=location > > Mike > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 09:11:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24638 for ; Thu, 12 Feb 2004 09:11:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHYv-0006Bt-3v for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 09:11:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CEBTO8023791 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 09:11:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHYv-0006Be-0I for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 09:11:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24618 for ; Thu, 12 Feb 2004 09:11:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArHYp-00000J-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 09:11:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArHXo-0007hf-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 09:10:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArHXX-0007bx-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 09:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHXY-0005wA-9w; Thu, 12 Feb 2004 09:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHWn-0005sz-39 for sipping@optimus.ietf.org; Thu, 12 Feb 2004 09:09:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24536 for ; Thu, 12 Feb 2004 09:09:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArHWh-0007Zk-00 for sipping@ietf.org; Thu, 12 Feb 2004 09:09:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArHVp-0007Tx-00 for sipping@ietf.org; Thu, 12 Feb 2004 09:08:17 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1ArHVA-0007O0-00 for sipping@ietf.org; Thu, 12 Feb 2004 09:07:36 -0500 Received: from bear.cs.columbia.edu (IDENT:dBFWL8CWVS1UdAsB5ryRMS4gpDJWU0or@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1CE7ckE002249 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 12 Feb 2004 09:07:38 -0500 (EST) Received: from cs.columbia.edu (pool-141-153-198-80.mad.east.verizon.net [141.153.198.80]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1CE7bmi004589 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 12 Feb 2004 09:07:38 -0500 Message-ID: <402B88A6.7060804@cs.columbia.edu> Date: Thu, 12 Feb 2004 09:07:34 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: sipping@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] SOS: emergency numbers Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Let me try to tease out separate issues in the discussion and see if we can make progress that way. In some cases, we're revisiting old ground, so the proponents of the 'old' solution will have to chime in.] One of the core problems, spanning the architecture and sos drafts, is the question: what is an emergency number, how do systems find out and who needs to know? The current proposal is a bit of hybrid, in that there are pre-defined numbers (112, 911, 000, etc.) and acquired numbers. Numbers are acquired using three different mechanisms: XCAP to the home domain, XCAP to the visited domain (following the configuration draft methodology) and DNS based on knowledge of the current country code. None of these mechanisms existed in the first iterations of the -sos- draft, so it may be appropriate to revisit the issue. Thus, a streamlined proposal would be: (1) No protocol pre-defined numeric identifiers, not even 112 and 911. (Devices with personalization devices, such as SIM cards, may pre-load a dialplan, see (3).) (2) Any digit string NNN (not just emergency numbers) dialed and unrecognized gets translated into sip:NNN@aord;user=dialstring (as discussed at the last IETF meeting). AORD is then responsible for recognizing this as an emergency number, based on the current and possibly home country of the caller. An alternative is to translate these dialstrings into sip:NNN@outbound-proxy;user=dialstring, e.g., using the DHCP-provided outbound proxy address. I think this might be better, but that's a more general discussion. (2a) In general, digit strings that match a dialplan MAY become tel URIs, after they have been suitably normalized by the dialplan transformation rules. This does not apply to emergency numbers, where (3) applies. (3) Any digit dial string recognized as an emergency number gets translated into sos*@AORD. AORD = address of record domain, i.e., the domain part of my address of record. The device owner decides whether to acquire only the geographically local dialplan (MUST) or also his 'home' dialplan (MAY). Is this acceptable? Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 09:19:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24959 for ; Thu, 12 Feb 2004 09:19:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHgY-0006is-FM for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 09:19:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CEJMfW025836 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 09:19:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHgY-0006id-Bb for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 09:19:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24935 for ; Thu, 12 Feb 2004 09:19:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArHgS-0000p9-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 09:19:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArHfV-0000jq-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 09:18:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArHfD-0000eU-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 09:17:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHfG-0006T4-0j; Thu, 12 Feb 2004 09:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHea-0006Me-Lh for sipping@optimus.ietf.org; Thu, 12 Feb 2004 09:17:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24879 for ; Thu, 12 Feb 2004 09:17:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArHeV-0000dn-00 for sipping@ietf.org; Thu, 12 Feb 2004 09:17:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArHde-0000YL-00 for sipping@ietf.org; Thu, 12 Feb 2004 09:16:23 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1ArHd7-0000SU-00 for sipping@ietf.org; Thu, 12 Feb 2004 09:15:49 -0500 Received: from bear.cs.columbia.edu (IDENT:1cgXqnaqAW9iPzA9ZI3dB6Ow/S0+LiZR@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1CEFpkE003001 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 12 Feb 2004 09:15:51 -0500 (EST) Received: from cs.columbia.edu (pool-141-153-198-80.mad.east.verizon.net [141.153.198.80]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1CEFomi005396 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Feb 2004 09:15:51 -0500 Message-ID: <402B8A93.60507@cs.columbia.edu> Date: Thu, 12 Feb 2004 09:15:47 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: sipping@ietf.org Subject: Re: [Sipping] Concern within sos ID - user addresses reserved References: <475FF955A05DD411980D00508B6D5FB00439EFF1@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EFF1@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Interesting. The selection sounds like caller preferences to me. The nice thing about that is that you might be able to use existing techniques to match up services and destinations. For example, this could be considered a sip.class value, extending 'home' and 'business', or a new media feature tag, either specific to emergency services or a more generic service identifier. (The latter does invite the fashion emergency and roadside repair services into the same namespace.) Drage, Keith (Keith) wrote: > With a view of trying to borrow decisions from elsewhere. > > In 3GPP when the phone recognises that it is an emergency call, and needs to identify the type of emergency call, then it has access to signal categories with the following names (ref 3GPP TS 22.101): > > ------------------------------ > - Police > - Ambulance > - Fire Brigade > - Marine Guard > - Mountain Rescue > - Spare, at least [three] different types > ----------------------------- > > which results in a coding accompanying the call establishment of (ref 3GPP TS 24.008 table 10.5.135d) > > -------------------------- > Emergency Service Category Value (octet 3) > The meaning of the Emergency Category Value is derived from the following settings (Please see 3GPP TS 22.101 clause 8): > Bit 1 Police > Bit 2 Ambulance > Bit 3 Fire Brigade > Bit 4 Marine Guard > Bit 5 Mountain Rescue > Bits 6,7,8 are spare and set to "0" > > Mobile station may set one or more bits to "1" > If more than one bit is set to "1", routing to a combined Emergency centre (e.g. ambulance and fire brigade in Japan) is required. If the MSC can not match the received service category to any of the emergency centres, it shall route the call to an operator defined default emergency centre. > > If no bit is set to "1", the MSC shall route the Emergency call to an operator defined default emergency centre > ------------------------- > > These terms are at least accepted by multiple SDOs in the international community for transposition into their national standards. > > I also note that 3GPP does have the capability of signalling multiple preferences - this left me wondering whether we would be better off trying to follow that, possibly with a single emergency uri, but with the possibility of signalling category as a URI parameter with a list of values. Any thoughts on this? > > regards > > Keith > > > >>-----Original Message----- >>From: Andrew Allen [mailto:aallen@rim.net] >>Sent: 11 February 2004 16:57 >>To: mhammer@cisco.com; sipping@ietf.org >>Subject: Re: [Sipping] Concern within sos ID - user addresses reserved >> >> >> >> >>How about sos.medical then since that outlines the type of >>emergency. I agree that rescue may be confused with the others. >> >>Andrew >>-------------------------- >>Andrew Allen >>Manager Standards >>Research In Motion Ltd >>BlackBerry Mobile +1 847 809 8636 >>European Mobile +358 50 467 5870 >>http://www.rim.com/ >> >>Sent from my BlackBerry Wireless Handheld >> >> >>-----Original Message----- >>From: Michael Hammer >>To: sipping@ietf.org >>Sent: Wed Feb 11 10:45:29 2004 >>Subject: Re: [Sipping] Concern within sos ID - user addresses reserved >> >>At 03:55 PM 2/10/2004 -0600, James M. Polk wrote: >> >>> sos.fire fire brigade >>> sos.rescue ambulance (rescue) >>> sos.marine marine guard >>> sos.police police (law enforcement) >>> sos.mountain mountain rescue >> >>The second sub-address seems vague to me. Rescue could mean many >>things. Perhaps, I need to be rescued from a fashion >>emergency. :) Would >>something like: >> >> sos.medic medical (doctor, nurse, paramedic team) >> >>be more descriptive? >> >>Also, with respect to registrations, I could see commercial interests >>wanting to get into the act, such as an sos.fashion that I hinted at >>above. Is there some guidance necessary to IANA? Do we >>expect that the >>IETF WGs will act as arbiters for this? >> >>Second, wrt location information reporting, is there any need for a >>convention for providing a URL to which a receiving ECC can >>SUBSCRIBE to >>get location updates from either the UA or a network element >>that is doing >>triangulation. I am wondering if something like the following can be >>inserted into the emergency INVITE: >> >>Call-Info: >>;purpose=location >> >>Mike >> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP >> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP >> > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 10:52:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29424 for ; Thu, 12 Feb 2004 10:52:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJ8U-0003xq-Kj for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 10:52:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CFqIsP015234 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 10:52:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJ8U-0003xd-Ge for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 10:52:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29381 for ; Thu, 12 Feb 2004 10:52:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJ8O-00028P-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 10:52:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJ7R-00021l-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 10:51:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArJ6Y-0001vj-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 10:50:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJ6J-0003eD-Hh; Thu, 12 Feb 2004 10:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJ5g-0003aM-IK for sipping@optimus.ietf.org; Thu, 12 Feb 2004 10:49:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29225 for ; Thu, 12 Feb 2004 10:49:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJ5Z-0001pN-00 for sipping@ietf.org; Thu, 12 Feb 2004 10:49:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJ4d-0001k5-00 for sipping@ietf.org; Thu, 12 Feb 2004 10:48:20 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1ArJ4G-0001ex-00 for sipping@ietf.org; Thu, 12 Feb 2004 10:47:58 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 12 Feb 2004 07:45:26 -0800 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 i1CFlQT4022376; Thu, 12 Feb 2004 10:47:26 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-118.cisco.com [64.100.229.118]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AWY37769; Thu, 12 Feb 2004 07:47:25 -0800 (PST) Message-Id: <4.3.2.7.2.20040212103534.00b54878@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Feb 2004 10:47:24 -0500 To: Henning Schulzrinne From: Michael Hammer Subject: Re: [Sipping] Other concerns within sos ID Cc: sipping@ietf.org In-Reply-To: <402AFA74.5020106@cs.columbia.edu> References: <4.3.2.7.2.20040211114231.00b29e68@cia.cisco.com> <4.3.2.7.2.20040211114231.00b29e68@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 11:00 PM 2/11/2004 -0500, Henning Schulzrinne wrote: >>If an sos URI contains a domain name, I presume that a proxy will forward >>the request based on that domain name and never look at the local part >>containing the "sos.xxx". Is that correct? > >We have discussed two options in the past. One is the one you describe >(and is normal SIP behavior); on the other hand, an outbound proxy could >indeed inspect the URI and treat the call as an emergency call. I'd like >to have a separate discussion as to whether such 'early intercept' is >desirable. > >This behavior would need to be specified in the emergency-arch draft. > >>If so, does that mean that the proxy in that domain is expected to look >>at the location information and forward to the appropriate ECC proxy? > >Yes. > >>As for internationalization, that could get out of hand. Was the intent > >I don't see how multiple languages could work in practice. Since emergency >calls can be routed to strange places, outside the local calling area, >every proxy would have to understand every possible variation of 'police' >in hundreds of languages. > >>that these URIs are machine readable only? I suspect that some > >Mostly machine-generated. But that's a user interface issue that I thought >IETF specs generally stayed out of. Agreed. I was only suggesting that the dial-plan+local-language combination could be rather difficult. The below stuff was just suggesting that a GUI to machine translation could help solve that. >>internationally recognized icons on the user agents that translate into >>these URIs will be needed. But, that could be tricky as well: >>sos.fire picture of flames >>sos.rescue picture of Red Cross/Crescent? >>sos.police picture of badge/police belt? >>sos.marine picture of boat + cross/crescent? >>sos.mountain picture of mountain + cross/crescent? >>But those icons are phone implementation details. > >I would also consider them somewhat unlikely to be visible on most >devices, certainly hard phones with plastic buttons. Old POTS black phones yes, but many hard phones and cell phones today all come with a display and control software. So, it does not have to be a softphone on a PC. >For soft phones, if there is local dial plan discovery, the phone can >display the appropriate icons or, easily, a word that means something in >the user's native language. > >In general, I suspect that the use of different numbers is declining. For >example, in Germany, due to 112 as the GSM emergency number and the EU >common-emergency-number plans, dialing 112 will get you all emergency >services, even though 110 is the designated police number. > >Henning It would be nice if Asia, Africa, and South America had standard regional emergency numbers. (perhaps someone will tell us there is) Australia is apparently "000". Mike _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 11:36:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01536 for ; Thu, 12 Feb 2004 11:36:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJpC-0000CV-T6 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 11:36:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CGaQLI000765 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 11:36:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJpC-0000CG-OO for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 11:36:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01513 for ; Thu, 12 Feb 2004 11:36:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJp9-0007Dz-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 11:36:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJoF-00078X-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 11:35:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArJnq-00072k-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 11:35:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJnq-0008PF-SL; Thu, 12 Feb 2004 11:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJn5-0008Lb-2E for sipping@optimus.ietf.org; Thu, 12 Feb 2004 11:34:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01408 for ; Thu, 12 Feb 2004 11:34:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJn2-0006zv-00 for sipping@ietf.org; Thu, 12 Feb 2004 11:34:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJm3-0006qX-00 for sipping@ietf.org; Thu, 12 Feb 2004 11:33:13 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1ArJl5-0006aQ-00 for sipping@ietf.org; Thu, 12 Feb 2004 11:32:11 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1CGVgXV024387 for ; Thu, 12 Feb 2004 11:31:43 -0500 (EST) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Thu, 12 Feb 2004 11:31:29 -0500 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id <1WJACNLV>; Thu, 12 Feb 2004 11:31:33 -0500 Message-ID: From: "Farahmand, Fardad" To: "'Hearty, John'" , Jonathan Rosenberg Cc: sipping@ietf.org, "Peterson, Jon" Subject: RE: [Sipping] TCAP tunneling Date: Thu, 12 Feb 2004 11:31:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 The Yu draft describes a redirector or proxy which would perform the LNP for the called number. The redirector would add a Contact in 3XX with the information about the ported number. The proxy would add the information to the R-URI. CNAM is a bit different since we are dealing with the calling party information. I am a bit confused about Jonathan's comment regarding adding the CNAM information to the Contact header. It seems that the right approach would be for Proxies to add a PAI with display name. Looking at RFC3325, it seems that PAI can also be present in 3XX responses. So potentially redirectors can also add CNAM information by adding a PAI. So it seems like there are standard methods of introducing LNP and CNAM services in SIP networks. But what about all the other TCAP based services? This is yet to be resolved. Thanks, Fardad > -----Original Message----- > From: Hearty, John [mailto:John.Hearty@Level3.com] > Sent: Wednesday, February 11, 2004 6:50 PM > To: Jonathan Rosenberg > Cc: sipping@ietf.org; Peterson, Jon > Subject: RE: [Sipping] TCAP tunneling > > > In looking at the ENUM RFC, it looks like NAPTR records are used, and > they convert E.164 numbers to URIs. The syntax for the URIs does not > appear to allow for Display Names, which is what I believe needs to be > populated when forwarding SIP messages. I suppose we could > still do TXT > type DNS records for this, but can't find any standards specific to > CNAM. The alternate idea similar to the yu draft seems to contradict > the statement that SIP isn't a database query protocol. If anyone is > already doing something like this or has plans I'd love to hear about > it. > > John > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Monday, February 02, 2004 11:29 PM > > To: Hearty, John > > Cc: sipping@ietf.org; Peterson, Jon > > Subject: Re: [Sipping] TCAP tunneling > > > > SIP isnt a database query protocol, and cnam is just a DB query > service. > > As such, I would think that enum would be an appropriate > technique for > > this. Any other DB query mechanism will do as well. > > > > Another idea would be to use a redirect service, similar to what has > > been proposed in the past for LNP: > > > > http://www.watersprings.org/pub/id/draft-yu-sip-np-02.txt > > > > except that a request for a number would be redirected to a Contact > > which contains that number plus the display name, representing the > > calling name. > > > > -Jonathan R. > > > > Hearty, John wrote: > > > Other than the miller draft below, is there any SIP standard > proposed to > > > carry cnam queries? > > > > > > John Hearty > > > Level3 > > > > > > > > >>-----Original Message----- > > >>From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On > Behalf > > > > > > Of > > > > > >>Arjun Roychowdhury > > >>Sent: Monday, February 02, 2004 7:25 AM > > >>To: Banibrata Dutta > > >>Cc: kagarwal@cedarpointcom.com; ranjit.avasarala@wipro.com; > > >>sipping@ietf.org; sipping-admin@ietf.org > > >>Subject: RE: [Sipping] TCAP tunneling > > >> > > >>Actually, there _is_ an independant draft on how to carry TCAP in > SIP. > > >>http://www.ietf.org/internet-drafts/draft-miller-sip-tcap-00.txt > > >> > > >>Its another matter whether this is the right thing to do or not > > > > > > (please > > > > > >>refer to old archives for the debates). > > >>Kaitaki, you may want to read the above draft as well as the > > > > > > discussions > > > > > >>on it to conclude for yourself which is the preferred > method in your > > >>deployment scenario. > > >> > > >>regds > > >>arjun > > >> > > >> > > >>-- > > >>Arjun Roychowdhury @ Hughes Software Systems > > >>11717 Exploration Lane, Germantown MD 20876 > > >>(O): 301 212 7860 > > >>VOIP: (SIP) 10303@fwd.pulver.com (PSTN alias:360-207-0467) > > >> > > >> > > >> > > >> > > >>"Banibrata Dutta" > > >>Sent by: sipping-admin@ietf.org > > >>02/02/2004 12:25 AM > > >> > > >> > > >> To: , > > > > > > , > > > > > >> > > >> cc: > > >> Subject: RE: [Sipping] TCAP tunneling > > >> > > >> > > >>hi, > > >> > > >>franly, i'd say that, it depends on your motivation/reason to use > SIP > > >>for > > >>tunneling TCAP. of course you can tunnel TCAP, but why you'd want > to, > > > > > > is > > > > > >>a justification you'd have to work out. AFAIK, there's not > ietf-draft > > >>that > > >>says, how. > > >> > > >>you can obviously tunnel TCAP query in an INVITE or INFO for that > > > > > > matter > > > > > >>(ideally in INVITE s.t. a SIP-dialog is also created which may be > used > > >>to > > >>model the TCAP dialog as well, perhaps!). the ASN.1 BER > encoded TCAP > > >>messages may then reside within the body of a multi-part > (MIME) enc, > > >>INVITE. > > >> > > >>infact 1 reason i see where this may make sense is that you would > > > > > > rather > > > > > >>not have two stacks s.a. SIGTRAN and SIP for signalling transport, > and > > >>use > > >>SIP as the *only* signalling solution, i.e. for the signalling > > >>application > > >>as well as for signalling transport, and support > legacy/TCAP apps by > > >>tunneling > > >>them within SIP. but then, you generally have the constraints of > > >>not-enough- > > >>space, (for 2 stacks) only on resource-limited devices, s.a. > > > > > > hand-sets, > > > > > >>embedded devices etc., but i am unable see (yet), how TCAP can be > > >>related to > > >>such devices. > > >> > > >>my 2 cents, > > >>Banibrata Dutta, > > >> Hewlett-Packard ISO (P) Ltd, > > >> 29, Cunningham Road, > > >> Bangalore - 560052 > > >> Ph: +91-80-22051796 > > >> > > >> > > >>>-----Original Message----- > > >>>From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > >>>On Behalf Of ranjit.avasarala@wipro.com > > >>>Sent: Monday, February 02, 2004 10:20 AM > > >>>To: kagarwal@cedarpointcom.com; sipping@ietf.org > > >>>Subject: RE: [Sipping] TCAP tunneling > > >>> > > >>> > > >>>Hi > > >>> TCAP is used for Transaction Capabilities i.e database > > >>>related while SIP with ISUP tunneling is used between MGCs. > > >>>So I don't think TCAP can be tunneled in SIP. > > >>> > > >>>Ranjit > > >>>Ph: 8520408/16 extn: 2173 > > >>> > > >>> > > >>> > > >>> > > >>>-----Original Message----- > > >>>From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > >>>On Behalf Of Kaitki Agarwal > > >>>Sent: Monday, February 02, 2004 8:28 AM > > >>>To: sipping@ietf.org > > >>>Subject: [Sipping] TCAP tunneling > > >>> > > >>> > > >>>Hi > > >>> Can we tunnel tcap message in SIP as we do ISUP. If not why. > > >>> > > >>>Thanks > > >>>Kaitki > > >>>Jj~Yzy=i~Rz}y > > >>> > > >>>_______________________________________________ > > >>>Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > >>>This list is for NEW development of the application of SIP > > >>>Use sip-implementors@cs.columbia.edu for questions on current > > >>>sip Use sip@ietf.org for new developments of core SIP > > >>> > > >> > > >> > > >>_______________________________________________ > > >>Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > >>This list is for NEW development of the application of SIP > > >>Use sip-implementors@cs.columbia.edu for questions on current sip > > >>Use sip@ietf.org for new developments of core SIP > > >> > > >> > > >> > > >> > > >>_______________________________________________ > > >>Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > >>This list is for NEW development of the application of SIP > > >>Use sip-implementors@cs.columbia.edu for questions on current sip > > >>Use sip@ietf.org for new developments of core SIP > > > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ > 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 11:58:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02385 for ; Thu, 12 Feb 2004 11:58:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArK9w-0002Y9-J1 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 11:57:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CGvq7q009801 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 11:57:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArK9w-0002Y0-Et for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 11:57:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02366 for ; Thu, 12 Feb 2004 11:57:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArK9t-0001Yz-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 11:57:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArK8w-0001QS-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 11:56:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArK8G-0001HV-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 11:56:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArK8A-0002JL-J0; Thu, 12 Feb 2004 11:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArK7T-0002Ih-D2 for sipping@optimus.ietf.org; Thu, 12 Feb 2004 11:55:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02303 for ; Thu, 12 Feb 2004 11:55:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArK7Q-0001Fi-00 for sipping@ietf.org; Thu, 12 Feb 2004 11:55:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArK6X-0001BO-00 for sipping@ietf.org; Thu, 12 Feb 2004 11:54:21 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1ArK66-00016Y-00 for sipping@ietf.org; Thu, 12 Feb 2004 11:53:54 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1CGrckD001831; Thu, 12 Feb 2004 11:53:38 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1CGrZH23297; Thu, 12 Feb 2004 11:53:35 -0500 Message-ID: <402BAF8B.2040402@cs.columbia.edu> Date: Thu, 12 Feb 2004 11:53:31 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: sipping@ietf.org Subject: Re: [Sipping] Other concerns within sos ID References: <4.3.2.7.2.20040211114231.00b29e68@cia.cisco.com> <4.3.2.7.2.20040211114231.00b29e68@cia.cisco.com> <4.3.2.7.2.20040212103534.00b54878@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20040212103534.00b54878@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Old POTS black phones yes, but many hard phones and cell phones today > all come with a display and control software. So, it does not have to > be a softphone on a PC. Certainly. > It would be nice if Asia, Africa, and South America had standard > regional emergency numbers. (perhaps someone will tell us there is) > > Australia is apparently "000". http://www.911dispatch.com/web_graphic/graphic1.html has a graphic and lists of numbers. As you can see, very little coherence, but lots of countries with a single NNN. > > Mike _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 12:00:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02500 for ; Thu, 12 Feb 2004 12:00:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKBd-00033k-Q4 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 11:59:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CGxbhJ011754 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 11:59:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKBd-00033V-LH for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 11:59:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02476 for ; Thu, 12 Feb 2004 11:59:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKBa-0001oY-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 11:59:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKAm-0001hX-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 11:58:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArKA2-0001ZJ-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 11:57:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKA5-0002aT-3N; Thu, 12 Feb 2004 11:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArK9v-0002Xq-1D for sipping@optimus.ietf.org; Thu, 12 Feb 2004 11:57:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02360 for ; Thu, 12 Feb 2004 11:57:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArK9r-0001Yo-00 for sipping@ietf.org; Thu, 12 Feb 2004 11:57:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArK8u-0001QC-00 for sipping@ietf.org; Thu, 12 Feb 2004 11:56:49 -0500 Received: from pooh.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 1ArK8C-0001HS-00 for sipping@ietf.org; Thu, 12 Feb 2004 11:56:04 -0500 Received: from pcasveren (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with SMTP id LAA11031 for ; Thu, 12 Feb 2004 11:56:05 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sipping] TCAP tunneling Date: Thu, 12 Feb 2004 11:53:44 -0500 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.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A few thoughts below.... > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of > Farahmand, Fardad > Sent: Thursday, February 12, 2004 11:32 AM > To: 'Hearty, John'; Jonathan Rosenberg > Cc: sipping@ietf.org; Peterson, Jon > Subject: RE: [Sipping] TCAP tunneling > > > > The Yu draft describes a redirector or proxy which would perform > the LNP for > the called number. The redirector would add a Contact in 3XX with the > information about the ported number. The proxy would add the > information to > the R-URI. > > CNAM is a bit different since we are dealing with the calling party > information. I am a bit confused about Jonathan's comment regarding adding > the CNAM information to the Contact header. It seems that the > right approach > would be for Proxies to add a PAI with display name. Looking at > RFC3325, it > seems that PAI can also be present in 3XX responses. So potentially > redirectors can also add CNAM information by adding a PAI. > > So it seems like there are standard methods of introducing LNP and CNAM > services in SIP networks. But what about all the other TCAP > based services? > This is yet to be resolved. [TOLGA]Maybe the key point is that the services are *not* based on TCAP, TCAP is just a way to do synchronous remote procedure calls, so it does not really have service related semantics. Important is, what is transferred on top of TCAP (e.g. INAP), and I would think in such a case, the best way is thinking on a per service bases rather than trying to encapsulate such a protocol (afterall also for INAP just the protocol is standardized by ITU, there are different ways to implement a certain service from message flow point of view) > > Thanks, > Fardad > > > -----Original Message----- > > From: Hearty, John [mailto:John.Hearty@Level3.com] > > Sent: Wednesday, February 11, 2004 6:50 PM > > To: Jonathan Rosenberg > > Cc: sipping@ietf.org; Peterson, Jon > > Subject: RE: [Sipping] TCAP tunneling > > > > > > In looking at the ENUM RFC, it looks like NAPTR records are used, and > > they convert E.164 numbers to URIs. The syntax for the URIs does not > > appear to allow for Display Names, which is what I believe needs to be > > populated when forwarding SIP messages. I suppose we could > > still do TXT > > type DNS records for this, but can't find any standards specific to > > CNAM. The alternate idea similar to the yu draft seems to contradict > > the statement that SIP isn't a database query protocol. If anyone is > > already doing something like this or has plans I'd love to hear about > > it. > > > > John > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Monday, February 02, 2004 11:29 PM > > > To: Hearty, John > > > Cc: sipping@ietf.org; Peterson, Jon > > > Subject: Re: [Sipping] TCAP tunneling > > > > > > SIP isnt a database query protocol, and cnam is just a DB query > > service. > > > As such, I would think that enum would be an appropriate > > technique for > > > this. Any other DB query mechanism will do as well. > > > > > > Another idea would be to use a redirect service, similar to what has > > > been proposed in the past for LNP: > > > > > > http://www.watersprings.org/pub/id/draft-yu-sip-np-02.txt > > > > > > except that a request for a number would be redirected to a Contact > > > which contains that number plus the display name, representing the > > > calling name. > > > > > > -Jonathan R. > > > > > > Hearty, John wrote: > > > > Other than the miller draft below, is there any SIP standard > > proposed to > > > > carry cnam queries? > > > > > > > > John Hearty > > > > Level3 > > > > > > > > > > > >>-----Original Message----- > > > >>From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On > > Behalf > > > > > > > > Of > > > > > > > >>Arjun Roychowdhury > > > >>Sent: Monday, February 02, 2004 7:25 AM > > > >>To: Banibrata Dutta > > > >>Cc: kagarwal@cedarpointcom.com; ranjit.avasarala@wipro.com; > > > >>sipping@ietf.org; sipping-admin@ietf.org > > > >>Subject: RE: [Sipping] TCAP tunneling > > > >> > > > >>Actually, there _is_ an independant draft on how to carry TCAP in > > SIP. > > > >>http://www.ietf.org/internet-drafts/draft-miller-sip-tcap-00.txt > > > >> > > > >>Its another matter whether this is the right thing to do or not > > > > > > > > (please > > > > > > > >>refer to old archives for the debates). > > > >>Kaitaki, you may want to read the above draft as well as the > > > > > > > > discussions > > > > > > > >>on it to conclude for yourself which is the preferred > > method in your > > > >>deployment scenario. > > > >> > > > >>regds > > > >>arjun > > > >> > > > >> > > > >>-- > > > >>Arjun Roychowdhury @ Hughes Software Systems > > > >>11717 Exploration Lane, Germantown MD 20876 > > > >>(O): 301 212 7860 > > > >>VOIP: (SIP) 10303@fwd.pulver.com (PSTN alias:360-207-0467) > > > >> > > > >> > > > >> > > > >> > > > >>"Banibrata Dutta" > > > >>Sent by: sipping-admin@ietf.org > > > >>02/02/2004 12:25 AM > > > >> > > > >> > > > >> To: , > > > > > > > > , > > > > > > > >> > > > >> cc: > > > >> Subject: RE: [Sipping] TCAP tunneling > > > >> > > > >> > > > >>hi, > > > >> > > > >>franly, i'd say that, it depends on your motivation/reason to use > > SIP > > > >>for > > > >>tunneling TCAP. of course you can tunnel TCAP, but why you'd want > > to, > > > > > > > > is > > > > > > > >>a justification you'd have to work out. AFAIK, there's not > > ietf-draft > > > >>that > > > >>says, how. > > > >> > > > >>you can obviously tunnel TCAP query in an INVITE or INFO for that > > > > > > > > matter > > > > > > > >>(ideally in INVITE s.t. a SIP-dialog is also created which may be > > used > > > >>to > > > >>model the TCAP dialog as well, perhaps!). the ASN.1 BER > > encoded TCAP > > > >>messages may then reside within the body of a multi-part > > (MIME) enc, > > > >>INVITE. > > > >> > > > >>infact 1 reason i see where this may make sense is that you would > > > > > > > > rather > > > > > > > >>not have two stacks s.a. SIGTRAN and SIP for signalling transport, > > and > > > >>use > > > >>SIP as the *only* signalling solution, i.e. for the signalling > > > >>application > > > >>as well as for signalling transport, and support > > legacy/TCAP apps by > > > >>tunneling > > > >>them within SIP. but then, you generally have the constraints of > > > >>not-enough- > > > >>space, (for 2 stacks) only on resource-limited devices, s.a. > > > > > > > > hand-sets, > > > > > > > >>embedded devices etc., but i am unable see (yet), how TCAP can be > > > >>related to > > > >>such devices. > > > >> > > > >>my 2 cents, > > > >>Banibrata Dutta, > > > >> Hewlett-Packard ISO (P) Ltd, > > > >> 29, Cunningham Road, > > > >> Bangalore - 560052 > > > >> Ph: +91-80-22051796 > > > >> > > > >> > > > >>>-----Original Message----- > > > >>>From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > >>>On Behalf Of ranjit.avasarala@wipro.com > > > >>>Sent: Monday, February 02, 2004 10:20 AM > > > >>>To: kagarwal@cedarpointcom.com; sipping@ietf.org > > > >>>Subject: RE: [Sipping] TCAP tunneling > > > >>> > > > >>> > > > >>>Hi > > > >>> TCAP is used for Transaction Capabilities i.e database > > > >>>related while SIP with ISUP tunneling is used between MGCs. > > > >>>So I don't think TCAP can be tunneled in SIP. > > > >>> > > > >>>Ranjit > > > >>>Ph: 8520408/16 extn: 2173 > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>-----Original Message----- > > > >>>From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > >>>On Behalf Of Kaitki Agarwal > > > >>>Sent: Monday, February 02, 2004 8:28 AM > > > >>>To: sipping@ietf.org > > > >>>Subject: [Sipping] TCAP tunneling > > > >>> > > > >>> > > > >>>Hi > > > >>> Can we tunnel tcap message in SIP as we do ISUP. If not why. > > > >>> > > > >>>Thanks > > > >>>Kaitki > > > >>>Jj~Yzy=i~Rz}y > > > >>> > > > >>>_______________________________________________ > > > >>>Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > >>>This list is for NEW development of the application of SIP > > > >>>Use sip-implementors@cs.columbia.edu for questions on current > > > >>>sip Use sip@ietf.org for new developments of core SIP > > > >>> > > > >> > > > >> > > > >>_______________________________________________ > > > >>Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > >>This list is for NEW development of the application of SIP > > > >>Use sip-implementors@cs.columbia.edu for questions on current sip > > > >>Use sip@ietf.org for new developments of core SIP > > > >> > > > >> > > > >> > > > >> > > > >>_______________________________________________ > > > >>Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > >>This list is for NEW development of the application of SIP > > > >>Use sip-implementors@cs.columbia.edu for questions on current sip > > > >>Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Technology Officer Parsippany, NJ > > 07054-2711 > > > dynamicsoft > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 12:12:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02851 for ; Thu, 12 Feb 2004 12:12:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKO5-0005SM-2t for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 12:12:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CHCTwM020968 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 12:12:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKO4-0005S7-T5 for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 12:12:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02848 for ; Thu, 12 Feb 2004 12:12:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKO1-000384-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 12:12:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKN7-000323-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 12:11:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArKMh-0002vq-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 12:11:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKMf-00053b-8w; Thu, 12 Feb 2004 12:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKM0-00050p-IR for sipping@optimus.ietf.org; Thu, 12 Feb 2004 12:10:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02813 for ; Thu, 12 Feb 2004 12:10:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKLx-0002tK-00 for sipping@ietf.org; Thu, 12 Feb 2004 12:10:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKL7-0002no-00 for sipping@ietf.org; Thu, 12 Feb 2004 12:09:25 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ArKKC-0002bG-00 for sipping@ietf.org; Thu, 12 Feb 2004 12:08:28 -0500 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 i1CH7vu5005414; Thu, 12 Feb 2004 09:07:57 -0800 (PST) Received: from [10.32.245.153] (stealth-10-32-245-153.cisco.com [10.32.245.153]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMH70669; Thu, 12 Feb 2004 09:07:56 -0800 (PST) Date: Thu, 12 Feb 2004 12:07:54 -0500 From: David Oran To: "Drage, Keith (Keith)" , sipping@ietf.org Subject: RE: [Sipping] Concern within sos ID - user addresses reserved Message-ID: <2147483647.1076587674@[10.32.245.153]> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EFF1@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00439EFF1@en0033exch001u.uk.luce nt.com> X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Thursday, February 12, 2004 1:54 PM +0000 "Drage, Keith (Keith)" wrote: > With a view of trying to borrow decisions from elsewhere. > > In 3GPP when the phone recognises that it is an emergency call, and needs > to identify the type of emergency call, then it has access to signal > categories with the following names (ref 3GPP TS 22.101): > > ------------------------------ > - Police > - Ambulance > - Fire Brigade > - Marine Guard > - Mountain Rescue > - Spare, at least [three] different types > ----------------------------- > > which results in a coding accompanying the call establishment of (ref > 3GPP TS 24.008 table 10.5.135d) > > -------------------------- > Emergency Service Category Value (octet 3) > The meaning of the Emergency Category Value is derived from the following > settings (Please see 3GPP TS 22.101 clause 8): Bit 1 Police > Bit 2 Ambulance > Bit 3 Fire Brigade > Bit 4 Marine Guard > Bit 5 Mountain Rescue > Bits 6,7,8 are spare and set to "0" > > Mobile station may set one or more bits to "1" > If more than one bit is set to "1", routing to a combined Emergency > centre (e.g. ambulance and fire brigade in Japan) is required. If the MSC > can not match the received service category to any of the emergency > centres, it shall route the call to an operator defined default emergency > centre. > > If no bit is set to "1", the MSC shall route the Emergency call to an > operator defined default emergency centre ------------------------- > > These terms are at least accepted by multiple SDOs in the international > community for transposition into their national standards. > > I also note that 3GPP does have the capability of signalling multiple > preferences - this left me wondering whether we would be better off > trying to follow that, possibly with a single emergency uri, but with the > possibility of signalling category as a URI parameter with a list of > values. Any thoughts on this? > Actually, this seems like ideal fodder for caller prefs, no? > regards > > Keith > > >> -----Original Message----- >> From: Andrew Allen [mailto:aallen@rim.net] >> Sent: 11 February 2004 16:57 >> To: mhammer@cisco.com; sipping@ietf.org >> Subject: Re: [Sipping] Concern within sos ID - user addresses reserved >> >> >> >> >> How about sos.medical then since that outlines the type of >> emergency. I agree that rescue may be confused with the others. >> >> Andrew >> -------------------------- >> Andrew Allen >> Manager Standards >> Research In Motion Ltd >> BlackBerry Mobile +1 847 809 8636 >> European Mobile +358 50 467 5870 >> http://www.rim.com/ >> >> Sent from my BlackBerry Wireless Handheld >> >> >> -----Original Message----- >> From: Michael Hammer >> To: sipping@ietf.org >> Sent: Wed Feb 11 10:45:29 2004 >> Subject: Re: [Sipping] Concern within sos ID - user addresses reserved >> >> At 03:55 PM 2/10/2004 -0600, James M. Polk wrote: >> > sos.fire fire brigade >> > sos.rescue ambulance (rescue) >> > sos.marine marine guard >> > sos.police police (law enforcement) >> > sos.mountain mountain rescue >> >> The second sub-address seems vague to me. Rescue could mean many >> things. Perhaps, I need to be rescued from a fashion >> emergency. :) Would >> something like: >> >> sos.medic medical (doctor, nurse, paramedic team) >> >> be more descriptive? >> >> Also, with respect to registrations, I could see commercial interests >> wanting to get into the act, such as an sos.fashion that I hinted at >> above. Is there some guidance necessary to IANA? Do we >> expect that the >> IETF WGs will act as arbiters for this? >> >> Second, wrt location information reporting, is there any need for a >> convention for providing a URL to which a receiving ECC can >> SUBSCRIBE to >> get location updates from either the UA or a network element >> that is doing >> triangulation. I am wondering if something like the following can be >> inserted into the emergency INVITE: >> >> Call-Info: >> ;purpose=location >> >> Mike >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 12:51:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04332 for ; Thu, 12 Feb 2004 12:51:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKyv-0000qG-EP for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 12:50:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CHoXHl003230 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 12:50:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKyv-0000q1-6X for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 12:50:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04325 for ; Thu, 12 Feb 2004 12:50:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKyr-0007Eu-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 12:50:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKxu-00077m-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 12:49:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArKxS-00071N-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 12:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKxR-0000Re-Cd; Thu, 12 Feb 2004 12:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKwn-0000Pa-FU for sipping@optimus.ietf.org; Thu, 12 Feb 2004 12:48:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04221 for ; Thu, 12 Feb 2004 12:48:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKwj-0006z7-00 for sipping@ietf.org; Thu, 12 Feb 2004 12:48:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKvn-0006sb-00 for sipping@ietf.org; Thu, 12 Feb 2004 12:47:20 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ArKuu-0006hf-00 for sipping@ietf.org; Thu, 12 Feb 2004 12:46:24 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1CHjlr01274 for ; Thu, 12 Feb 2004 11:45:50 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 12 Feb 2004 17:45:46 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00B1B1F94@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Henning Schulzrinne Cc: sipping@ietf.org Subject: RE: [Sipping] Concern within sos ID - user addresses reserved Date: Thu, 12 Feb 2004 17:45:45 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I guess if we did things the way 3GPP treats circuited switched emergency calls, it would be along the lines of caller preferences, with a Request-Disposition header parameter indicating route-emergency or some such like (and a Proxy-Require header as specified in callerprefs). Any Request-URI would then be totally ignored, and we would not need an sos* uri to be defined at all. My wondering below was as to whether we could define a single sos* uri, and deal with different types of emergency service providers by a URI-parameter attached to the Request-URI. SIPPING, you are welcome to pull either of these to bits. regards Keith > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 12 February 2004 14:16 > To: Drage, Keith (Keith) > Cc: sipping@ietf.org > Subject: Re: [Sipping] Concern within sos ID - user addresses reserved > > > Interesting. The selection sounds like caller preferences to me. The > nice thing about that is that you might be able to use existing > techniques to match up services and destinations. > > For example, this could be considered a sip.class value, extending > 'home' and 'business', or a new media feature tag, either specific to > emergency services or a more generic service identifier. (The latter > does invite the fashion emergency and roadside repair > services into the > same namespace.) > > Drage, Keith (Keith) wrote: > > > With a view of trying to borrow decisions from elsewhere. > > > > In 3GPP when the phone recognises that it is an emergency > call, and needs to identify the type of emergency call, then > it has access to signal categories with the following names > (ref 3GPP TS 22.101): > > > > ------------------------------ > > - Police > > - Ambulance > > - Fire Brigade > > - Marine Guard > > - Mountain Rescue > > - Spare, at least [three] different types > > ----------------------------- > > > > which results in a coding accompanying the call > establishment of (ref 3GPP TS 24.008 table 10.5.135d) > > > > -------------------------- > > Emergency Service Category Value (octet 3) > > The meaning of the Emergency Category Value is derived from > the following settings (Please see 3GPP TS 22.101 clause 8): > > Bit 1 Police > > Bit 2 Ambulance > > Bit 3 Fire Brigade > > Bit 4 Marine Guard > > Bit 5 Mountain Rescue > > Bits 6,7,8 are spare and set to "0" > > > > Mobile station may set one or more bits to "1" > > If more than one bit is set to "1", routing to a combined > Emergency centre (e.g. ambulance and fire brigade in Japan) > is required. If the MSC can not match the received service > category to any of the emergency centres, it shall route the > call to an operator defined default emergency centre. > > > > If no bit is set to "1", the MSC shall route the Emergency > call to an operator defined default emergency centre > > ------------------------- > > > > These terms are at least accepted by multiple SDOs in the > international community for transposition into their national > standards. > > > > I also note that 3GPP does have the capability of > signalling multiple preferences - this left me wondering > whether we would be better off trying to follow that, > possibly with a single emergency uri, but with the > possibility of signalling category as a URI parameter with a > list of values. Any thoughts on this? > > > > regards > > > > Keith > > > > > > > >>-----Original Message----- > >>From: Andrew Allen [mailto:aallen@rim.net] > >>Sent: 11 February 2004 16:57 > >>To: mhammer@cisco.com; sipping@ietf.org > >>Subject: Re: [Sipping] Concern within sos ID - user > addresses reserved > >> > >> > >> > >> > >>How about sos.medical then since that outlines the type of > >>emergency. I agree that rescue may be confused with the others. > >> > >>Andrew > >>-------------------------- > >>Andrew Allen > >>Manager Standards > >>Research In Motion Ltd > >>BlackBerry Mobile +1 847 809 8636 > >>European Mobile +358 50 467 5870 > >>http://www.rim.com/ > >> > >>Sent from my BlackBerry Wireless Handheld > >> > >> > >>-----Original Message----- > >>From: Michael Hammer > >>To: sipping@ietf.org > >>Sent: Wed Feb 11 10:45:29 2004 > >>Subject: Re: [Sipping] Concern within sos ID - user > addresses reserved > >> > >>At 03:55 PM 2/10/2004 -0600, James M. Polk wrote: > >> > >>> sos.fire fire brigade > >>> sos.rescue ambulance (rescue) > >>> sos.marine marine guard > >>> sos.police police (law enforcement) > >>> sos.mountain mountain rescue > >> > >>The second sub-address seems vague to me. Rescue could mean many > >>things. Perhaps, I need to be rescued from a fashion > >>emergency. :) Would > >>something like: > >> > >> sos.medic medical (doctor, nurse, paramedic team) > >> > >>be more descriptive? > >> > >>Also, with respect to registrations, I could see commercial > interests > >>wanting to get into the act, such as an sos.fashion that I > hinted at > >>above. Is there some guidance necessary to IANA? Do we > >>expect that the > >>IETF WGs will act as arbiters for this? > >> > >>Second, wrt location information reporting, is there any need for a > >>convention for providing a URL to which a receiving ECC can > >>SUBSCRIBE to > >>get location updates from either the UA or a network element > >>that is doing > >>triangulation. I am wondering if something like the > following can be > >>inserted into the emergency INVITE: > >> > >>Call-Info: > >>;purpose=location > >> > >>Mike > >> > >> > >>_______________________________________________ > >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >>This list is for NEW development of the application of SIP > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sip@ietf.org for new developments of core SIP > >> > >> > >>_______________________________________________ > >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >>This list is for NEW development of the application of SIP > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sip@ietf.org for new developments of core SIP > >> > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 12:51:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04335 for ; Thu, 12 Feb 2004 12:51:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKyv-0000qY-S9 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 12:50:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CHoXij003248 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 12:50:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKyv-0000qJ-Oz for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 12:50:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04328 for ; Thu, 12 Feb 2004 12:50:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKys-0007F3-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 12:50:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKxv-00077u-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 12:49:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArKxS-00071O-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 12:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKxS-0000SA-Bw; Thu, 12 Feb 2004 12:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKwr-0000Pf-JV for sipping@optimus.ietf.org; Thu, 12 Feb 2004 12:48:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04224 for ; Thu, 12 Feb 2004 12:48:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKwn-0006zj-00 for sipping@ietf.org; Thu, 12 Feb 2004 12:48:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKvr-0006tX-00 for sipping@ietf.org; Thu, 12 Feb 2004 12:47:24 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ArKv6-0006hi-00 for sipping@ietf.org; Thu, 12 Feb 2004 12:46:36 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1CHjlD09727 for ; Thu, 12 Feb 2004 11:45:51 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 12 Feb 2004 17:45:46 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00B1B1F93@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sipping@ietf.org Subject: RE: [Sipping] Other concerns within sos ID Date: Thu, 12 Feb 2004 17:45:45 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Not sure we want, or need, to go there. We are meant to be defining the interface at the SIP level, and whether the buttons are little blue square ones or big red round ones does not make a lot of difference to that. There are around 1 billion GSM phones out there, all of which are designed to do as much as possible to identify emergency calls in the terminal and make a dedicated emergency call. They all have the capability of implementing options of recognising that from dialled keys, menu buttons or special keys - but the user interface functionality is all not specified, and works perfectly well without being specified. regards Keith > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortelnetworks.com] > Sent: 11 February 2004 20:58 > To: Michael Hammer > Cc: Mpierce1@aol.com; oran@cisco.com; jmpolk@cisco.com; > sipping@ietf.org > Subject: Re: [Sipping] Other concerns within sos ID > > > The human factors aspect of this stuff has traditionally been > the domain of the > ITU-T. I have a feeling they should be brought into the > discussion. I would have > to check, but the relevant experts used to be located in > Study Group 2. > > Michael Hammer wrote: > > > One additional question that was touched on in this email: > > > > If an sos URI contains a domain name, I presume that a proxy will > > forward the request based on that domain name and never look at the > > local part containing the "sos.xxx". Is that correct? > > > > If so, does that mean that the proxy in that domain is > expected to look > > at the location information and forward to the appropriate > ECC proxy? > > > > As for internationalization, that could get out of hand. > Was the intent > > that these URIs are machine readable only? I suspect that some > > internationally recognized icons on the user agents that > translate into > > these URIs will be needed. But, that could be tricky as well: > > > > sos.fire picture of flames > > sos.rescue picture of Red Cross/Crescent? > > sos.police picture of badge/police belt? > > sos.marine picture of boat + cross/crescent? > > sos.mountain picture of mountain + cross/crescent? > > > > But those icons are phone implementation details. > > > > Mike > > > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 15:44:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13719 for ; Thu, 12 Feb 2004 15:44:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNgK-0002wH-7K for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 15:43:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CKhWdv011293 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 15:43:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNgK-0002w4-3l for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 15:43:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13697 for ; Thu, 12 Feb 2004 15:43:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNgG-0001FR-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 15:43:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNfP-0001A3-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 15:42:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArNf0-00014G-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 15:42:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNet-0002cU-5A; Thu, 12 Feb 2004 15:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNeM-0002ai-4L for sipping@optimus.ietf.org; Thu, 12 Feb 2004 15:41:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13576 for ; Thu, 12 Feb 2004 15:41:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNeI-00012e-00 for sipping@ietf.org; Thu, 12 Feb 2004 15:41:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNdP-0000xN-00 for sipping@ietf.org; Thu, 12 Feb 2004 15:40:32 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ArNcs-0000ri-00 for sipping@ietf.org; Thu, 12 Feb 2004 15:39:58 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1CKdbNr003417; Thu, 12 Feb 2004 15:39:38 -0500 (EST) Message-ID: <402BE47F.1090301@dynamicsoft.com> Date: Thu, 12 Feb 2004 15:39:27 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hearty, John" CC: sipping@ietf.org, "Peterson, Jon" Subject: Re: [Sipping] TCAP tunneling References: <3F75233A2E57CC468B35F3B1FAF71EC013AB37@idc1exc0004.corp.global.level3.com> In-Reply-To: <3F75233A2E57CC468B35F3B1FAF71EC013AB37@idc1exc0004.corp.global.level3.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hearty, John wrote: > In looking at the ENUM RFC, it looks like NAPTR records are used, and > they convert E.164 numbers to URIs. The syntax for the URIs does not > appear to allow for Display Names, which is what I believe needs to be > populated when forwarding SIP messages. A URI can represent just about anything. I didnt find a URN namespace defined for containing people names; I suspect this is because of difficulty in uniqueness. But, in principle one could do: urn:people:Jonathan.D.Rosenberg In this case you would need to define an enumservices that maps phone numbers to people URNs. > I suppose we could still do TXT > type DNS records for this, but can't find any standards specific to > CNAM. The alternate idea similar to the yu draft seems to contradict > the statement that SIP isn't a database query protocol. Well, let me clarify. SIP is not itself a database protocol. However, when a DB query is involved in the process of proxying a request, you can access a SIP service that effectively performs a proxy operation to the result of the DB lookup. Fardad writes: > CNAM is a bit different since we are dealing with the calling party > information. I am a bit confused about Jonathan's comment regarding adding > the CNAM information to the Contact header. It seems that the right approach > would be for Proxies to add a PAI with display name. Looking at RFC3325, it > seems that PAI can also be present in 3XX responses. So potentially > redirectors can also add CNAM information by adding a PAI. Redirectors would not add a PAI; it says the wrong thing. It would assert the identity of the element generating the response, which is not what you want here. The redirect would look like this: SIP/2.0 301 Name Added Contact: sip:john@example.edu?P-Asserted-ID=John%20Example%20 In other words, the redirected-to URI contains a header parameter, which the "requesting" proxy would automatically populate into the outgoing request. Of course it would need to trust the source of the header, as a proxy should not normally accept a redirect with a p-asserted-id. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 15:57:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14866 for ; Thu, 12 Feb 2004 15:57:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNsx-0004u4-HJ for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 15:56:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CKuZea018842 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 15:56:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNsx-0004tp-D8 for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 15:56:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14851 for ; Thu, 12 Feb 2004 15:56:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNst-00033t-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 15:56:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNrz-0002xU-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 15:55:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArNrb-0002rY-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 15:55:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNrT-0004PA-IE; Thu, 12 Feb 2004 15:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNqu-0004Ml-CO for sipping@optimus.ietf.org; Thu, 12 Feb 2004 15:54:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14671 for ; Thu, 12 Feb 2004 15:54:26 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNqq-0002p8-00 for sipping@ietf.org; Thu, 12 Feb 2004 15:54:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNpr-0002iJ-00 for sipping@ietf.org; Thu, 12 Feb 2004 15:53:24 -0500 Received: from imo-m20.mx.aol.com ([64.12.137.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNoy-0002Tc-00 for sipping@ietf.org; Thu, 12 Feb 2004 15:52:28 -0500 Received: from Mpierce1@aol.com by imo-m20.mx.aol.com (mail_out_v36_r4.12.) id o.3c.3afbf69f (4380); Thu, 12 Feb 2004 15:51:50 -0500 (EST) Message-ID: <3c.3afbf69f.2d5d4166@aol.com> Date: Thu, 12 Feb 2004 15:51:50 EST Subject: Re: [Sipping] Concern within sos ID - user addresses reserved To: drage@lucent.com, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_3c.3afbf69f.2d5d4166_boundary" X-Mailer: 6.0 for Windows XP sub 51 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 --part1_3c.3afbf69f.2d5d4166_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/12/2004 8:58:35 AM Eastern Standard Time, drage@lucent.com writes: > ... I also note that 3GPP does have the capability of signalling multiple preferences - this left me wondering whether we would be better off trying to follow that, > possibly with a single emergency uri, but with the possibility of > signalling category as a URI parameter with a list of values. Any thoughts on this? > It's always good to use other standards as the base. This list of "subadresses" is good. But I still don't see how a 3GPP phone can translate number dialed into one of these, unless it knows the local dial plan, or knows all dial plans and knows its location. Does the 3GPP spec mean that, if someone dials 911 in the US, that all bits must be set? Mike Pierce --part1_3c.3afbf69f.2d5d4166_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/12/2004 8:58:35 AM Eastern Standard Time, drage@lucent.com writes:


...
I also n= ote that 3GPP does have the capability of signalling multiple preferences -=20= this left me wondering whether we would be better off trying to follow that,=
possibly with a single e= mergency uri, but with the possibility of signalling category as a URI param= eter with a list of values. Any thoughts on this?

It's always good to use other standards as the base. This list of "su= badresses" is good. But I still don't see how a 3GPP phone can translate num= ber dialed into one of these, unless it knows the local dial plan, or knows=20= all dial plans and knows its location.

Does the 3GPP spec mean that, if someone dials 911 in the US, that all b= its must be set?

Mike Pierce

--part1_3c.3afbf69f.2d5d4166_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 15:57:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14884 for ; Thu, 12 Feb 2004 15:57:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNsy-0004uM-76 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 15:56:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CKuar4018860 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 15:56:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNsy-0004u7-2I for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 15:56:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14855 for ; Thu, 12 Feb 2004 15:56:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNsu-00033z-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 15:56:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNs0-0002xc-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 15:55:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArNrb-0002rZ-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 15:55:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNrV-0004Pl-16; Thu, 12 Feb 2004 15:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNqw-0004Mw-M8 for sipping@optimus.ietf.org; Thu, 12 Feb 2004 15:54:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14684 for ; Thu, 12 Feb 2004 15:54:28 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNqt-0002pS-00 for sipping@ietf.org; Thu, 12 Feb 2004 15:54:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNq0-0002jU-00 for sipping@ietf.org; Thu, 12 Feb 2004 15:53:33 -0500 Received: from imo-r02.mx.aol.com ([152.163.225.98]) by ietf-mx with esmtp (Exim 4.12) id 1ArNpI-0002XC-00 for sipping@ietf.org; Thu, 12 Feb 2004 15:52:48 -0500 Received: from Mpierce1@aol.com by imo-r02.mx.aol.com (mail_out_v36_r4.12.) id 7.1df.195c1e24 (4380); Thu, 12 Feb 2004 15:52:01 -0500 (EST) Message-ID: <1df.195c1e24.2d5d4171@aol.com> Date: Thu, 12 Feb 2004 15:52:01 EST Subject: Re: [Sipping] Other concerns within sos ID To: hgs@cs.columbia.edu, Brian.Rosen@marconi.com CC: oran@cisco.com, jmpolk@cisco.com, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1df.195c1e24.2d5d4171_boundary" X-Mailer: 6.0 for Windows XP sub 51 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 --part1_1df.195c1e24.2d5d4171_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/11/2004 2:18:51 PM Eastern Standard Time, hgs@cs.columbia.edu writes: In general, I think the correct long-term user interface solution is to have a hotkey or address book entry *with user confirmation* rather than having users trying to remember digit strings. The digit string model currently works rather badly for the PSTN - do you know, without looking at the hotel phone card insert, whether you need to dial 9-911, 0, 911, 0-911 or some other combination to get emergency help in a US hotel, let alone in some hotel in a foreign country? [MAP] The digit string model works badly only when there is a lack of standardization. The solution is to push for standards, which has been happening in the US for many years. I suspect that "9" is prettty much "standard" in the US to get an outside line from a PBX, and "911" is pretty much "standard" in the US, so 9-911 almost always works. (I believe some jurisdictions have mandated this operation.) It's easy for a PBX to also interpret 911 itself as meaning the same thing, since no outside number begins with "11" in the US as far as I know, and the PBX can't have an internal number of "911" if "9" gets an external line. I don't know if any PBXs do this. (I'm not going to try!) The solution to lack of full standardization is not to create yet another system, and I think the emergency industry (and US regulators) would have a problem with this. If the user's terminal has a hotkey for emergency, what possibilities are there for a "user confirmation"? A voice message that says: "If you really meant it, push the button again harder"? Or if you click on an icon, a confirmation window pops up asking if you really meant it? I really can't see any "confirmation" procedure as being better than simply dialing the 3-digit emergency code (or "9" plus the 3-digits) that the government has spent millions publicizing. Any such "confirmation" procedure would have serious accessibility issues (for blind, deaf, illiterate, etc.) I don't think that a hotkey or address book entry, even with a "user confirmation", is the correct long-term user interface solution. "Remembering" digit strings for an emergency is not a problem that needs solving. On the other hand, if foreign travellers in the US not knowing our emergency number were really a problem, then it should be solved (in the US) by pushing for acceptance of 112, 118, 999 and maybe a few others as emergency numbers in our dial plan, even without SIP phones. This is not solely an IP phone or SIP issue. Mike Pierce --part1_1df.195c1e24.2d5d4171_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/11/2004 2:18:51 PM Eastern Standard Time, hgs@cs.columbia.edu writes= :


In general, I think the correct long-term user interface solution is to=20
have a hotkey or address book entry *with user confirmation* rather than= =20
having users trying to remember digit strings. The digit string model=20
currently works rather badly for the PSTN - do you know, without looking= =20
at the hotel phone card insert, whether you need to dial 9-911, 0, 911,=20
0-911 or some other combination to get emergency help in a US hotel, let= =20
alone in some hotel in a foreign country?


[MAP] The digit string model works badly only when there is a lack of st= andardization. The solution is to push for standards, which has been happeni= ng in the US for many years. I suspect that "9" is prettty much "standard" i= n the US to get an outside line from a PBX, and "911" is pretty much "standa= rd" in the US, so 9-911 almost always works. (I believe some jurisdictions h= ave mandated this operation.) It's easy for a PBX to also interpret 911 itse= lf as meaning the same thing, since no outside number begins with "11" in th= e US as far as I know, and the PBX can't have an internal number of "911" if= "9" gets an external line. I don't know if any PBXs do this. (I'm not going= to try!)

The solution to lack of full standardization is not to create yet anothe= r system, and I think the emergency industry (and US regulators) would have=20= a problem with this.

If the user's terminal has a hotkey for emergency, what possibilities ar= e there for a "user confirmation"? A voice message that says: "If you really= meant it, push the button again harder"? Or if you click on an icon, a conf= irmation window pops up asking if you really meant it? I really can't see an= y "confirmation" procedure as being better than simply dialing the 3-digit e= mergency code (or "9" plus the 3-digits) that the government has spent milli= ons publicizing. Any such "confirmation" procedure would have serious access= ibility issues (for blind, deaf, illiterate, etc.)

I don't think that a hotkey or address book entry, even with a "user con= firmation", is the correct long-term user interface solution. "Remembering"=20= digit strings for an emergency is not a problem that needs solving.

On the other hand, if foreign travellers in the US not knowing our emerg= ency number were really a problem, then it should be solved (in the US) by p= ushing for acceptance of 112, 118, 999 and maybe a few others as emergency n= umbers in our dial plan, even without SIP phones. This is not solely an IP p= hone or SIP issue.

Mike Pierce

--part1_1df.195c1e24.2d5d4171_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 16:11:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16148 for ; Thu, 12 Feb 2004 16:11:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArO6k-0006g6-1y for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 16:10:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CLAnsu025664 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 16:10:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArO6j-0006fr-Rk for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 16:10:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16115 for ; Thu, 12 Feb 2004 16:10:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArO6g-0004xj-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 16:10:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArO62-0004pZ-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 16:10:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArO4z-0004f5-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 16:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArO4z-0006SU-VJ; Thu, 12 Feb 2004 16:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArO4X-0006Af-Fr for sipping@optimus.ietf.org; Thu, 12 Feb 2004 16:08:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15771 for ; Thu, 12 Feb 2004 16:08:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArO4T-0004aE-00 for sipping@ietf.org; Thu, 12 Feb 2004 16:08:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArO3b-0004Sh-00 for sipping@ietf.org; Thu, 12 Feb 2004 16:07:35 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1ArO2x-0004Mj-00 for sipping@ietf.org; Thu, 12 Feb 2004 16:06:55 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1CL6UkD018015; Thu, 12 Feb 2004 16:06:30 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1CL6SH22675; Thu, 12 Feb 2004 16:06:29 -0500 Message-ID: <402BEAD0.4080101@cs.columbia.edu> Date: Thu, 12 Feb 2004 16:06:24 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: Brian.Rosen@marconi.com, oran@cisco.com, jmpolk@cisco.com, sipping@ietf.org Subject: Re: [Sipping] Other concerns within sos ID References: <1df.195c1e24.2d5d4171@aol.com> In-Reply-To: <1df.195c1e24.2d5d4171@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > If the user's terminal has a hotkey for emergency, what possibilities > are there for a "user confirmation"? A voice message that says: "If you > really meant it, push the button again harder"? Or if you click on an > icon, a confirmation window pops up asking if you really meant it? I > really can't see any "confirmation" procedure as being better than > simply dialing the 3-digit emergency code (or "9" plus the 3-digits) > that the government has spent millions publicizing. Any such > "confirmation" procedure would have serious accessibility issues (for > blind, deaf, illiterate, etc.) This is a UI issue, not for the IETF to solve. Confirmation dialogs, in many forms, are common. Indeed, there are many existing phones that have such buttons: Google randomly found http://www.allphones.us/shop/shopexd.asp?id=180 and http://www.gogotech.com/flypage/1086/Ameriphone_Emergency_Response_Telephones http://www.gogotech.com/flypage/1574/none/Ameriphone_JB-20 The confirmation problem seems to be primarily one for cell phones stuck in back pockets. > > I don't think that a hotkey or address book entry, even with a "user > confirmation", is the correct long-term user interface solution. > "Remembering" digit strings for an emergency is not a problem that needs > solving. The discussion was not about replacing 911 in your home domain. There is no disagreement that this should be available. Quick, what's the emergency number for Korea? > > On the other hand, if foreign travellers in the US not knowing our > emergency number were really a problem, then it should be solved (in the > US) by pushing for acceptance of 112, 118, 999 and maybe a few others as > emergency numbers in our dial plan, even without SIP phones. This is not > solely an IP phone or SIP issue. The current technical solution seems much better and much more likely. > > Mike Pierce > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 17:10:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19104 for ; Thu, 12 Feb 2004 17:10:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArP1c-0003mi-1Y for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 17:09:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CM9a6Y014542 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 17:09:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArP1b-0003mT-U0 for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 17:09:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19097 for ; Thu, 12 Feb 2004 17:09:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArP1X-0002ne-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 17:09:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArP0Y-0002iU-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 17:08:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArP0A-0002dK-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 17:08:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArP07-0003Xe-AP; Thu, 12 Feb 2004 17:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOzY-0003MK-Ej for sipping@optimus.ietf.org; Thu, 12 Feb 2004 17:07:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19001 for ; Thu, 12 Feb 2004 17:07:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArOzU-0002cQ-00 for sipping@ietf.org; Thu, 12 Feb 2004 17:07:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArOyZ-0002YE-00 for sipping@ietf.org; Thu, 12 Feb 2004 17:06:27 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1ArOxq-0002PK-00 for sipping@ietf.org; Thu, 12 Feb 2004 17:05:42 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMGVSZ>; Thu, 12 Feb 2004 22:05:13 -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 1ZGN1BMJ; Thu, 12 Feb 2004 22:05:12 -0000 From: "Conroy, Lawrence (SMTP)" To: Jonathan Rosenberg Cc: sipping@ietf.org, "Hearty, John" , "Peterson, Jon" In-Reply-To: <402BE47F.1090301@dynamicsoft.com> References: <3F75233A2E57CC468B35F3B1FAF71EC013AB37@idc1exc0004.corp.global.level3.com> <402BE47F.1090301@dynamicsoft.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <867AC4EA-5DA7-11D8-A740-00039355516C@roke.co.uk> Content-Transfer-Encoding: 7bit Subject: Re: [Sipping] TCAP tunneling Date: Thu, 12 Feb 2004 22:05:10 +0000 X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi folks, ... and, from my explorations, people commonly use TXT records for names. It's a hack but it works for human displayable items. Anything more complex (like URN stuff) maybe cleaner but requires more work. BTW, often the TXT records I see are 'cos folk haven't set their "split horizon" correctly in BIND. Number -> is a major privacy issue for many, and this will be an issue whatever scheme one uses; NAPTRs use/are DNS so a 'people' URN NAPTR doesn't help. Just my 14 centimes. atb, Lawrence On 12 Feb 2004, at 8:39 pm, Jonathan Rosenberg wrote: > > > Hearty, John wrote: > >> In looking at the ENUM RFC, it looks like NAPTR records are used, and >> they convert E.164 numbers to URIs. The syntax for the URIs does not >> appear to allow for Display Names, which is what I believe needs to be >> populated when forwarding SIP messages. > > A URI can represent just about anything. I didnt find a URN namespace > defined for containing people names; I suspect this is because of > difficulty in uniqueness. But, in principle one could do: > > urn:people:Jonathan.D.Rosenberg > > In this case you would need to define an enumservices that maps phone > numbers to people URNs. > > >> I suppose we could still do TXT >> type DNS records for this, but can't find any standards specific to >> CNAM. The alternate idea similar to the yu draft seems to contradict >> the statement that SIP isn't a database query protocol. > > Well, let me clarify. SIP is not itself a database protocol. However, > when a DB query is involved in the process of proxying a request, you > can access a SIP service that effectively performs a proxy operation > to the result of the DB lookup. > > Fardad writes: >> CNAM is a bit different since we are dealing with the calling party >> information. I am a bit confused about Jonathan's comment regarding >> adding >> the CNAM information to the Contact header. It seems that the right >> approach >> would be for Proxies to add a PAI with display name. Looking at >> RFC3325, it >> seems that PAI can also be present in 3XX responses. So potentially >> redirectors can also add CNAM information by adding a PAI. > > Redirectors would not add a PAI; it says the wrong thing. It would > assert the identity of the element generating the response, which is > not what you want here. The redirect would look like this: > > SIP/2.0 301 Name Added > Contact: > sip:john@example.edu?P-Asserted-ID=John%20Example%20 > > In other words, the redirected-to URI contains a header parameter, > which the "requesting" proxy would automatically populate into the > outgoing request. Of course it would need to trust the source of the > header, as a proxy should not normally accept a redirect with a > p-asserted-id. > > Thanks, > Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 18:06:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21782 for ; Thu, 12 Feb 2004 18:06:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPtl-0002Ws-Jr for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 18:05:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CN5XeJ009716 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 18:05:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPtl-0002Wd-EW for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 18:05:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21733 for ; Thu, 12 Feb 2004 18:05:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArPtg-0000Wd-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 18:05:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArPsj-0000R6-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 18:04:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArPsJ-0000MW-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 18:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPsH-0001u8-Tb; Thu, 12 Feb 2004 18:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPrn-0001d8-Al for sipping@optimus.ietf.org; Thu, 12 Feb 2004 18:03:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21559 for ; Thu, 12 Feb 2004 18:03:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArPri-0000Lp-00 for sipping@ietf.org; Thu, 12 Feb 2004 18:03:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArPqm-0000HP-00 for sipping@ietf.org; Thu, 12 Feb 2004 18:02:28 -0500 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 1ArPq4-00008Y-00 for sipping@ietf.org; Thu, 12 Feb 2004 18:01:45 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i1CN1GM3007532 for ; Thu, 12 Feb 2004 18:01:16 -0500 Received: from d03nm119.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1CN1FHx104338 for ; Thu, 12 Feb 2004 16:01:15 -0700 To: sipping@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: Joseph Herman Date: Thu, 12 Feb 2004 18:01:19 -0500 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 02/12/2004 16:01:15, Serialize complete at 02/12/2004 16:01:15 Content-Type: multipart/alternative; boundary="=_alternative 007ECB9A85256E38_=" Subject: [Sipping] Translating ISDN IE or SS7 optional fields to SIP Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 007ECB9A85256E38_= Content-Type: text/plain; charset="US-ASCII" Is there a document that defines (or proposes) a standard way to map protocol specific information into SIP to be consumed by a UA? SIP-T provides the entire SS7 packet embedded in the SIP message rather than a translation of the fields. I am hoping for a mapping like redirection-number <==> redir-num: SIP header field Is there such a document? Thanks for any info, Joe H. -- Joe Herman IBM Annapolis RM Telephony Solutions 410-571-7117 dzoey@us.ibm.com Everything is wonderful until you know something about it. --=_alternative 007ECB9A85256E38_= Content-Type: text/html; charset="US-ASCII"
Is there a document that defines (or proposes) a standard way to map protocol specific information into SIP to be consumed by a UA?   SIP-T provides  the entire SS7 packet embedded in the SIP message rather than a translation of the fields.   I am hoping for a mapping like

redirection-number <==> redir-num: SIP header field

Is there such a document?

                                        Thanks for any info,
                                        Joe H.

--
Joe Herman
IBM Annapolis RM Telephony Solutions
410-571-7117
dzoey@us.ibm.com

Everything is wonderful until you know something about it.
 --=_alternative 007ECB9A85256E38_=-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 22:43:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05659 for ; Thu, 12 Feb 2004 22:43:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArUDw-0001kq-C5 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 22:42:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D3geKS006737 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 22:42:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArUDw-0001ka-8H for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 22:42:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05628 for ; Thu, 12 Feb 2004 22:42:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArUDq-0005Ch-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 22:42:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArUCt-00057q-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 22:41:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArUCQ-00053j-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 22:41:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArUCM-0001Va-9w; Thu, 12 Feb 2004 22:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArUBz-0001V0-5z for sipping@optimus.ietf.org; Thu, 12 Feb 2004 22:40:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05581 for ; Thu, 12 Feb 2004 22:40:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArUBt-00053E-00 for sipping@ietf.org; Thu, 12 Feb 2004 22:40:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArUAy-0004zH-00 for sipping@ietf.org; Thu, 12 Feb 2004 22:39:37 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ArUAB-0004rB-00 for sipping@ietf.org; Thu, 12 Feb 2004 22:38:47 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1D3bvNr003720; Thu, 12 Feb 2004 22:37:59 -0500 (EST) Message-ID: <402C468B.5060709@dynamicsoft.com> Date: Thu, 12 Feb 2004 22:37:47 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: Henning Schulzrinne , sipping@ietf.org Subject: Re: [Sipping] Concern within sos ID - user addresses reserved References: <475FF955A05DD411980D00508B6D5FB00B1B1F94@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00B1B1F94@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > I guess if we did things the way 3GPP treats circuited switched > emergency calls, it would be along the lines of caller preferences, > with a Request-Disposition header parameter indicating > route-emergency or some such like (and a Proxy-Require header as > specified in callerprefs). Request disposition is purposefully non-extensible, so that is not the place. This sounds like a routing problem to me, in which case the traditional Accept-Contact is the right place. The r-uri would remain plain old sos. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 23:02:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06069 for ; Thu, 12 Feb 2004 23:02:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArUWR-0002Ra-4O for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 23:01:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D41l1R009388 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 23:01:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArUWR-0002RL-18 for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 23:01:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06052 for ; Thu, 12 Feb 2004 23:01:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArUWL-0006fn-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 23:01:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArUVO-0006aa-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 23:00:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArUUq-0006VI-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 23:00:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArUUq-0002EA-Bn; Thu, 12 Feb 2004 23:00:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArUUS-0002CD-3u for sipping@optimus.ietf.org; Thu, 12 Feb 2004 22:59:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05990 for ; Thu, 12 Feb 2004 22:59:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArUUM-0006Ud-00 for sipping@ietf.org; Thu, 12 Feb 2004 22:59:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArUTR-0006QC-00 for sipping@ietf.org; Thu, 12 Feb 2004 22:58:41 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1ArUSr-0006LK-00 for sipping@ietf.org; Thu, 12 Feb 2004 22:58:05 -0500 Received: from bear.cs.columbia.edu (IDENT:B2g1GyooYzAV6MuMiTx8P5RPt5sXWQg0@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1D3vxR5008757 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 12 Feb 2004 22:58:00 -0500 (EST) Received: from cs.columbia.edu (pool-141-153-198-80.mad.east.verizon.net [141.153.198.80]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1D3vwmi005689 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Feb 2004 22:57:59 -0500 Message-ID: <402C4B40.3050304@cs.columbia.edu> Date: Thu, 12 Feb 2004 22:57:52 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Drage, Keith (Keith)" , sipping@ietf.org Subject: Re: [Sipping] Concern within sos ID - user addresses reserved References: <475FF955A05DD411980D00508B6D5FB00B1B1F94@en0033exch001u.uk.lucent.com> <402C468B.5060709@dynamicsoft.com> In-Reply-To: <402C468B.5060709@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Request disposition is purposefully non-extensible, so that is not the > place. This sounds like a routing problem to me, in which case the > traditional Accept-Contact is the right place. The r-uri would remain > plain old sos. That's what I had in mind. Question is whether there should be a generic new 'sip.service' parameter, a more specific emergency-service parameter or whether this should be folded as additional values into 'class'. My inclination would be the first, with a hiearchical scheme. I'm not sure whether there are other services, beyond emergency services, that would or should use this. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 12 23:40:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07282 for ; Thu, 12 Feb 2004 23:40:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArV7C-0004q9-UG for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 23:39:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D4dknB018597 for sipping-archive@odin.ietf.org; Thu, 12 Feb 2004 23:39:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArV7C-0004ps-QE for sipping-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 23:39:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07267 for ; Thu, 12 Feb 2004 23:39:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArV76-0002AH-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 23:39:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArV69-000255-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 23:38:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArV5V-00020L-00 for sipping-web-archive@ietf.org; Thu, 12 Feb 2004 23:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArV5W-0004Yk-4L; Thu, 12 Feb 2004 23:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArV5G-0004Ur-Rg for sipping@optimus.ietf.org; Thu, 12 Feb 2004 23:37:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07211 for ; Thu, 12 Feb 2004 23:37:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArV5B-0001zf-00 for sipping@ietf.org; Thu, 12 Feb 2004 23:37:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArV4H-0001vN-00 for sipping@ietf.org; Thu, 12 Feb 2004 23:36:46 -0500 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1ArV3f-0001qK-00 for sipping@ietf.org; Thu, 12 Feb 2004 23:36:07 -0500 Received: from harvest.india.hp.com (harvest.india.hp.com [15.76.216.203]) by palrel13.hp.com (Postfix) with ESMTP id 34F521C00626; Thu, 12 Feb 2004 20:36:09 -0800 (PST) Received: from nt13192 (nt13192.india.hp.com [15.76.113.192]) by harvest.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id KAA16020; Fri, 13 Feb 2004 10:07:46 +0530 (IST) From: "Banibrata Dutta" To: "'Joseph Herman'" , Subject: RE: [Sipping] Translating ISDN IE or SS7 optional fields to SIP Date: Fri, 13 Feb 2004 10:06:04 +0530 Message-ID: <009601c3f1ea$e3e43150$c0714c0f@nt13192> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01C3F218.FD9C6D50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0097_01C3F218.FD9C6D50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit One quick way would be to check that out by searching the ID-list hosted at the very useful http://softarmor.com/sipping/ site. AFAIK, such a draft doesn't exist. SIP-T is what comes closest (i think). -BDutta. -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Joseph Herman Sent: Friday, February 13, 2004 4:31 AM To: sipping@ietf.org Subject: [Sipping] Translating ISDN IE or SS7 optional fields to SIP Is there a document that defines (or proposes) a standard way to map protocol specific information into SIP to be consumed by a UA? SIP-T provides the entire SS7 packet embedded in the SIP message rather than a translation of the fields. I am hoping for a mapping like redirection-number <==> redir-num: SIP header field Is there such a document? Thanks for any info, Joe H. -- Joe Herman IBM Annapolis RM Telephony Solutions 410-571-7117 dzoey@us.ibm.com Everything is wonderful until you know something about it. ------=_NextPart_000_0097_01C3F218.FD9C6D50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
One=20 quick way would be to check that out by searching the ID-list = hosted=20 at the
very=20 useful http://softarmor.com/sipping/&= nbsp;site.
AFAIK,=20 such a draft doesn't exist. SIP-T is what comes closest (i=20 think).
 
-BDutta.
-----Original Message-----
From:=20 sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of = Joseph Herman
Sent: Friday, February 13, 2004 4:31=20 AM
To: sipping@ietf.org
Subject: [Sipping] = Translating=20 ISDN IE or SS7 optional fields to SIP


Is there a document that defines (or = proposes) a=20 standard way to map protocol specific information into SIP to be = consumed by a=20 UA?   SIP-T provides  the entire SS7 packet embedded in the = SIP=20 message rather than a translation of the fields.   I am hoping = for a=20 mapping like

redirection-number=20 <=3D=3D> redir-num: SIP header field

Is there such a document?

                =    =20                     = Thanks=20 for any info,
  =    =20                     =  =20             Joe H.

--
Joe Herman
IBM Annapolis RM = Telephony=20 Solutions
410-571-7117
dzoey@us.ibm.com

Everything is = wonderful=20 until you know something about = it.
 ------=_NextPart_000_0097_01C3F218.FD9C6D50-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 00:17:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08993 for ; Fri, 13 Feb 2004 00:17:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArVh0-0006nJ-OS for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 00:16:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D5Gk9I026111 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 00:16:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArVh0-0006n4-Jk for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 00:16:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08979 for ; Fri, 13 Feb 2004 00:16:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArVgu-0006Lg-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 00:16:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArVg1-0006Gy-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 00:15:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArVfL-0006CB-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 00:15:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArVfL-0006a6-FB; Fri, 13 Feb 2004 00:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArVf2-0006ZC-Me for sipping@optimus.ietf.org; Fri, 13 Feb 2004 00:14:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08928 for ; Fri, 13 Feb 2004 00:14:39 -0500 (EST) From: mielias@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArVew-0006AG-00 for sipping@ietf.org; Fri, 13 Feb 2004 00:14:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArVe4-00065L-00 for sipping@ietf.org; Fri, 13 Feb 2004 00:13:44 -0500 Received: from 210-210-93-99.lan.sify.net ([210.210.93.99] helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1ArVdA-0005vq-00 for sipping@ietf.org; Fri, 13 Feb 2004 00:12:48 -0500 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i1D5AYD02184; Fri, 13 Feb 2004 10:40:46 +0530 In-Reply-To: Subject: Re: [Sipping] Translating ISDN IE or SS7 optional fields to SIP To: Joseph Herman Cc: sipping@ietf.org X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Fri, 13 Feb 2004 10:41:01 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 02/13/2004 10:41:32 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 RFC 3398 - Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping. This RFC describes a way to perform the mapping between SIP and ISUP (message and parameter level). - Elias Hughes Software Systems http://www.hssworld.com - Joseph Herman To Sent by: sipping@ietf.org sipping-admin@iet cc f.org Subject [Sipping] Translating ISDN IE or 02/13/04 04:31 AM SS7 optional fields to SIP Is there a document that defines (or proposes) a standard way to map protocol specific information into SIP to be consumed by a UA? SIP-T provides the entire SS7 packet embedded in the SIP message rather than a translation of the fields. I am hoping for a mapping like redirection-number <==> redir-num: SIP header field Is there such a document? Thanks for any info, Joe H. -- Joe Herman IBM Annapolis RM Telephony Solutions 410-571-7117 dzoey@us.ibm.com Everything is wonderful until you know something about it. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 02:55:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27214 for ; Fri, 13 Feb 2004 02:55:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYA7-0002Dw-GV for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 02:54:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D7sxTk008542 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 02:54:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYA7-0002Dh-08 for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 02:54:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27175 for ; Fri, 13 Feb 2004 02:54:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArY9z-0004LN-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 02:54:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArY98-0004FC-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 02:53:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArY8F-00048G-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 02:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArY8E-0001oC-Ij; Fri, 13 Feb 2004 02:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArY7L-0001ls-8h for sipping@optimus.ietf.org; Fri, 13 Feb 2004 02:52:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27078 for ; Fri, 13 Feb 2004 02:52:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArY7D-00040m-00 for sipping@ietf.org; Fri, 13 Feb 2004 02:51:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArY6D-0003ub-00 for sipping@ietf.org; Fri, 13 Feb 2004 02:50:57 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1ArY5Q-0003kW-00 for sipping@ietf.org; Fri, 13 Feb 2004 02:50:08 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i1D7nZLc023373 for ; Fri, 13 Feb 2004 01:49:35 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Feb 2004 01:45:22 -0600 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 151RWKM6; Fri, 13 Feb 2004 01:49:36 -0600 Message-ID: <402C8194.1080109@ericsson.com> Date: Fri, 13 Feb 2004 09:49:40 +0200 X-Sybari-Trust: c4b0c8e3 91259930 43af4536 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2004 07:45:22.0171 (UTC) FILETIME=[559E6CB0:01C3F205] Content-Transfer-Encoding: 7bit Subject: [Sipping] Drafts on exploders Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, We have submitted a set of drafts on exploders. The following one provides the requirements we are using and a framework to understand the rest of the drafts. http://users.piuha.net/gonzalo/draft-camarillo-sipping-exploders-02.txt The rest of them can be fetched (until they appear in the archives) from: http://users.piuha.net/gonzalo/draft-camarillo-sipping-uri-list-01.txt http://users.piuha.net/gonzalo/draft-camarillo-sipping-adhoc-management-00.txt http://users.piuha.net/gonzalo/draft-camarillo-sipping-transac-package-00.txt http://users.piuha.net/gonzalo/draft-camarillo-sipping-multiple-refer-00.txt Commments are appreciated, Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 04:43:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00597 for ; Fri, 13 Feb 2004 04:43:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZqY-0001wT-Eu for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 04:42:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D9gse4007458 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 04:42:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZqX-0001wD-Sa for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 04:42:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00585 for ; Fri, 13 Feb 2004 04:42:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZqP-00055O-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 04:42:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZpT-00051f-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 04:41:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArZok-0004xq-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 04:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZoo-0001jC-9t; Fri, 13 Feb 2004 04:41:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZog-0001iN-71 for sipping@optimus.ietf.org; Fri, 13 Feb 2004 04:40:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00478 for ; Fri, 13 Feb 2004 04:40:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZoW-0004xA-00 for sipping@ietf.org; Fri, 13 Feb 2004 04:40:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZnd-0004tG-00 for sipping@ietf.org; Fri, 13 Feb 2004 04:39:54 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1ArZn7-0004oc-00 for sipping@ietf.org; Fri, 13 Feb 2004 04:39:21 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i1D9cmLc007496 for ; Fri, 13 Feb 2004 03:38:48 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Feb 2004 03:34:34 -0600 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 151RW3W4; Fri, 13 Feb 2004 03:38:49 -0600 Message-ID: <402C9B2D.40302@ericsson.com> Date: Fri, 13 Feb 2004 11:38:53 +0200 X-Sybari-Trust: 54818521 91259930 43af4536 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Banibrata Dutta CC: "'sipping'" Subject: Re: [Sipping] Drafts on exploders References: <00e101c3f213$e260f010$c0714c0f@nt13192> In-Reply-To: <00e101c3f213$e260f010$c0714c0f@nt13192> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2004 09:34:34.0843 (UTC) FILETIME=[9750D2B0:01C3F214] Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, > Why do you need a heavy-weight light B2BUA for "exploding". Do you mean light *or* heavy-weight? In any case, you do not want to use a proxy because the services these exploders provide (e.g., conferencing) are provided by B2BUAs, not by proxies. Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 04:54:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00916 for ; Fri, 13 Feb 2004 04:54:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ara1I-0002aQ-CJ for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 04:54:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D9s0pO009939 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 04:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ara1H-0002aE-Ga for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 04:53:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00895 for ; Fri, 13 Feb 2004 04:53:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ara18-0005xg-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 04:53:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ara0D-0005sc-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 04:52:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArZzL-0005nt-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 04:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZzQ-0002Jx-2U; Fri, 13 Feb 2004 04:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZzH-0002Ix-Hm for sipping@optimus.ietf.org; Fri, 13 Feb 2004 04:51:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00831 for ; Fri, 13 Feb 2004 04:51:48 -0500 (EST) From: ranjit.avasarala@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZz8-0005mk-00 for sipping@ietf.org; Fri, 13 Feb 2004 04:51:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZyG-0005ir-00 for sipping@ietf.org; Fri, 13 Feb 2004 04:50:52 -0500 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1ArZxY-0005ZT-00 for sipping@ietf.org; Fri, 13 Feb 2004 04:50:13 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i1D9ncPp008004 for ; Fri, 13 Feb 2004 15:19:38 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Fri, 13 Feb 2004 15:21:16 +0530 Received: from blr-ec-msg03.wipro.com ([10.200.52.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Feb 2004 15:19:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Drafts on exploders Date: Fri, 13 Feb 2004 15:19:37 +0530 Message-ID: Thread-Topic: [Sipping] Drafts on exploders Thread-Index: AcPyFlF6hlqlDdeoQ0CPdt6e43fMyAAAY4ZQ To: , Cc: X-OriginalArrivalTime: 13 Feb 2004 09:49:37.0929 (UTC) FILETIME=[B198CF90:01C3F216] Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi I have one doubt here: so u mean to say that B2BUA behaves as a conference mixer? Thanks Ranjit Ph: 8520408/16 extn: 2173 -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Gonzalo Camarillo Sent: Friday, February 13, 2004 3:09 PM To: Banibrata Dutta Cc: 'sipping' Subject: Re: [Sipping] Drafts on exploders Hello, > Why do you need a heavy-weight light B2BUA for "exploding". Do you mean light *or* heavy-weight? In any case, you do not want to use a proxy because the services these=20 exploders provide (e.g., conferencing) are provided by B2BUAs, not by=20 proxies. Gonzalo =20 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 05:08:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01529 for ; Fri, 13 Feb 2004 05:08:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AraEs-0003zC-Im for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 05:08:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DA82LM015302 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 05:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AraEq-0003yY-FH for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 05:08:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01499 for ; Fri, 13 Feb 2004 05:07:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AraEh-0007L5-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 05:07:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AraDp-0007EZ-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 05:06:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AraCt-00078m-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 05:05:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AraCx-0003a1-CN; Fri, 13 Feb 2004 05:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AraCq-0003ZW-9g for sipping@optimus.ietf.org; Fri, 13 Feb 2004 05:05:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01461 for ; Fri, 13 Feb 2004 05:05:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AraCh-00076u-00 for sipping@ietf.org; Fri, 13 Feb 2004 05:05:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AraBh-00070q-00 for sipping@ietf.org; Fri, 13 Feb 2004 05:04:46 -0500 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1AraAo-0006tz-00 for sipping@ietf.org; Fri, 13 Feb 2004 05:03:50 -0500 Received: from harvest.india.hp.com (harvest.india.hp.com [15.76.216.203]) by palrel13.hp.com (Postfix) with ESMTP id A87301C000A7; Fri, 13 Feb 2004 02:03:51 -0800 (PST) Received: from nt13192 (nt13192.india.hp.com [15.76.113.192]) by harvest.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id PAA24113; Fri, 13 Feb 2004 15:35:29 +0530 (IST) From: "Banibrata Dutta" To: "'Gonzalo Camarillo'" Cc: "'sipping'" Subject: RE: [Sipping] Drafts on exploders Date: Fri, 13 Feb 2004 15:33:46 +0530 Message-ID: <00e301c3f218$ab32b5b0$c0714c0f@nt13192> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <402C9B2D.40302@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Gonzalo, I am sorry, I meant "heavy-weight" only. Okay, isn't then exploder itself a service, but yes it would become a feature they may be used by several services. Confercing is then just another service that uses the exploder feature, right? Won't it be better to take that responsibility out of a B2BUA and put it in the core network (in the proxies) s.t. the explosion happens where it is needed? Let me explain my view as follows:- there are 2 ways:- 1) A single To: header which explodes to multiple INVITES (or other method messages). 2) A single INVITE with multiple To: headers which is understood by a router and split off into multiple INVITE's with single To: headers. in the first case the exploding proxy (or entity) needs access to a explosion database (i.e. group-name -> list of members). this "may be" achieved by DNS mechanisms (i am not even close to being a DNS expert, but i think that it can be done, the same way SOS URI's are transformed into actual ERS/PCAP #s). in the second case the exploding proxy doesn't need a explosion database and the original INVITE anyway had all the info needed to split it off into multiple INVITEs with single To: headers. with these approaches the benefit of "localization" of explosion can be used, i.e. the explosion happens as late as possible, leading to the minimum # of messages in the network, i.e. multiple exploder proxies would exist in the network and it may so happen that the orginal invite with 10 To: headers go split into 2 INVITES with 6 and 4 To: headers respectively at an exploder proxy, and then the INVITE with 6 To:s got split into 2 with 3 To:s each and so on. this way the explosion is "Just-In-Time" and minimal. regards, banibrata dutta. > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Gonzalo Camarillo > Sent: Friday, February 13, 2004 3:09 PM > To: Banibrata Dutta > Cc: 'sipping' > Subject: Re: [Sipping] Drafts on exploders > > > Hello, > > > Why do you need a heavy-weight light B2BUA for "exploding". > > Do you mean light *or* heavy-weight? > > In any case, you do not want to use a proxy because the > services these > exploders provide (e.g., conferencing) are provided by B2BUAs, not by > proxies. > > Gonzalo > > > > This communication is confidential and intended solely for > the addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has > been sent to you in error, please notify the sender by > replying to this transmission and delete the message without > disclosing it. Thank you. > > E-mail including attachments is susceptible to data > corruption, interruption, unauthorized amendment, tampering > and viruses, and we only send and receive e-mails on the > basis that we are not liable for any such corruption, > interception, amendment, tampering or viruses or any > consequences thereof. > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 05:20:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02015 for ; Fri, 13 Feb 2004 05:20:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AraQR-0004rS-OE for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 05:20:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DAJxdf018680 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 05:19:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AraQR-0004rD-Jd for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 05:19:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01994 for ; Fri, 13 Feb 2004 05:19:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AraQI-0000f9-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 05:19:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AraPK-0000a8-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 05:18:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AraOT-0000V3-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 05:17:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AraOZ-0004eA-7g; Fri, 13 Feb 2004 05:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AraOW-0004da-ET for sipping@optimus.ietf.org; Fri, 13 Feb 2004 05:18:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01911 for ; Fri, 13 Feb 2004 05:17:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AraON-0000U7-00 for sipping@ietf.org; Fri, 13 Feb 2004 05:17:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AraNU-0000OR-00 for sipping@ietf.org; Fri, 13 Feb 2004 05:16:57 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly03a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AraMZ-0000E7-00 for sipping@ietf.org; Fri, 13 Feb 2004 05:15:59 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly03a.srv.mailcontrol.com (MailControl) with SMTP id i1DAFNJ3008751; Fri, 13 Feb 2004 10:15:23 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Fri, 13 Feb 2004 10:15:21 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Concern within sos ID - user addresses reserved Date: Fri, 13 Feb 2004 10:15:23 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF1B6@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sipping] Concern within sos ID - user addresses reserved Thread-Index: AcPx5eILNuEsXWGZTw2+GqaXvQWE/gANB/1A From: "Chris Boulton" To: "Henning Schulzrinne" , "Jonathan Rosenberg" Cc: "Drage, Keith (Keith)" , X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable My inclination would be to have a specific emergency service parameter to avoid any confusion in usage. That way we explicitly define emergency routing without confusion. Chris. >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: 13 February 2004 03:58 >To: Jonathan Rosenberg >Cc: Drage, Keith (Keith); sipping@ietf.org >Subject: Re: [Sipping] Concern within sos ID - user addresses reserved > > >> Request disposition is purposefully non-extensible, so that is not the >> place. This sounds like a routing problem to me, in which case the >> traditional Accept-Contact is the right place. The r-uri would remain >> plain old sos. > >That's what I had in mind. Question is whether there should be a generic >new 'sip.service' parameter, a more specific emergency-service parameter >or whether this should be folded as additional values into 'class'. My >inclination would be the first, with a hiearchical scheme. I'm not sure >whether there are other services, beyond emergency services, that would >or should use this. > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 05:27:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02278 for ; Fri, 13 Feb 2004 05:27:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AraX9-0005KV-Cl for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 05:26:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DAQtML020481 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 05:26:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AraX9-0005KG-7z for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 05:26:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02252 for ; Fri, 13 Feb 2004 05:26:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AraX0-0001Au-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 05:26:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AraW5-00015x-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 05:25:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AraVD-00011z-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 05:24:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AraVK-00058u-AG; Fri, 13 Feb 2004 05:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AraVD-00058X-J4 for sipping@optimus.ietf.org; Fri, 13 Feb 2004 05:24:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02191 for ; Fri, 13 Feb 2004 05:24:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AraV4-00010w-00 for sipping@ietf.org; Fri, 13 Feb 2004 05:24:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AraU8-0000xN-00 for sipping@ietf.org; Fri, 13 Feb 2004 05:23:49 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AraTK-0000pl-00 for sipping@ietf.org; Fri, 13 Feb 2004 05:22:59 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i1DAMWfX011736 for ; Fri, 13 Feb 2004 04:22:32 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Feb 2004 04:18:12 -0600 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 151RWQQX; Fri, 13 Feb 2004 04:22:27 -0600 Message-ID: <402CA567.6060907@ericsson.com> Date: Fri, 13 Feb 2004 12:22:31 +0200 X-Sybari-Trust: 36a0ff15 91259930 43af4536 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Banibrata Dutta CC: "'sipping'" Subject: Re: [Sipping] Drafts on exploders References: <00e301c3f218$ab32b5b0$c0714c0f@nt13192> In-Reply-To: <00e301c3f218$ab32b5b0$c0714c0f@nt13192> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2004 10:18:12.0593 (UTC) FILETIME=[AF9DC610:01C3F21A] Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Banibrata, The services we intend to provide using exploders are implemented using B2BUAs. If the services you have in mind can be implemented using only proxies, you do not need to use the mechanisms described in these drafts. Thanks, Gonzalo Banibrata Dutta wrote: > Hi Gonzalo, > > I am sorry, I meant "heavy-weight" only. Okay, isn't then exploder > itself a service, but yes it would become a feature they may be used > by several services. Confercing is then just another service that uses > the exploder feature, right? > > Won't it be better to take that responsibility out of a B2BUA and > put it in the core network (in the proxies) s.t. the explosion happens > where it is needed? Let me explain my view as follows:- > > there are 2 ways:- > > 1) A single To: header which explodes to multiple INVITES (or other > method messages). > 2) A single INVITE with multiple To: headers which is understood by > a router and split off into multiple INVITE's with single To: > headers. > > in the first case the exploding proxy (or entity) needs access to a > explosion database (i.e. group-name -> list of members). this "may be" > achieved by DNS mechanisms (i am not even close to being a DNS > expert, but i think that it can be done, the same way SOS URI's > are transformed into actual ERS/PCAP #s). > > in the second case the exploding proxy doesn't need a explosion database > and the original INVITE anyway had all the info needed to split it off > into multiple INVITEs with single To: headers. > > with these approaches the benefit of "localization" of explosion can be > used, i.e. the explosion happens as late as possible, leading to the > minimum # of messages in the network, i.e. multiple exploder proxies > would exist in the network and it may so happen that the orginal > invite with 10 To: headers go split into 2 INVITES with 6 and 4 To: > headers respectively at an exploder proxy, and then the INVITE with > 6 To:s got split into 2 with 3 To:s each and so on. this way the > explosion is "Just-In-Time" and minimal. > > regards, > banibrata dutta. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 06:58:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06265 for ; Fri, 13 Feb 2004 06:58:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArbxI-0004t9-6H for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 06:58:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DBw0Gb018785 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 06:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArbxI-0004su-2B for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 06:58:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06230 for ; Fri, 13 Feb 2004 06:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arbx8-0001Pq-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 06:57:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArbwA-0001Ke-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 06:56:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArbvM-0001GR-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 06:56:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArbvQ-0004gW-2B; Fri, 13 Feb 2004 06:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArbuS-0004eL-RH for sipping@optimus.ietf.org; Fri, 13 Feb 2004 06:55:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06093 for ; Fri, 13 Feb 2004 06:54:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArbuJ-00019N-00 for sipping@ietf.org; Fri, 13 Feb 2004 06:54:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArbtL-00014P-00 for sipping@ietf.org; Fri, 13 Feb 2004 06:53:56 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ArbsX-0000vV-00 for sipping@ietf.org; Fri, 13 Feb 2004 06:53:05 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1DBqWr25793 for ; Fri, 13 Feb 2004 05:52:32 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 13 Feb 2004 11:52:31 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EFF6@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Mpierce1@aol.com'" , sipping@ietf.org Subject: RE: [Sipping] Concern within sos ID - user addresses reserved Date: Fri, 13 Feb 2004 11:52:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F227.DABD1BFE" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 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. ------_=_NextPart_001_01C3F227.DABD1BFE Content-Type: text/plain Depending on which 3GPP release you get there are a number of mechanisms. 1) Certain numbers are built into the phone and recognised there. 2) Certain numbers are preloaded onto the SIM/UICC card by the operator at subscription time. 3) Numbers can be downloaded to the phone at registration time from the local providing access network. These are identified in the various versions of 22.101 (see http://www.3gpp.org/ftp/Specs/html-info/22101.htm ) clause 10. I am not sure what terminal manufacturers do in the case of setting the bits for phones supplied for use in the US, however inspection of the 3GPP TS 24.008 text says that in the US, whatever the bits are set to, or not set at all, the call will be routed to an emergency centre. Note that this category element does not determine an emegency call, only the category of an emergency call. A call identified by the terminal as an emergency call will be sent with an EMERGENCY SETUP message rather than a SETUP message. Special characteristics of the EMERGENCY SETUP message include ignoring any called party number sent in that message. Note that none of the above mechanisms can guarantee that an emergency call is always identified as such at the phone, and therefore there is also a responsibility on the local serving network to do its own analysis as well. In the 3GPP SIP environment, that responsibility may well extend to other proxies, with the need to reroute back to the country of origin (all calls carry the mobile country code and mobile network code as well as potentially geographic information). regards Keith -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: 12 February 2004 20:52 To: drage@lucent.com; sipping@ietf.org Subject: Re: [Sipping] Concern within sos ID - user addresses reserved In a message dated 2/12/2004 8:58:35 AM Eastern Standard Time, drage@lucent.com writes: ... I also note that 3GPP does have the capability of signalling multiple preferences - this left me wondering whether we would be better off trying to follow that, possibly with a single emergency uri, but with the possibility of signalling category as a URI parameter with a list of values. Any thoughts on this? It's always good to use other standards as the base. This list of "subadresses" is good. But I still don't see how a 3GPP phone can translate number dialed into one of these, unless it knows the local dial plan, or knows all dial plans and knows its location. Does the 3GPP spec mean that, if someone dials 911 in the US, that all bits must be set? Mike Pierce ------_=_NextPart_001_01C3F227.DABD1BFE Content-Type: text/html
Depending on which 3GPP release you get there are a number of mechanisms.
 
1)    Certain numbers are built into the phone and recognised there.
 
2)    Certain numbers are preloaded onto the SIM/UICC card by the operator at subscription time.
 
3)    Numbers can be downloaded to the phone at registration time from the local providing access network.
 
These are identified in the various versions of 22.101 (see http://www.3gpp.org/ftp/Specs/html-info/22101.htm) clause 10.
 
I am not sure what terminal manufacturers do in the case of setting the bits for phones supplied for use in the US, however inspection of the 3GPP TS 24.008 text says that in the US, whatever the bits are set to, or not set at all, the call will be routed to an emergency centre. Note that this category element does not determine an emegency call, only the category of an emergency call. A call identified by the terminal as an emergency call will be sent with an EMERGENCY SETUP message rather than a SETUP message. Special characteristics of the EMERGENCY SETUP message include ignoring any called party number sent in that message.
 
Note that none of the above mechanisms can guarantee that an emergency call is always identified as such at the phone, and therefore there is also a responsibility on the local serving network to do its own analysis as well. In the 3GPP SIP environment, that responsibility may well extend to other proxies, with the need to reroute back to the country of origin (all calls carry the mobile country code and mobile network code as well as potentially geographic information).
 
regards
 
Keith
-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: 12 February 2004 20:52
To: drage@lucent.com; sipping@ietf.org
Subject: Re: [Sipping] Concern within sos ID - user addresses reserved

In a message dated 2/12/2004 8:58:35 AM Eastern Standard Time, drage@lucent.com writes:


...
I also note that 3GPP does have the capability of signalling multiple preferences - this left me wondering whether we would be better off trying to follow that,
possibly with a single emergency uri, but with the possibility of signalling category as a URI parameter with a list of values. Any thoughts on this?

It's always good to use other standards as the base. This list of "subadresses" is good. But I still don't see how a 3GPP phone can translate number dialed into one of these, unless it knows the local dial plan, or knows all dial plans and knows its location.

Does the 3GPP spec mean that, if someone dials 911 in the US, that all bits must be set?

Mike Pierce

------_=_NextPart_001_01C3F227.DABD1BFE-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 08:42:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09038 for ; Fri, 13 Feb 2004 08:42:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdZy-0005Z7-Tk for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 08:42:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DDg2lH021387 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 08:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdZy-0005Ys-Pe for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 08:42:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08990 for ; Fri, 13 Feb 2004 08:42:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArdZx-00012h-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 08:42:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArdZ0-0000wa-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 08:41:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArdY8-0000qU-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 08:40:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdY2-0005KD-QL; Fri, 13 Feb 2004 08:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdX9-00053D-GP for sipping@optimus.ietf.org; Fri, 13 Feb 2004 08:39:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08858 for ; Fri, 13 Feb 2004 08:39:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArdX8-0000lE-00 for sipping@ietf.org; Fri, 13 Feb 2004 08:39:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArdW9-0000hA-00 for sipping@ietf.org; Fri, 13 Feb 2004 08:38:06 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1ArdVt-0000cv-00 for sipping@ietf.org; Fri, 13 Feb 2004 08:37:49 -0500 Received: from bear.cs.columbia.edu (IDENT:69pmoLATnhQufOSQdg5UZNGef1tJfU/w@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1DDbLR5007380 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 13 Feb 2004 08:37:22 -0500 (EST) Received: from cs.columbia.edu (pool-141-153-198-80.mad.east.verizon.net [141.153.198.80]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1DDbKmi016569 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Feb 2004 08:37:21 -0500 Message-ID: <402CD30A.8020205@cs.columbia.edu> Date: Fri, 13 Feb 2004 08:37:14 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Chris Boulton CC: Jonathan Rosenberg , sipping@ietf.org Subject: Re: [Sipping] Concern within sos ID - user addresses reserved References: <45730E094814E44488F789C1CDED27AE02BDF1B6@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE02BDF1B6@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Since SIP generally favors generality, I wonder if the more general service description wouldn't be better. I don't see a confusion problem if services are defined hierarchically, as in sos.fire automobile.towing restaurant.italian However, if this causes major delays in discussion, we should stick to the simple list of half a dozen sos.* items, I think. Chris Boulton wrote: > My inclination would be to have a specific emergency service parameter > to avoid any confusion in usage. That way we explicitly define > emergency routing without confusion. > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 08:56:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09381 for ; Fri, 13 Feb 2004 08:56:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdnV-00068Y-Ua for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 08:56:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DDu1Sn023566 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 08:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdnV-000680-4T for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 08:56:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09350 for ; Fri, 13 Feb 2004 08:55:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArdnT-000208-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 08:55:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArdmZ-0001vM-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 08:55:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ardlb-0001rF-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 08:54:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ardla-0005wm-As; Fri, 13 Feb 2004 08:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ardkb-0005v4-T2 for sipping@optimus.ietf.org; Fri, 13 Feb 2004 08:53:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09291 for ; Fri, 13 Feb 2004 08:52:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ardka-0001mx-00 for sipping@ietf.org; Fri, 13 Feb 2004 08:53:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ardjh-0001jH-00 for sipping@ietf.org; Fri, 13 Feb 2004 08:52:06 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1ArdjR-0001f8-00 for sipping@ietf.org; Fri, 13 Feb 2004 08:51:49 -0500 Received: from bear.cs.columbia.edu (IDENT:76zTvhGVBPrhHiOXRQZVqNSavLErvvCB@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1DDpnR5008785 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 13 Feb 2004 08:51:49 -0500 (EST) Received: from cs.columbia.edu (pool-141-153-198-80.mad.east.verizon.net [141.153.198.80]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1DDpmmi017683 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Feb 2004 08:51:48 -0500 Message-ID: <402CD66D.6040109@cs.columbia.edu> Date: Fri, 13 Feb 2004 08:51:41 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'Mpierce1@aol.com'" , sipping@ietf.org Subject: Re: [Sipping] Concern within sos ID - user addresses reserved References: <475FF955A05DD411980D00508B6D5FB00439EFF6@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EFF6@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for the pointer. From the description, Mike should talk to 3GPP about his concerns :-) http://www.3gpp.org/ftp/Specs/archive/22_series/22.101/22101-660.zip (SP-22) has pretty much the mechanisms described in the SOS draft. Note, in particular, in Section 10.1: "The user friendly MMI that specifies the type of emergency directly (e.g. menu) should be supported for use in any (i.e. home or visited) PLMN to avoid the mis-connection in roaming case. This shall be allowed both with and without SIM/USIM being present." and 10.1.1 "a) 112 and 911 shall always be available. These numbers shall be stored on the ME. b) Any emergency number stored on a SIM/USIM when the SIM/USIM is present. c) 000, 08, 110, 999, 118 and 119 when a SIM/USIM is not present. These numbers shall be stored on the ME. d) Additional emergency numbers that may have been downloaded by the serving network when the SIM/USIM is present." Note that bullet (b) specifically means that a traveling user will have his or her home emergency numbers available even when roaming. Unless we identify an equivalent set of personalization mechanisms for item (c), these would always have to be recognized, given that most non-3G SIP phones don't seem to carry SIMs or equivalent devices. Suggestions are most welcome here. My general inclination is to follow the spirit of this document, as it seems strange that if a user is used to be able to dial 112 on a SIM-less 3GPP SIP device that this wouldn't work on a non-3GPP SIP phone. Henning Drage, Keith (Keith) wrote: > Depending on which 3GPP release you get there are a number of mechanisms. > > 1) Certain numbers are built into the phone and recognised there. > > 2) Certain numbers are preloaded onto the SIM/UICC card by the > operator at subscription time. > > 3) Numbers can be downloaded to the phone at registration time from > the local providing access network. > > These are identified in the various versions of 22.101 (see > http://www.3gpp.org/ftp/Specs/html-info/22101.htm) clause 10. > > I am not sure what terminal manufacturers do in the case of setting the > bits for phones supplied for use in the US, however inspection of the > 3GPP TS 24.008 text says that in the US, whatever the bits are set to, > or not set at all, the call will be routed to an emergency centre. Note > that this category element does not determine an emegency call, only the > category of an emergency call. A call identified by the terminal as an > emergency call will be sent with an EMERGENCY SETUP message rather than > a SETUP message. Special characteristics of the EMERGENCY SETUP message > include ignoring any called party number sent in that message. > > Note that none of the above mechanisms can guarantee that an emergency > call is always identified as such at the phone, and therefore there is > also a responsibility on the local serving network to do its own > analysis as well. In the 3GPP SIP environment, that responsibility may > well extend to other proxies, with the need to reroute back to the > country of origin (all calls carry the mobile country code and mobile > network code as well as potentially geographic information). > > regards > > Keith > > -----Original Message----- > *From:* Mpierce1@aol.com [mailto:Mpierce1@aol.com] > *Sent:* 12 February 2004 20:52 > *To:* drage@lucent.com; sipping@ietf.org > *Subject:* Re: [Sipping] Concern within sos ID - user addresses reserved > > In a message dated 2/12/2004 8:58:35 AM Eastern Standard Time, > drage@lucent.com writes: > > >> ... > > I also note that 3GPP does have the capability of signalling > multiple preferences - this left me wondering whether we would be > better off trying to follow that, > >> possibly with a single emergency uri, but with the possibility of >> signalling category as a URI parameter with a list of values. Any >> thoughts on this? > > > It's always good to use other standards as the base. This list of > "subadresses" is good. But I still don't see how a 3GPP phone can > translate number dialed into one of these, unless it knows the local > dial plan, or knows all dial plans and knows its location. > > Does the 3GPP spec mean that, if someone dials 911 in the US, that > all bits must be set? > > Mike Pierce > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 09:07:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09697 for ; Fri, 13 Feb 2004 09:07:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdyC-0006za-Bh for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 09:07:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DE74XM026872 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 09:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdyB-0006zL-UB for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 09:07:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09663 for ; Fri, 13 Feb 2004 09:07:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArdyA-0002uB-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 09:07:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArdxC-0002pN-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 09:06:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArdwJ-0002lA-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 09:05:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdwG-0006iG-0Y; Fri, 13 Feb 2004 09:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdwB-0006gN-28 for sipping@optimus.ietf.org; Fri, 13 Feb 2004 09:04:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09563 for ; Fri, 13 Feb 2004 09:04:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ardw9-0002kU-00 for sipping@ietf.org; Fri, 13 Feb 2004 09:04:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArdvI-0002h5-00 for sipping@ietf.org; Fri, 13 Feb 2004 09:04:04 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly01a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1ArduR-0002Yj-00 for sipping@ietf.org; Fri, 13 Feb 2004 09:03:11 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly01a.srv.mailcontrol.com (MailControl) with SMTP id i1DE2ZG3030668; Fri, 13 Feb 2004 14:02:35 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Fri, 13 Feb 2004 14:02:34 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Drafts on exploders Date: Fri, 13 Feb 2004 14:02:35 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF1BB@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sipping] Drafts on exploders Thread-Index: AcPyBmzbliCsWY96SZK93kD/hzk55AAMy5Yw From: "Chris Boulton" To: "Gonzalo Camarillo" , "sipping" X-Scanned-By: MailControl A-01-00-04-90 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Gonzalo, Really interesting stuff ;-). Would it be worth mentioning the use of GRUU when an 'Associated-List-Manipulation' header is equal to a SIP or SIPS URI in the adhoc management draft? Chris. >-----Original Message----- >From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >Sent: 13 February 2004 07:50 >To: sipping >Subject: [Sipping] Drafts on exploders > >Folks, > >We have submitted a set of drafts on exploders. The following one >provides the requirements we are using and a framework to understand the >rest of the drafts. > >http://users.piuha.net/gonzalo/draft-camarillo-sipping-exploders-02.txt > >The rest of them can be fetched (until they appear in the archives) from: > >http://users.piuha.net/gonzalo/draft-camarillo-sipping-uri-list-01.txt >http://users.piuha.net/gonzalo/draft-camarillo-sipping-adhoc-management - >00.txt >http://users.piuha.net/gonzalo/draft-camarillo-sipping-transac-package- >00.txt >http://users.piuha.net/gonzalo/draft-camarillo-sipping-multiple-refer- >00.txt > >Commments are appreciated, > >Thanks, > >Gonzalo > > > >This communication is confidential and intended solely for the >addressee(s). Any unauthorized review, use, disclosure or distribution is >prohibited. If you believe this message has been sent to you in error, >please notify the sender by replying to this transmission and delete the >message without disclosing it. Thank you. > >E-mail including attachments is susceptible to data corruption, >interruption, unauthorized amendment, tampering and viruses, and we only >send and receive e-mails on the basis that we are not liable for any such >corruption, interception, amendment, tampering or viruses or any >consequences thereof. > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 09:17:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10017 for ; Fri, 13 Feb 2004 09:17:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Are7o-00087f-8s for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 09:17:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DEH0G7031217 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 09:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Are7o-00087Q-3D for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 09:17:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09991 for ; Fri, 13 Feb 2004 09:16:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Are7m-0003pT-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 09:16:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Are6p-0003kY-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 09:15:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Are5v-0003er-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 09:15:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Are5u-0007uq-68; Fri, 13 Feb 2004 09:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Are4w-0007sU-Mh for sipping@optimus.ietf.org; Fri, 13 Feb 2004 09:14:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09891 for ; Fri, 13 Feb 2004 09:13:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Are4v-0003Yn-00 for sipping@ietf.org; Fri, 13 Feb 2004 09:14:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Are3x-0003TF-00 for sipping@ietf.org; Fri, 13 Feb 2004 09:13:01 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1Are34-0003Ju-00 for sipping@ietf.org; Fri, 13 Feb 2004 09:12:06 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i1DEBTLc022455 for ; Fri, 13 Feb 2004 08:11:29 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Feb 2004 08:07:15 -0600 Received: from ericsson.com (rvi2-92-96.sw.ericsson.se [153.88.92.96]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 151RW6MP; Fri, 13 Feb 2004 08:11:30 -0600 Message-ID: <402CDB16.1000000@ericsson.com> Date: Fri, 13 Feb 2004 16:11:34 +0200 X-Sybari-Trust: ae809d3f 91259930 43af4536 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: sipping Subject: Re: [Sipping] Drafts on exploders References: <45730E094814E44488F789C1CDED27AE02BDF1BB@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE02BDF1BB@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2004 14:07:15.0640 (UTC) FILETIME=[AF1C5380:01C3F23A] Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chris, > Would it be worth mentioning the > use of GRUU when an 'Associated-List-Manipulation' header is equal to a > SIP or SIPS URI in the adhoc management draft? Yes, definitively. That is the idea. I will clarify that in the next revision of the drafts. Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 09:26:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10408 for ; Fri, 13 Feb 2004 09:26:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AreGW-0000Ov-H2 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 09:26:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DEQ0Jt001535 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 09:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AreGW-0000Of-CZ for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 09:26:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10363 for ; Fri, 13 Feb 2004 09:25:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AreGU-0004WK-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 09:25:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AreFZ-0004Ry-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 09:25:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AreEe-0004NJ-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 09:24:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AreEc-00008m-7N; Fri, 13 Feb 2004 09:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AreDk-00008J-5E for sipping@optimus.ietf.org; Fri, 13 Feb 2004 09:23:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10235 for ; Fri, 13 Feb 2004 09:23:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AreDi-0004Hb-00 for sipping@ietf.org; Fri, 13 Feb 2004 09:23:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AreCi-0004DY-00 for sipping@ietf.org; Fri, 13 Feb 2004 09:22:04 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1AreCV-00049X-00 for sipping@ietf.org; Fri, 13 Feb 2004 09:21:51 -0500 content-class: urn:content-classes:message Subject: RE: [Sipping] Concern within sos ID - user addresses reserved MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Feb 2004 15:27:07 +0100 Message-ID: <06CF906FE3998C4E944213062009F162233B41@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Sipping] Concern within sos ID - user addresses reserved Thread-Index: AcPyN8gKSQUCJeJrQoK95MuyKPztdwAAw51Q From: "Stastny Richard" To: "Henning Schulzrinne" , "Chris Boulton" Cc: "Jonathan Rosenberg" , Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Henning wrote: >=20 > However, if this causes major delays in discussion, we should=20 > stick to=20 > the simple list of half a dozen sos.* items, I think. >=20 Agree, we should stick in a first run to genuine _emergency_ calls, and what this is, is in most countries defined, and only these are handled special. This is the list proposed in the -sipping-sos- draft by Henning Just for information: In Austria we have in addition to this list 112 sos:doctor sos:child (e.g. for abused children with special trained personal) but we do not have sos:marine ;-) Richard _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 10:26:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14671 for ; Fri, 13 Feb 2004 10:26:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfCd-00042H-Ue for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 10:26:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DFQ3CH015504 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 10:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfCc-00041Z-RK for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 10:26:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14646 for ; Fri, 13 Feb 2004 10:25:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfCa-0002MI-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 10:26:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfBg-0002HQ-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 10:25:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArfAp-0002DL-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 10:24:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfAh-0003XE-Hx; Fri, 13 Feb 2004 10:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arf9h-0003Qa-Ld for sipping@optimus.ietf.org; Fri, 13 Feb 2004 10:23:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14520 for ; Fri, 13 Feb 2004 10:22:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arf9f-00026t-00 for sipping@ietf.org; Fri, 13 Feb 2004 10:22:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arf8h-00022u-00 for sipping@ietf.org; Fri, 13 Feb 2004 10:22:00 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Arf7o-0001ul-00 for sipping@ietf.org; Fri, 13 Feb 2004 10:21:04 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 13 Feb 2004 07:21:14 -0800 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 i1DFKVT4021261; Fri, 13 Feb 2004 10:20:32 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-118.cisco.com [64.100.229.118]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AWZ18872; Fri, 13 Feb 2004 07:20:31 -0800 (PST) Message-Id: <4.3.2.7.2.20040213101034.00b385d0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Feb 2004 10:20:31 -0500 To: "Banibrata Dutta" From: Michael Hammer Subject: RE: [Sipping] Drafts on exploders Cc: "'Gonzalo Camarillo'" , "'sipping'" In-Reply-To: <00e301c3f218$ab32b5b0$c0714c0f@nt13192> References: <402C9B2D.40302@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I am a little leery of a proxy-based solution, based on the experiences with early media. In essence, the middleman initiates the INVITE at the front end of a dialog then expects the UAC to handle who knows how many responses that return to it. For connectionless operations it might work, but for connection-oriented operations, it can easily scale beyond the capability of the UAC to handle it. Hopefully, this will be more elegant than early media. Mike At 03:33 PM 2/13/2004 +0530, Banibrata Dutta wrote: >Hi Gonzalo, > > I am sorry, I meant "heavy-weight" only. Okay, isn't then exploder >itself a service, but yes it would become a feature they may be used >by several services. Confercing is then just another service that uses >the exploder feature, right? > > Won't it be better to take that responsibility out of a B2BUA and >put it in the core network (in the proxies) s.t. the explosion happens >where it is needed? Let me explain my view as follows:- > >there are 2 ways:- > >1) A single To: header which explodes to multiple INVITES (or other > method messages). >2) A single INVITE with multiple To: headers which is understood by > a router and split off into multiple INVITE's with single To: > headers. > >in the first case the exploding proxy (or entity) needs access to a >explosion database (i.e. group-name -> list of members). this "may be" >achieved by DNS mechanisms (i am not even close to being a DNS >expert, but i think that it can be done, the same way SOS URI's >are transformed into actual ERS/PCAP #s). > >in the second case the exploding proxy doesn't need a explosion database >and the original INVITE anyway had all the info needed to split it off >into multiple INVITEs with single To: headers. > >with these approaches the benefit of "localization" of explosion can be >used, i.e. the explosion happens as late as possible, leading to the >minimum # of messages in the network, i.e. multiple exploder proxies >would exist in the network and it may so happen that the orginal >invite with 10 To: headers go split into 2 INVITES with 6 and 4 To: >headers respectively at an exploder proxy, and then the INVITE with >6 To:s got split into 2 with 3 To:s each and so on. this way the >explosion is "Just-In-Time" and minimal. > >regards, >banibrata dutta. > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of Gonzalo Camarillo > > Sent: Friday, February 13, 2004 3:09 PM > > To: Banibrata Dutta > > Cc: 'sipping' > > Subject: Re: [Sipping] Drafts on exploders > > > > > > Hello, > > > > > Why do you need a heavy-weight light B2BUA for "exploding". > > > > Do you mean light *or* heavy-weight? > > > > In any case, you do not want to use a proxy because the > > services these > > exploders provide (e.g., conferencing) are provided by B2BUAs, not by > > proxies. > > > > Gonzalo > > > > > > > > This communication is confidential and intended solely for > > the addressee(s). Any unauthorized review, use, disclosure or > > distribution is prohibited. If you believe this message has > > been sent to you in error, please notify the sender by > > replying to this transmission and delete the message without > > disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data > > corruption, interruption, unauthorized amendment, tampering > > and viruses, and we only send and receive e-mails on the > > basis that we are not liable for any such corruption, > > interception, amendment, tampering or viruses or any > > consequences thereof. > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current > > sip Use sip@ietf.org for new developments of core SIP > > > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 11:29:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17954 for ; Fri, 13 Feb 2004 11:29:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgBg-0001Ro-MP for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 11:29:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGT8js005558 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 11:29:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgBg-0001RZ-IS for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 11:29:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17902 for ; Fri, 13 Feb 2004 11:29:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgBf-0007ev-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 11:29:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgAg-0007ZI-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 11:28:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arg9k-0007Tc-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 11:27:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg9d-0001DS-Gm; Fri, 13 Feb 2004 11:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg96-0001D0-Rf for sipping@optimus.ietf.org; Fri, 13 Feb 2004 11:26:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17718 for ; Fri, 13 Feb 2004 11:26:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arg95-0007P8-00 for sipping@ietf.org; Fri, 13 Feb 2004 11:26:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arg7q-0007JK-00 for sipping@ietf.org; Fri, 13 Feb 2004 11:25:11 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Arg7a-0007Et-00 for sipping@ietf.org; Fri, 13 Feb 2004 11:24:54 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DGOAn10613; Fri, 13 Feb 2004 11:24:10 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1FNH8J87; Fri, 13 Feb 2004 11:24:09 -0500 Received: from nortelnetworks.com (acart1k7.ca.nortel.com [47.129.130.27]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DBDZJG9W; Fri, 13 Feb 2004 11:24:10 -0500 Message-ID: <402CFA29.8050208@nortelnetworks.com> Date: Fri, 13 Feb 2004 11:24:09 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mielias@hss.hns.com CC: Joseph Herman , sipping@ietf.org Subject: Re: [Sipping] Translating ISDN IE or SS7 optional fields to SIP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Also, the ITU-T and regional bodies (ANSI T1S1 for sure) are defining their own rules. The ITU-T reference is Q.1912.5. mielias@hss.hns.com wrote: > > > > RFC 3398 - Integrated Services Digital Network (ISDN) User Part (ISUP) to > Session Initiation Protocol (SIP) Mapping. > This RFC describes a way to perform the mapping between SIP and ISUP > (message and parameter level). > > - > Elias > Hughes Software Systems > http://www.hssworld.com > - > > > > > Joseph Herman > com> To > Sent by: sipping@ietf.org > sipping-admin@iet cc > f.org > Subject > [Sipping] Translating ISDN IE or > 02/13/04 04:31 AM SS7 optional fields to SIP > > > > > > > > > > > > Is there a document that defines (or proposes) a standard way to map > protocol specific information into SIP to be consumed by a UA? SIP-T > provides the entire SS7 packet embedded in the SIP message rather than a > translation of the fields. I am hoping for a mapping like > > redirection-number <==> redir-num: SIP header field > > Is there such a document? > > Thanks for any info, > Joe H. > > -- > Joe Herman > IBM Annapolis RM Telephony Solutions > 410-571-7117 > dzoey@us.ibm.com > > Everything is wonderful until you know something about it. > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 11:42:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18718 for ; Fri, 13 Feb 2004 11:42:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgOd-0002k8-Ue for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 11:42:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGgVsL010537 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 11:42:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgOd-0002jj-Oj for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 11:42:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18676 for ; Fri, 13 Feb 2004 11:42:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgOc-0001Sf-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 11:42:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgN1-00013a-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 11:40:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArgKM-0000dP-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 11:38:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgKJ-0001vj-Rg; Fri, 13 Feb 2004 11:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgJK-0001el-Hb for sipping@optimus.ietf.org; Fri, 13 Feb 2004 11:37:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18106 for ; Fri, 13 Feb 2004 11:36:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgJJ-0000Tk-00 for sipping@ietf.org; Fri, 13 Feb 2004 11:37:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgIL-0000MO-00 for sipping@ietf.org; Fri, 13 Feb 2004 11:36:01 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArgHO-0000EM-00 for sipping@ietf.org; Fri, 13 Feb 2004 11:35:02 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DGYUS10419 for ; Fri, 13 Feb 2004 11:34:30 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1FNH8KHV; Fri, 13 Feb 2004 11:34:30 -0500 Received: from nortelnetworks.com (acart1k7.ca.nortel.com [47.129.130.27]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DBDZJG96; Fri, 13 Feb 2004 11:34:30 -0500 Message-ID: <402CFC95.4030307@nortelnetworks.com> Date: Fri, 13 Feb 2004 11:34:29 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] INFO before 200 OK INVITE? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Q.1912.5 currently has some ISUP messages which don't interwork to call processing being encapsulated by INFO except when no dialog-establishing provisional response has been sent. We have had an intervention suggesting that what is required is a confirmed dialog, not just an early dialog. As a result, according to the intervention, you can't send an INFO from the UAS before it sends 200 OK INVITE. Any views on this? The RFC 2976 text quoted in the intervention is really based on RFC 2543, and was written before the concept of a dialog was elaborated. If it seems reasonable to send INFO in an early dialog, the language of RFC 2976 (as presented in Q.1912.5 Annex C.3) would need to be tweaked a bit. Tom Taylor _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 12:36:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22042 for ; Fri, 13 Feb 2004 12:36:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhEW-0007uB-PZ for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 12:36:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DHa8r5030381 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 12:36:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhEW-0007tw-K8 for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 12:36:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21950 for ; Fri, 13 Feb 2004 12:36:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArhEV-00076o-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 12:36:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArhDU-00070E-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 12:35:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArhCZ-0006ud-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 12:34:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhCT-0007XK-Oq; Fri, 13 Feb 2004 12:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhBc-0007Vv-T0 for sipping@optimus.ietf.org; Fri, 13 Feb 2004 12:33:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21765 for ; Fri, 13 Feb 2004 12:33:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArhBb-0006o7-00 for sipping@ietf.org; Fri, 13 Feb 2004 12:33:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArhAe-0006iW-00 for sipping@ietf.org; Fri, 13 Feb 2004 12:32:08 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Arh9q-0006Zv-00 for sipping@ietf.org; Fri, 13 Feb 2004 12:31:18 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 13 Feb 2004 09:39:26 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1DHUiuA001678; Fri, 13 Feb 2004 09:30:45 -0800 (PST) Received: from cisco.com ([10.32.130.58]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGB07716; Fri, 13 Feb 2004 12:30:42 -0500 (EST) Message-ID: <402D09C1.4010507@cisco.com> Date: Fri, 13 Feb 2004 12:30:41 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Chris Boulton , Jonathan Rosenberg , sipping@ietf.org Subject: Re: [Sipping] Concern within sos ID - user addresses reserved References: <45730E094814E44488F789C1CDED27AE02BDF1B6@gbnewp0758m.eu.ubiquity.net> <402CD30A.8020205@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I like the callerprefs direction for this. I don't have a particular preference for class or a new service feature tag. (But that word service continues to cause problems.) Whatever it is, I think it should work with non-emergency calls, rather than just with sos. For instance, often there is a separate number for non-emergency calls to the police etc. department. It would be nice to be able to use the same "service" callerpref parameter with a generic non-emergency public service number, together with the appropriate preference setting, to talk in a non-emergency context to the police, fire, ems, etc. organization. Paul Henning Schulzrinne wrote: > Since SIP generally favors generality, I wonder if the more general > service description wouldn't be better. I don't see a confusion problem > if services are defined hierarchically, as in > > sos.fire > automobile.towing > restaurant.italian > > However, if this causes major delays in discussion, we should stick to > the simple list of half a dozen sos.* items, I think. > > Chris Boulton wrote: > >> My inclination would be to have a specific emergency service parameter >> to avoid any confusion in usage. That way we explicitly define >> emergency routing without confusion. >> > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 12:39:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22276 for ; Fri, 13 Feb 2004 12:39:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhHL-0008Ve-UB for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 12:39:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DHd3n5032704 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 12:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhHL-0008VP-Qn for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 12:39:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22217 for ; Fri, 13 Feb 2004 12:39:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArhHK-0007NW-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 12:39:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArhGM-0007Hc-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 12:38:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArhFN-0007AF-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 12:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhFN-0007xQ-EB; Fri, 13 Feb 2004 12:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhEe-0007ub-Jj for sipping@optimus.ietf.org; Fri, 13 Feb 2004 12:36:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21995 for ; Fri, 13 Feb 2004 12:36:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArhEc-00077x-00 for sipping@ietf.org; Fri, 13 Feb 2004 12:36:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArhDj-00072O-00 for sipping@ietf.org; Fri, 13 Feb 2004 12:35:20 -0500 Received: from smtp.sylantro.com ([65.200.90.207]) by ietf-mx with esmtp (Exim 4.12) id 1ArhCy-0006ty-00 for sipping@ietf.org; Fri, 13 Feb 2004 12:34:32 -0500 Received: from 10.10.5.1 by smtp.sylantro.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v5.6.0)); Fri, 13 Feb 2004 09:32:45 -0800 X-Server-Uuid: A2273672-8896-48F6-829D-BBF711663783 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] Drafts on exploders Date: Fri, 13 Feb 2004 09:32:45 -0800 Message-ID: <22ACFCD87A5780449EEBDD6D78BB8DB5854511@sylmail1> Thread-Topic: [Sipping] Drafts on exploders Thread-Index: AcPyGPjL4t8m8tucTYSqcsEDZKmi+AAPFOlQ From: "Sunil Veluvali" To: "Gonzalo Camarillo" cc: sipping X-WSS-ID: 6C33D5B71XC26053-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Gonzolo, I believe this idea has merits. If I could somehow instruct my transaction stateful outbound proxy to preload a set of contacts in it's request target list (section 16.5 of RFC 3261), I have a generic way to fan out the request to a set of addresses-of-record. Combine this with Caller Preferences and now I also have control on how redirections are handled, etc.=20 Since multiple To: headers will break existing implementations, maybe a better way to go about it is to define a new header called Request-Target. Say, I have three buddies in my list a, b, c whose registrations are for a1,a2,b1,b2,c1,c2 respectively. I could simply a request to my outbound-proxy as: REQUEST sip:outbound-proxy SIP/2.0 f: me@domain;tag=3Dxyz t: all@domain Call-ID: xxxx M: me@m1 Request-Target: a@domain,b@domain,c@domain Request-Disposition: proxy,recurse,parallel,no-queue Almost all of what I need is available in a transaction stateful proxy server. Thanks, Sunil > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf > Of Gonzalo Camarillo > Sent: Friday, February 13, 2004 3:09 PM > To: Banibrata Dutta > Cc: 'sipping' > Subject: Re: [Sipping] Drafts on exploders >=20 >=20 > Hello, >=20 > > Why do you need a heavy-weight light B2BUA for "exploding". >=20 > Do you mean light *or* heavy-weight? >=20 > In any case, you do not want to use a proxy because the services these > exploders provide (e.g., conferencing) are provided by B2BUAs, not by=20 > proxies. >=20 > Gonzalo >=20 > =20 >=20 > This communication is confidential and intended solely for the=20 > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in=20 > error, please notify the sender by replying to this transmission and=20 > delete the message without disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data corruption,=20 > interruption, unauthorized amendment, tampering and viruses, and we=20 > only send and receive e-mails on the basis that we are not liable for=20 > any such corruption, interception, amendment, tampering or viruses or=20 > any consequences thereof. >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 14:54:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28969 for ; Fri, 13 Feb 2004 14:54:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjOG-0004ri-LS for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 14:54:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DJsKVM018696 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 14:54:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjOG-0004rT-HZ for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 14:54:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28965 for ; Fri, 13 Feb 2004 14:54:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArjOD-0003kA-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 14:54:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArjNS-0003fd-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 14:53:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArjMy-0003Zj-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 14:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjMz-0004Jg-Fx; Fri, 13 Feb 2004 14:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjMF-0004DW-D7 for sipping@optimus.ietf.org; Fri, 13 Feb 2004 14:52:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28846 for ; Fri, 13 Feb 2004 14:52:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArjMC-0003XA-00 for sipping@ietf.org; Fri, 13 Feb 2004 14:52:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArjLI-0003Sh-00 for sipping@ietf.org; Fri, 13 Feb 2004 14:51:16 -0500 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1ArjKS-0003Jp-00 for sipping@ietf.org; Fri, 13 Feb 2004 14:50:24 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i1DJnh8d005275; Fri, 13 Feb 2004 13:49:44 -0600 (CST) Message-ID: <402D2A56.6050402@alcatel.com> Date: Fri, 13 Feb 2004 13:49:42 -0600 From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mielias@hss.hns.com CC: Joseph Herman , sipping@ietf.org Subject: Re: [Sipping] Translating ISDN IE or SS7 optional fields to SIP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit And for ISUP Overlap Signaling to SIP mapping, see rfc3578 Alex. mielias@hss.hns.com wrote: > > >RFC 3398 - Integrated Services Digital Network (ISDN) User Part (ISUP) to >Session Initiation Protocol (SIP) Mapping. >This RFC describes a way to perform the mapping between SIP and ISUP >(message and parameter level). > >- >Elias >Hughes Software Systems >http://www.hssworld.com >- > > > > > Joseph Herman > com> To > Sent by: sipping@ietf.org > sipping-admin@iet cc > f.org > Subject > [Sipping] Translating ISDN IE or > 02/13/04 04:31 AM SS7 optional fields to SIP > > > > > > > > > > > >Is there a document that defines (or proposes) a standard way to map >protocol specific information into SIP to be consumed by a UA? SIP-T >provides the entire SS7 packet embedded in the SIP message rather than a >translation of the fields. I am hoping for a mapping like > >redirection-number <==> redir-num: SIP header field > >Is there such a document? > > Thanks for any info, > Joe H. > >-- >Joe Herman >IBM Annapolis RM Telephony Solutions >410-571-7117 >dzoey@us.ibm.com > >Everything is wonderful until you know something about it. > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 15:00:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29351 for ; Fri, 13 Feb 2004 15:00:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjU8-0006J3-Aq for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 15:00:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DK0Nfl023695 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 15:00:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjU5-00062P-Pf for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 15:00:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29309 for ; Fri, 13 Feb 2004 15:00:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArjU2-0004Pq-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 15:00:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArjTE-0004L2-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 14:59:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArjSo-0004FV-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 14:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjSo-000521-Cq; Fri, 13 Feb 2004 14:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjRz-00050G-Ud for sipping@optimus.ietf.org; Fri, 13 Feb 2004 14:58:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29171 for ; Fri, 13 Feb 2004 14:58:08 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArjRx-0004As-00 for sipping@ietf.org; Fri, 13 Feb 2004 14:58:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArjR3-00043X-00 for sipping@ietf.org; Fri, 13 Feb 2004 14:57:14 -0500 Received: from imo-m25.mx.aol.com ([64.12.137.6]) by ietf-mx with esmtp (Exim 4.12) id 1ArjQA-0003sJ-00 for sipping@ietf.org; Fri, 13 Feb 2004 14:56:18 -0500 Received: from Mpierce1@aol.com by imo-m25.mx.aol.com (mail_out_v36_r4.14.) id 7.4a.27c74177 (3924); Fri, 13 Feb 2004 14:55:07 -0500 (EST) Message-ID: <4a.27c74177.2d5e859a@aol.com> Date: Fri, 13 Feb 2004 14:55:06 EST Subject: Re: [Sipping] Concern within sos ID - user addresses reserved To: hgs@cs.columbia.edu, drage@lucent.com CC: sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_4a.27c74177.2d5e859a_boundary" X-Mailer: 6.0 for Windows XP sub 51 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 --part1_4a.27c74177.2d5e859a_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/13/2004 8:52:05 AM Eastern Standard Time, hgs@cs.columbia.edu writes: > Thanks for the pointer. From the description, Mike should talk to 3GPP > about his concerns :-) > > http://www.3gpp.org/ftp/Specs/archive/22_series/22.101/22101-660.zip > [MAP] The main different being the lack of a SIM, or personalization device, in the SOS draft. That leaves it with following the GSM case "without SIM", which, as noted below, means that many different numbers, including 118, will be reported as emergency. If it is true that 118 is Directory Assistance in Finland, as the SOS draft states, then this operation (using GSM, 3GPP, SIP, or a rotary dial phone) can not be allowed in Finland). (Anyone in Finland know what is done there?) Guess if I was involved in 3GPP I would take this up with them, but I'm not. Certainly looks like a mistake that the actual dialled digits are not included in the Emergency Setup message, which would allow the switch in the network to sort it out! > > Note, in particular, in Section 10.1: > > "The user friendly MMI that specifies the type of emergency directly > (e.g. menu) should be supported for use in any (i.e. home or visited) > PLMN to avoid the mis-connection in roaming case. This shall be allowed > both with and without SIM/USIM being present." > > and 10.1.1 > > "a) 112 and 911 shall always be available. These numbers shall be stored > on the ME. > b) Any emergency number stored on a SIM/USIM when the SIM/USIM is present. > c) 000, 08, 110, 999, 118 and 119 when a SIM/USIM is not present. These > numbers shall be stored on the ME. > d) Additional emergency numbers that may have been downloaded by the > serving network when the SIM/USIM is present." > Mike Pierce --part1_4a.27c74177.2d5e859a_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/13/2004 8:52:05 AM Eastern Standard Time, hgs@cs.columbia.edu writes= :


Thanks for the pointer. Fro= m the description, Mike should talk to 3GPP=20
about his concerns :-)

http://www.3gpp.org/ftp/Specs/archive/22_series/22.101/22101-660.zip=20
(SP-22) has pretty much the mechanisms described in the SOS draft.


[MAP] The main different being the lack of a SIM, or personalization dev= ice, in the SOS draft. That leaves it with following the GSM case "without S= IM", which, as noted below, means that many different numbers, including 118= , will be reported as emergency. If it is true that 118 is Directory Assista= nce in Finland, as the SOS draft states, then this operation (using GSM, 3GP= P, SIP, or a rotary dial phone) can not be allowed in Finland). (Anyone in F= inland know what is done there?)

Guess if I was involved in 3GPP I would take this up with them, but I'm=20= not. Certainly looks like a mistake that the actual dialled digits are not i= ncluded in the Emergency Setup message, which would allow the switch in the=20= network to sort it out!


Note, in particular, in Section 10.1:

"The user friendly MMI that specifies the type of emergency directly=20
(e.g. menu) should be supported for use in any (i.e. home or visited)=20
PLMN to avoid the mis-connection in roaming case.  This shall be al= lowed=20
both with and without SIM/USIM being present."

and 10.1.1

"a)    112 and 911 shall always be available. These numbe= rs shall be stored=20
on the ME.
b)    Any emergency number stored on a SIM/USIM when the=20= SIM/USIM is present.
c)    000, 08, 110, 999, 118 and 119 when a SIM/USIM is n= ot present. These=20
numbers shall be stored on the ME.
d)    Additional emergency numbers that may have been dow= nloaded by the=20
serving network when the SIM/USIM is present."



Mike Pierce

--part1_4a.27c74177.2d5e859a_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 15:20:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01139 for ; Fri, 13 Feb 2004 15:20:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjnF-0007HY-Cc for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 15:20:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DKK962027982 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 15:20:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjnE-0007HD-Ln for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 15:20:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01079 for ; Fri, 13 Feb 2004 15:20:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArjnD-0005oi-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 15:20:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArjmE-0005k2-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 15:19:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArjlF-0005dU-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 15:18:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjlB-0006d6-TZ; Fri, 13 Feb 2004 15:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjkW-0006QE-40 for sipping@optimus.ietf.org; Fri, 13 Feb 2004 15:17:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00811 for ; Fri, 13 Feb 2004 15:17:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArjkU-0005bA-00 for sipping@ietf.org; Fri, 13 Feb 2004 15:17:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArjjZ-0005WT-00 for sipping@ietf.org; Fri, 13 Feb 2004 15:16:21 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Arjj6-0005Rm-00 for sipping@ietf.org; Fri, 13 Feb 2004 15:15:52 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1DKFkR4023084; Fri, 13 Feb 2004 15:15:46 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1DKFjH21187; Fri, 13 Feb 2004 15:15:45 -0500 Message-ID: <402D306D.9000603@cs.columbia.edu> Date: Fri, 13 Feb 2004 15:15:41 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: drage@lucent.com, sipping@ietf.org Subject: Re: [Sipping] Concern within sos ID - user addresses reserved References: <4a.27c74177.2d5e859a@aol.com> In-Reply-To: <4a.27c74177.2d5e859a@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I suspect that the number of SIM-less phones is fairly small, as a fraction. For general SIP phones, one reasonable option is to say that the 'no configuration' case only applies if the device was unable to obtain information about geographically-local emergency numbers, using one of the several means available (XCAP, DNS). > [MAP] The main different being the lack of a SIM, or personalization > device, in the SOS draft. That leaves it with following the GSM case > "without SIM", which, as noted below, means that many different numbers, > including 118, will be reported as emergency. If it is true that 118 is > Directory Assistance in Finland, as the SOS draft states, then this > operation (using GSM, 3GPP, SIP, or a rotary dial phone) can not be > allowed in Finland). (Anyone in Finland know what is done there?) > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 16:06:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03517 for ; Fri, 13 Feb 2004 16:06:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkVu-0003Md-GF for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 16:06:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DL6IVI012925 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 16:06:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkVu-0003MO-B6 for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 16:06:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03500 for ; Fri, 13 Feb 2004 16:06:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArkVs-0001iA-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 16:06:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArkV4-0001eU-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 16:05:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArkUi-0001a9-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 16:05:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkUh-00030R-9c; Fri, 13 Feb 2004 16:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkTt-0002yJ-Ut for sipping@optimus.ietf.org; Fri, 13 Feb 2004 16:04:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03362 for ; Fri, 13 Feb 2004 16:04:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArkTs-0001Yt-00 for sipping@ietf.org; Fri, 13 Feb 2004 16:04:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArkT1-0001V2-00 for sipping@ietf.org; Fri, 13 Feb 2004 16:03:20 -0500 Received: from www4.mail.lycos.com ([209.202.220.170] helo=lycos.com) by ietf-mx with smtp (Exim 4.12) id 1ArkSM-0001N3-00 for sipping@ietf.org; Fri, 13 Feb 2004 16:02:38 -0500 Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Fri, 13 Feb 2004 21:02:02 -0000 To: "'Joseph Herman'" , sipping@ietf.org, "Banibrata Dutta" Date: Fri, 13 Feb 2004 16:02:02 -0500 From: "Jitender Arora" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: jitender_arora@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: RE: [Sipping] Translating ISDN IE or SS7 optional fields to SIP X-Sender-Ip: 63.144.164.60 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: multipart/alternative; boundary="=_-=_-KMNBJJFBNOGJFCAA" Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_BLUE, HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 This is a multi-part message in MIME format. You need a MIME compliant mail reader to completely decode it. --=_-=_-KMNBJJFBNOGJFCAA Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Length: 1623 Content-Transfer-Encoding: 7bit Refer to RFC 3398 ( ISUP to SIP Mapping ) ..... It contains the Mapping between the ISUP and SIP messages ... Jitender --------- Original Message --------- DATE: Fri, 13 Feb 2004 10:06:04 From: "Banibrata Dutta" To: "'Joseph Herman'" , Cc: One quick way would be to check that out by searching the ID-list hosted at the very useful http://softarmor.com/sipping/ site. AFAIK, such a draft doesn't exist. SIP-T is what comes closest (i think). -BDutta. -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Joseph Herman Sent: Friday, February 13, 2004 4:31 AM To: sipping@ietf.org Subject: [Sipping] Translating ISDN IE or SS7 optional fields to SIP Is there a document that defines (or proposes) a standard way to map protocol specific information into SIP to be consumed by a UA? SIP-T provides the entire SS7 packet embedded in the SIP message rather than a translation of the fields. I am hoping for a mapping like redirection-number <==> redir-num: SIP header field Is there such a document? Thanks for any info, Joe H. -- Joe Herman IBM Annapolis RM Telephony Solutions 410-571-7117 dzoey@us.ibm.com Everything is wonderful until you know something about it. ____________________________________________________________ Find what you are looking for with the Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10 --=_-=_-KMNBJJFBNOGJFCAA Content-Type: text/html; charset=us-ascii Content-Language: en Content-Length: 3420 Content-Transfer-Encoding: 7bit 
Refer to RFC 3398 ( ISUP to SIP Mapping ) .....
It contains the Mapping between the ISUP and SIP messages ...
Jitender
--------- Original Message ---------
DATE: Fri, 13 Feb 2004 10:06:04
From: "Banibrata Dutta" <dutta@india.hp.com>
To: "'Joseph Herman'" <jiherman@us.ibm.com>, <sipping@ietf.org>
Cc:

One quick way would be to check that out by searching the ID-list hosted at the
very useful http://softarmor.com/sipping/ site.
AFAIK, such a draft doesn't exist. SIP-T is what comes closest (i think).
 
-BDutta.
-----Original Message-----
From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Joseph Herman
Sent: Friday, February 13, 2004 4:31 AM
To: sipping@ietf.org
Subject: [Sipping] Translating ISDN IE or SS7 optional fields to SIP


Is there a document that defines (or proposes) a standard way to map protocol specific information into SIP to be consumed by a UA?   SIP-T provides  the entire SS7 packet embedded in the SIP message rather than a translation of the fields.   I am hoping for a mapping like

redirection-number <==> redir-num: SIP header field

Is there such a document?

              &nb! sp;                         Thanks for any info,
                                        Joe H.

--
Joe Herman
IBM Annapolis RM Telephony Solutions
410-571-7117
dzoey@us.ibm.com

Everything is wonderful until you know something about it.


____________________________________________________________
Find what you are looking for with the Lycos Yellow Pages. --=_-=_-KMNBJJFBNOGJFCAA-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 16:13:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04208 for ; Fri, 13 Feb 2004 16:13:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkcl-0004dZ-Im for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 16:13:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DLDNF5017819 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 16:13:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkcl-0004dK-ED for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 16:13:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04179 for ; Fri, 13 Feb 2004 16:13:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arkcj-0002FQ-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 16:13:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arkbo-0002A8-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 16:12:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArkbS-00024s-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 16:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkbT-0004D5-0x; Fri, 13 Feb 2004 16:12:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkan-00043G-MH for sipping@optimus.ietf.org; Fri, 13 Feb 2004 16:11:21 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03996; Fri, 13 Feb 2004 16:11:18 -0500 (EST) Message-Id: <200402132111.QAA03996@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 13 Feb 2004 16:11:18 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-trait-authz-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Trait-based Authorization Requirements for the Session Initiation Protocol (SIP) Author(s) : J. Peterson Filename : draft-ietf-sipping-trait-authz-00.txt Pages : 16 Date : 2004-2-12 This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol. While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allow greater privacy for users of an identity system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-trait-authz-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-trait-authz-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-trait-authz-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-13163415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-trait-authz-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-trait-authz-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-13163415.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 16:13:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04221 for ; Fri, 13 Feb 2004 16:13:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkcm-0004dr-4E for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 16:13:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DLDOQV017837 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 16:13:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkcl-0004dc-W1 for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 16:13:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04183 for ; Fri, 13 Feb 2004 16:13:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arkck-0002FV-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 16:13:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arkbp-0002AG-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 16:12:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArkbS-00024t-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 16:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkbR-0004Cn-MX; Fri, 13 Feb 2004 16:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkad-00040L-KO for sipping@optimus.ietf.org; Fri, 13 Feb 2004 16:11:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03919; Fri, 13 Feb 2004 16:11:08 -0500 (EST) Message-Id: <200402132111.QAA03919@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 13 Feb 2004 16:11:07 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-location-requirements-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Requirements for Session Initiation Protocol Location Conveyance Author(s) : J. Polk Filename : draft-ietf-sipping-location-requirements-00.txt Pages : 11 Date : 2004-2-12 This document presents the framework and requirements for an extension to the Session Initiation Protocol (SIP) [1] for conveyance of user location information from a Session Initiation Protocol (SIP) user agent to another SIP entity. We consider cases where location information is conveyed from end to end, as well as cases where message routing by intermediaries is influenced by the location of the session initiator. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirements-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-location-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-location-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-13163402.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-location-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-location-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-13163402.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 16:25:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05747 for ; Fri, 13 Feb 2004 16:25:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkoK-00068Z-Vd for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 16:25:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DLPK8L023585 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 16:25:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkoK-00068K-Ou for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 16:25:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05668 for ; Fri, 13 Feb 2004 16:25:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArkoI-0004E5-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 16:25:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arkn1-0003wE-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 16:24:00 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ArklH-0003YZ-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 16:22:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ArklG-0006s4-Gi for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 16:22:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkl7-0005YB-By; Fri, 13 Feb 2004 16:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkkv-0005XY-42 for sipping@optimus.ietf.org; Fri, 13 Feb 2004 16:21:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05013 for ; Fri, 13 Feb 2004 16:21:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arkkt-0003T3-00 for sipping@ietf.org; Fri, 13 Feb 2004 16:21:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arkj2-00033q-00 for sipping@ietf.org; Fri, 13 Feb 2004 16:19:53 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ArkhV-0002h9-00 for sipping@ietf.org; Fri, 13 Feb 2004 16:18:17 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1DLHi314173 for ; Fri, 13 Feb 2004 15:17:44 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id <15V6AY69>; Fri, 13 Feb 2004 15:17:44 -0600 Message-ID: From: "Chaidez, Fidencio (Fidencio)" To: "'Tom Taylor'" , sipping@ietf.org Subject: RE: [Sipping] INFO before 200 OK INVITE? Date: Fri, 13 Feb 2004 15:17:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Tom, The following text from RFC 3398 appears to clarify that INFO messages may indeed be sent for early dialogs: From the callee to the caller, if a message is received by a gateway before the call has been answered (i.e., ANM is received) it SHOULD be encapsulated in an INFO, provided that this will not be the first SIP message sent in the backwards direction (in which case it SHOULD be encapsulated in a provisional 1xx response). Similarly a message which is received on the originating side (probably in response to an INR) before a 200 OK has been received by the gateway should be carried within an INFO. Fidencio Chaidez -----Original Message----- From: Tom Taylor [mailto:taylor@nortelnetworks.com] Sent: Friday, February 13, 2004 10:34 AM To: sipping@ietf.org Subject: [Sipping] INFO before 200 OK INVITE? Q.1912.5 currently has some ISUP messages which don't interwork to call processing being encapsulated by INFO except when no dialog-establishing provisional response has been sent. We have had an intervention suggesting that what is required is a confirmed dialog, not just an early dialog. As a result, according to the intervention, you can't send an INFO from the UAS before it sends 200 OK INVITE. Any views on this? The RFC 2976 text quoted in the intervention is really based on RFC 2543, and was written before the concept of a dialog was elaborated. If it seems reasonable to send INFO in an early dialog, the language of RFC 2976 (as presented in Q.1912.5 Annex C.3) would need to be tweaked a bit. Tom Taylor _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 13 18:10:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13422 for ; Fri, 13 Feb 2004 18:10:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmRJ-0001un-RZ for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 18:09:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DN9fNI007357 for sipping-archive@odin.ietf.org; Fri, 13 Feb 2004 18:09:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmRJ-0001ua-Nu for sipping-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 18:09:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13355 for ; Fri, 13 Feb 2004 18:09:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArmRG-0007BN-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 18:09:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmQD-00074G-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 18:08:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArmPl-0006y5-00 for sipping-web-archive@ietf.org; Fri, 13 Feb 2004 18:08:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmPi-0001Ma-0A; Fri, 13 Feb 2004 18:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmOz-000122-8l for sipping@optimus.ietf.org; Fri, 13 Feb 2004 18:07:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13099 for ; Fri, 13 Feb 2004 18:07:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArmOw-0006wf-00 for sipping@ietf.org; Fri, 13 Feb 2004 18:07:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmO1-0006tj-00 for sipping@ietf.org; Fri, 13 Feb 2004 18:06:18 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1ArmNc-0006qY-00 for sipping@ietf.org; Fri, 13 Feb 2004 18:05:52 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1DN5qR4002036 for ; Fri, 13 Feb 2004 18:05:52 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1DN5qH09417 for ; Fri, 13 Feb 2004 18:05:52 -0500 Message-ID: <402D584C.6050103@cs.columbia.edu> Date: Fri, 13 Feb 2004 18:05:48 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] draft-ietf-sipping-location-requirements-00 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think it would be helpful to do a back-of-the-envelope calculation for a typical message exchange and geo value as to what delay a reasonable (GPRS, say) wireless channel would impose for the case that the proxy provides location information. My back-of-a-grocery-bag calculation (even rougher than back-of-the-envelope) is: 100 kb/s data rate (optimistic) 10000 bit per message with location information = 100 ms per transit of a location object across the air interface. In the proxy-provides-location case, we'd need roughly 3 messages (INVITE-redirect-INVITE), two of which have location information, for a total of 300 ms, not counting the TLS setup time (which may or may not be required for each emergency call). This is close enough to the E-1 requirement limit that somewhat more precise calculations are called for. I also found it peculiar that the draft does not mention the signature-only (unencrypted) mode for S/MIME, which would not interfere with proxy inspection. (The chain of reasoning should probably be: need privacy + can't use S/MIME for privacy since proxies need to peek -> TLS, rather than the current non-sequitur.) Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sat Feb 14 12:26:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24543 for ; Sat, 14 Feb 2004 12:26:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3Y7-0004jJ-Mj for sipping-archive@odin.ietf.org; Sat, 14 Feb 2004 12:25:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EHPpfb018175 for sipping-archive@odin.ietf.org; Sat, 14 Feb 2004 12:25:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3Y7-0004j4-Ha for sipping-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 12:25:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24528 for ; Sat, 14 Feb 2004 12:25:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3Y6-0003Mr-00 for sipping-web-archive@ietf.org; Sat, 14 Feb 2004 12:25:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3X8-0003Iq-00 for sipping-web-archive@ietf.org; Sat, 14 Feb 2004 12:24:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As3WW-0003Fn-00 for sipping-web-archive@ietf.org; Sat, 14 Feb 2004 12:24:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3WM-0004FH-PF; Sat, 14 Feb 2004 12:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3WB-0004EF-6K for sipping@optimus.ietf.org; Sat, 14 Feb 2004 12:23:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24483 for ; Sat, 14 Feb 2004 12:23:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3W9-0003FC-00 for sipping@ietf.org; Sat, 14 Feb 2004 12:23:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3VD-0003C3-00 for sipping@ietf.org; Sat, 14 Feb 2004 12:22:51 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1As3UK-00036T-01 for sipping@ietf.org; Sat, 14 Feb 2004 12:21:56 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 14 Feb 2004 09:30:18 +0000 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 i1EHLNuC016185 for ; Sat, 14 Feb 2004 09:21:25 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn4-702.cisco.com [10.21.82.190]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMJ40696; Sat, 14 Feb 2004 09:21:22 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 13 Feb 2004 08:26:29 -0800 From: Cullen Jennings To: sipping Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] draft-hwang-sipping-infomidcall-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Why not just use MGCP instead of SIP if you want to do this. It will work much better. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sat Feb 14 12:26:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24559 for ; Sat, 14 Feb 2004 12:26:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3Y8-0004jb-BV for sipping-archive@odin.ietf.org; Sat, 14 Feb 2004 12:25:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EHPqNt018193 for sipping-archive@odin.ietf.org; Sat, 14 Feb 2004 12:25:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3Y8-0004jM-8E for sipping-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 12:25:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24532 for ; Sat, 14 Feb 2004 12:25:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3Y6-0003Mx-00 for sipping-web-archive@ietf.org; Sat, 14 Feb 2004 12:25:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3X9-0003J0-00 for sipping-web-archive@ietf.org; Sat, 14 Feb 2004 12:24:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As3WW-0003Fo-00 for sipping-web-archive@ietf.org; Sat, 14 Feb 2004 12:24:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3WL-0004F6-Sr; Sat, 14 Feb 2004 12:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3WA-0004EA-HX for sipping@optimus.ietf.org; Sat, 14 Feb 2004 12:23:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24480 for ; Sat, 14 Feb 2004 12:23:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3W9-0003F7-00 for sipping@ietf.org; Sat, 14 Feb 2004 12:23:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3VC-0003Bv-00 for sipping@ietf.org; Sat, 14 Feb 2004 12:22:51 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1As3UK-00036T-00 for sipping@ietf.org; Sat, 14 Feb 2004 12:21:56 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 14 Feb 2004 09:30:17 +0000 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 i1EHLO1m016988 for ; Sat, 14 Feb 2004 09:21:24 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn4-702.cisco.com [10.21.82.190]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMJ40697; Sat, 14 Feb 2004 09:21:22 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 13 Feb 2004 08:34:35 -0800 From: Cullen Jennings To: sipping Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] draft-cgkim-sipping-info-00 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think this topic of far end camera control is important but I don't think this is the right way to do it. It seems like it would work better to use SIP to set up a session and use the data in this session to do the control. Sort of like MRCPv2 or session mode IM does. Have you considered something like using session mode IM to send mime bodies controlled the camera. One could define a mime type like application/fecc and send IM with a body like To pan clockwise by 20 degrees from the present position. Anyway, I don't know the best way to do this and we should probably figure out requirements before jumping into solutions but I would be glad to see some work like this get done. Not sure that sipping is the best place for it. Cullen _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sat Feb 14 12:43:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24956 for ; Sat, 14 Feb 2004 12:43:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3of-0006A5-Ay for sipping-archive@odin.ietf.org; Sat, 14 Feb 2004 12:42:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EHgvSo023679 for sipping-archive@odin.ietf.org; Sat, 14 Feb 2004 12:42:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3of-00069q-7e for sipping-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 12:42:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24929 for ; Sat, 14 Feb 2004 12:42:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3od-0004WU-00 for sipping-web-archive@ietf.org; Sat, 14 Feb 2004 12:42:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3nf-0004S0-00 for sipping-web-archive@ietf.org; Sat, 14 Feb 2004 12:41:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As3mr-0004OE-00 for sipping-web-archive@ietf.org; Sat, 14 Feb 2004 12:41:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3mn-0005bo-BR; Sat, 14 Feb 2004 12:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3ls-0005aW-8c for sipping@optimus.ietf.org; Sat, 14 Feb 2004 12:40:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24881 for ; Sat, 14 Feb 2004 12:40:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3lq-0004Jt-00 for sipping@ietf.org; Sat, 14 Feb 2004 12:40:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3ks-0004FC-00 for sipping@ietf.org; Sat, 14 Feb 2004 12:39:03 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1As3jz-0004AL-00 for sipping@ietf.org; Sat, 14 Feb 2004 12:38:07 -0500 Received: from bear.cs.columbia.edu (IDENT:eU5IgERJPFYSj/aWu+dTf8s+WfR8osQa@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1EHb6R5013140 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 14 Feb 2004 12:37:06 -0500 (EST) Received: from cs.columbia.edu (pool-141-153-198-80.mad.east.verizon.net [141.153.198.80]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1EHb5mi020703 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 14 Feb 2004 12:37:05 -0500 Message-ID: <402E5CBB.2070408@cs.columbia.edu> Date: Sat, 14 Feb 2004 12:36:59 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Cullen Jennings CC: sipping Subject: Re: [Sipping] draft-cgkim-sipping-info-00 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit IM works quite well for this and similar applications. We use it to control other devices beyond cameras, too, as sending an IM saying "look at me" and "move camera 20 degrees" are semantically rather similar. Should this be in MMUSIC? Cullen Jennings wrote: > I think this topic of far end camera control is important but I don't think > this is the right way to do it. It seems like it would work better to use > SIP to set up a session and use the data in this session to do the control. > Sort of like MRCPv2 or session mode IM does. Have you considered something > like using session mode IM to send mime bodies controlled the camera. One > could define a mime type like application/fecc and send IM with a body like > > > > To pan clockwise by 20 degrees from the present position. Anyway, I don't > know the best way to do this and we should probably figure out requirements > before jumping into solutions but I would be glad to see some work like this > get done. Not sure that sipping is the best place for it. > > Cullen > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sat Feb 14 13:15:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26229 for ; Sat, 14 Feb 2004 13:15:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As4Jn-0000KH-EF for sipping-archive@odin.ietf.org; Sat, 14 Feb 2004 13:15:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EIF7e2001247 for sipping-archive@odin.ietf.org; Sat, 14 Feb 2004 13:15:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As4Jn-0000K1-9g for sipping-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 13:15:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26219 for ; Sat, 14 Feb 2004 13:15:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As4Jl-0007I0-00 for sipping-web-archive@ietf.org; Sat, 14 Feb 2004 13:15:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As4Il-0007Cx-00 for sipping-web-archive@ietf.org; Sat, 14 Feb 2004 13:14:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As4Hr-000785-00 for sipping-web-archive@ietf.org; Sat, 14 Feb 2004 13:13:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As4Hm-0008Tr-0u; Sat, 14 Feb 2004 13:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As4Hi-0008TV-1I for sipping@optimus.ietf.org; Sat, 14 Feb 2004 13:12:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26162 for ; Sat, 14 Feb 2004 13:12:54 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As4Hg-000767-00 for sipping@ietf.org; Sat, 14 Feb 2004 13:12:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As4Go-00072O-00 for sipping@ietf.org; Sat, 14 Feb 2004 13:12:03 -0500 Received: from imo-r02.mx.aol.com ([152.163.225.98]) by ietf-mx with esmtp (Exim 4.12) id 1As4GL-0006y1-00 for sipping@ietf.org; Sat, 14 Feb 2004 13:11:33 -0500 Received: from Mpierce1@aol.com by imo-r02.mx.aol.com (mail_out_v36_r4.14.) id t.1a2.2041874c (17228); Sat, 14 Feb 2004 13:10:46 -0500 (EST) Message-ID: <1a2.2041874c.2d5fbea6@aol.com> Date: Sat, 14 Feb 2004 13:10:46 EST Subject: Re: [Sipping] Concern within sos ID - user addresses reserved To: atle.monrad@ericsson.com, hgs@cs.columbia.edu, drage@lucent.com CC: sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1a2.2041874c.2d5fbea6_boundary" X-Mailer: 6.0 for Windows XP sub 51 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 --part1_1a2.2041874c.2d5fbea6_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/13/2004 3:16:16 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > I suspect that the number of SIM-less phones is fairly small, as a > fraction. For general SIP phones, one reasonable option is to say that > the 'no configuration' case only applies if the device was unable to > obtain information about geographically-local emergency numbers, using > one of the several means available (XCAP, DNS). > In a message dated 2/14/2004 4:57:16 AM Eastern Standard Time, atle.monrad@ericsson.com writes: > What would be the first thought of Joe Citizen on vacation somewhere abroad > driving off the road desparately needing assistance, calling 911 or the > local xyz ?? > Due to the mobility, to me it makes sense to do the analysis whether it is > an emergency call or not in the handset in 3gpp. With the current mechanisms > the network can download local emergency numbers to the handset, and depending > on country, availability and configurastion of (U)SIM, the handset decides > whether a normal call setup is placed (that may be analyzed in the switch and > routed to the emergency centre anyway) or an emergency call setup is placed. > This is in the end about end-user perception and tradeoffs between different > numbering plans, analyzing the number based on the origin of the caller might > be some administrative work.... > Be also aware that local policy may decide whether (U)SIM-less emergency > calls are allowed or not, and that the support of 118 in 3gpp only apply in case > the (U)SIM is not present, thus other calls than emergency will always fail. > > [MAP] I agree that allowing an American to dial 911 for emergency while in Europe, or allowing anyone to dial their well-known emergency number while in the US is a good thing, as long as it is based on smarts in the phone (SIM or download locally) that says that this particular phone should work that way. I don't believe it is acceptable for the other 100 million people in the US to unknowingly get routed to emergency if they dial any one of those "foreign" numbers that they know nothing about. I suspect that 3GPP has covered this by allowing "analysis in the handset", although it isn't clear to me from the spec that they have covered all the cases. Anyway, this still doesn't answer the question of what is done in countries where this results in a conflict (like Finland which apparently uses 118 for Directory Service). I suspose the easy answer is that, if my SIM says that 118 is my desired emergency number and I'm in Finland, then I can't dial Directory Assistance. The other possible answer, implied someplace, is that the phone knows there is a confict, and if I dial 118, it asks me which one I want. Would this be a menu on the little screen that I'm unlikely to see if I was in an accident? It seems that the discussion for a SIP device (SOS URI) is lacking the presumption of the use of a SIM and the definition of a local download of local emergency numbers. If you want to follow the 3GPP model, then I think it's important to use all of it. As Henning noted (correctly I believe), the number of SIM-less phones is small. It is not the normal, since I understand that you must have a SIM to do lots of other things. Therefore, it is okay to interpret 118 (and just about every other assigned number) as emergency when there is no SIM. But, as I read 3GPP TS 22.101, it says that 112 and 911 are always interpreted as emergency, without or without a SIM. This is the point I don't understand. Of course, the other difference is that every mobile phone (as far as I know) operates on the basis that you enter a complete digit string and then hit "send" (or some equivalent). Therefore, there is no conflict between any of the emergency numbers and the starting digits of some other local number. So far, I don't believe there has been a general assumption that a SIP phone will work that way, therefore we also have to be concerned with the case of 911 or 112 or any other emergency number being the start of some other legitimate dialing string. Draft-siinnreich-sipdev-req-03 touches on this issue but seems to allow either operation. Mike Pierce --part1_1a2.2041874c.2d5fbea6_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/13/2004 3:16:16 PM Eastern Standard Time, hgs@cs.columbia.edu writes= :


I suspect that the number o= f SIM-less phones is fairly small, as a=20
fraction. For general SIP phones, one reasonable option is to say that=20
the 'no configuration' case only applies if the device was unable to=20
obtain information about geographically-local emergency numbers, using=20
one of the several means available (XCAP, DNS).




In a message dated 2/14/2004 4:57:16 AM Eastern Standard Time, atle.monr= ad@ericsson.com writes:

What would be the first tho= ught of Joe Citizen on vacation somewhere abroad driving off the road despar= ately needing assistance, calling 911 or the local xyz ??
Due to the mobility, to me it makes sense to do the analysis whether it=20= is an emergency call or not in the handset in 3gpp. With the current mechani= sms the network can download local emergency numbers to the handset, and dep= ending on country, availability and configurastion of (U)SIM, the handset de= cides whether a normal call setup is placed (that may be analyzed in the swi= tch and routed to the emergency centre anyway) or an emergency call setup is= placed. This is in the end about end-user perception and tradeoffs between=20= different numbering plans, analyzing the number based on the origin of the c= aller might be some administrative work....=20
Be also aware that local policy may decide whether (U)SIM-less emergency= calls are allowed or not, and that the support of 118 in 3gpp only apply in= case the (U)SIM is not present, thus other calls than emergency will always= fail.




[MAP]
I agree that allowing an American to dial 911 for emergency while in Eur= ope, or allowing anyone to dial their well-known emergency number while in t= he US is a good thing, as long as it is based on smarts in the phone (SIM or= download locally) that says that this particular phone should work that way= . I don't believe it is acceptable for the other 100 million people in the U= S to unknowingly get routed to emergency if they dial any one of those "fore= ign" numbers that they know nothing about. I suspect that 3GPP has covered t= his by allowing "analysis in the handset", although it isn't clear to me fro= m the spec that they have covered all the cases. Anyway, this still doesn't=20= answer the question of what is done in countries where this results in a con= flict (like Finland which apparently uses 118 for Directory Service). I susp= ose the easy answer is that, if my SIM says that 118 is my desired emergency= number and I'm in Finland, then I can't dial Directory Assistance. The othe= r possible answer, implied someplace, is that the phone knows there is a con= fict, and if I dial 118, it asks me which one I want. Would this be a menu o= n the little screen that I'm unlikely to see if I was in an accident?

It seems that the discussion for a SIP device (SOS URI) is lacking the p= resumption of the use of a SIM and the definition of a local download of loc= al emergency numbers. If you want to follow the 3GPP model, then I think it'= s important to use all of it. As Henning noted (correctly I believe), the nu= mber of SIM-less phones is small. It is not the normal, since I understand t= hat you must have a SIM to do lots of other things.

Therefore, it is okay to interpret 118 (and just about every other assig= ned number) as emergency when there is no SIM. But, as I read 3GPP TS 22.101= , it says that 112 and 911 are always interpreted as emergency, without or w= ithout a SIM. This is the point I don't understand.

Of course, the other difference is that every mobile phone (as far as I=20= know) operates on the basis that you enter a complete digit string and then=20= hit "send" (or some equivalent). Therefore, there is no conflict between any= of the emergency numbers and the starting digits of some other local number= . So far, I don't believe there has been a general assumption that a SIP pho= ne will work that way, therefore we also have to be concerned with the case=20= of 911 or 112 or any other emergency number being the start of some other le= gitimate dialing string. Draft-siinnreich-sipdev-req-03 touches on this issu= e but seems to allow either operation.

Mike Pierce



--part1_1a2.2041874c.2d5fbea6_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sat Feb 14 20:18:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08028 for ; Sat, 14 Feb 2004 20:18:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsAv8-0006Jm-PD for sipping-archive@odin.ietf.org; Sat, 14 Feb 2004 20:18:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1F1I6uZ024280 for sipping-archive@odin.ietf.org; Sat, 14 Feb 2004 20:18:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsAv8-0006JX-Lc for sipping-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 20:18:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08009 for ; Sat, 14 Feb 2004 20:18:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsAv6-000132-00 for sipping-web-archive@ietf.org; Sat, 14 Feb 2004 20:18:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsAu8-0000zo-00 for sipping-web-archive@ietf.org; Sat, 14 Feb 2004 20:17:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsAtE-0000wz-00 for sipping-web-archive@ietf.org; Sat, 14 Feb 2004 20:16:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsAt9-000621-Ns; Sat, 14 Feb 2004 20:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsAsT-000619-Q8 for sipping@optimus.ietf.org; Sat, 14 Feb 2004 20:15:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07941 for ; Sat, 14 Feb 2004 20:15:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsAsR-0000sO-00 for sipping@ietf.org; Sat, 14 Feb 2004 20:15:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsArG-0000pQ-00 for sipping@ietf.org; Sat, 14 Feb 2004 20:14:07 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AsAqh-0000mk-00 for sipping@ietf.org; Sat, 14 Feb 2004 20:13:31 -0500 Received: from bear.cs.columbia.edu (IDENT:Wj7+aEw2secnKf8+Jd2rCt7DF8WpHs84@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1F1DVR5011998 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 14 Feb 2004 20:13:32 -0500 (EST) Received: from cs.columbia.edu (pool-141-153-198-80.mad.east.verizon.net [141.153.198.80]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1F1DVmi020307 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 14 Feb 2004 20:13:31 -0500 Message-ID: <402EC7B5.9030505@cs.columbia.edu> Date: Sat, 14 Feb 2004 20:13:25 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: sipping@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] user=dialstring? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In Minneapolis (http://www.ietf.org/proceedings/03nov/228.htm) we had a lively discussion on how to capture dialstrings in SIP URI, with something like sip:*69@localhost;user=dialstring emerging as the favorite solution. Has this been written down anywhere? (This happens to be relevant for the -sos- discussion, for example.) Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 15 10:42:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15021 for ; Sun, 15 Feb 2004 10:42:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsOPP-0008EL-T5 for sipping-archive@odin.ietf.org; Sun, 15 Feb 2004 10:42:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FFgFlV031628 for sipping-archive@odin.ietf.org; Sun, 15 Feb 2004 10:42:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsOPP-0008E3-Oj for sipping-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 10:42:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14983 for ; Sun, 15 Feb 2004 10:42:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsOPN-0006yV-00 for sipping-web-archive@ietf.org; Sun, 15 Feb 2004 10:42:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsOOO-0006qM-00 for sipping-web-archive@ietf.org; Sun, 15 Feb 2004 10:41:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsONW-0006iX-00 for sipping-web-archive@ietf.org; Sun, 15 Feb 2004 10:40:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsONK-0007zX-03; Sun, 15 Feb 2004 10:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsON2-0007y8-Ky for sipping@optimus.ietf.org; Sun, 15 Feb 2004 10:39:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14871 for ; Sun, 15 Feb 2004 10:39:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsON0-0006gb-00 for sipping@ietf.org; Sun, 15 Feb 2004 10:39:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsOM4-0006aQ-00 for sipping@ietf.org; Sun, 15 Feb 2004 10:38:49 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AsOLX-0006Up-00 for sipping@ietf.org; Sun, 15 Feb 2004 10:38:15 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1FFc7R4003418 for ; Sun, 15 Feb 2004 10:38:07 -0500 (EST) Received: from cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1FFc6H07143 for ; Sun, 15 Feb 2004 10:38:07 -0500 Message-ID: <402F925E.9010705@cs.columbia.edu> Date: Sun, 15 Feb 2004 10:38:06 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Updated draft draft-ietf-sipping-sos-01 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have submitted draft-ietf-sipping-sos-01, reflecting some of the discussion of the last week. Until it appears in the archives, you can find it at http://www.cs.columbia.edu/sip/draft/sos/draft-ietf-sipping-sos-01.html The major semantic change is that the sos.* subaddresses were replaced by a callee capabilities media feature tag. Also, the discovery of emergency numbers was aligned, to the extent possible, with the 3GPP behavior: 112 and 911 always recognized, a short list of common numbers recognized if and only if the device has no other information about local emergency numbers. Since discovery of local emergency numbers could be relatively simple if the 'EN' resource record proposal is adopted (know the country the device is in, make one DNS query), I'm hoping that the use of default numbers will be rare in practice. 3GPP devices have the advantage that you can't call the Finnish directory service if your SIM card has been removed, so the collision problem is less pronounced. Comments are appreciated. I hope to get some session time in Seoul to discuss some of the open issues and reach closure on the discussion results so far. The draft notes one open issue: OPEN ISSUE: Alternatively, if the user dialed a digit string, the "To" header could contain the digit string, as in "tel:911;phone-context=sos.arpa". (The calling device may not know its current location, so it cannot insert a country-specific identifier.) This relates to my query to the list as to whether the 'dialstring' discussion ever yielded a draft. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 15 22:12:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11060 for ; Sun, 15 Feb 2004 22:12:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsZAr-0003cd-HY for sipping-archive@odin.ietf.org; Sun, 15 Feb 2004 22:11:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G3Bvuw013919 for sipping-archive@odin.ietf.org; Sun, 15 Feb 2004 22:11:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsZAr-0003cQ-B3 for sipping-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 22:11:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11053 for ; Sun, 15 Feb 2004 22:11:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsZAo-0006Ed-00 for sipping-web-archive@ietf.org; Sun, 15 Feb 2004 22:11:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsZ9q-0006BA-00 for sipping-web-archive@ietf.org; Sun, 15 Feb 2004 22:10:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsZ96-00068n-00 for sipping-web-archive@ietf.org; Sun, 15 Feb 2004 22:10:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsZ90-0003LF-JC; Sun, 15 Feb 2004 22:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsZ8v-0003JB-Eu for sipping@optimus.ietf.org; Sun, 15 Feb 2004 22:09:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10984 for ; Sun, 15 Feb 2004 22:09:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsZ8s-000688-00 for sipping@ietf.org; Sun, 15 Feb 2004 22:09:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsZ7y-00065d-00 for sipping@ietf.org; Sun, 15 Feb 2004 22:08:59 -0500 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1AsZ7R-00061r-00 for sipping@ietf.org; Sun, 15 Feb 2004 22:08:25 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1G37su22837 for ; Sun, 15 Feb 2004 22:07:54 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3DJZR4>; Sun, 15 Feb 2004 22:07:55 -0500 Message-ID: From: "Xuewen Li" To: sipping@ietf.org Date: Sun, 15 Feb 2004 22:07:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F43A.1248057A" Subject: [Sipping] SIP support for hold and ringback for operator / 911 services Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_RED,HTML_MESSAGE autolearn=no version=2.60 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. ------_=_NextPart_001_01C3F43A.1248057A Content-Type: text/plain Has anyone looked into how the orig-hold and ringback function should be supported in SIP? I realize that the wording may not be fully inline with the SIP model, but this is a real issue to address. Note that some of the terms below are in quotes since they are TDM telephony terms but are used in this context to represent logical equivalent. For example, "offhook" represents the action to initiate a call and "onhook" represents the action to end the call. Orig-hold refers to the ability to keep the call even when the originator goes "onhook" before the operator releases the call. The 911 operator is notified of such event (i.e., the caller has gone "onhook") so that the operator can initiate ringback (a special physical ringing is applied.) When the caller goes "offhook", no "dial tone" is provided. Rather the caller is reconnected to the original call to the 911 operator. When the caller is served by a softswitch which is connected to the 911 tandem via a SIP interface, SIP support for such functionality is required. Let's assume UA_a represents the caller, and UA_b represents the 911 operator. CMSS has a DCS-OSPS header (tag value = RING) which provides the mechanism for UA_b to request the "physical ringback". However the following pieces are missing. 1. Some way to communicate the caller's capabilities, e.g., supports orig-hold or not 2. Some mechanism to allow UA_b to request UA_a to apply orig-hold for this call. 3. Some mechanism for UA_b to subscribe to UA_a's "onhook" or "offhook" state changes. One can argue whether or not these are session states... 4. Some mechanism for UA_a to notify UA_b the state changes of UA_a For item 1, will the ALLOW header be appropriate? For item 2, the DCS-OSPS header (tagvalue=RING) can be used For item 3 and 4, will the SUBSCRIBE / NOTIFY mechanism be appropriate? Any thoughts, comment? ------_=_NextPart_001_01C3F43A.1248057A Content-Type: text/html

Has anyone looked into how the orig-hold and ringback function should be supported in SIP?  I realize that the wording may not be fully inline with the SIP model, but this is a real issue to address.

 

Note that some of the terms below are in quotes since they are TDM telephony terms but are used in this context to represent logical equivalent. For example, "offhook" represents the action to initiate a call and "onhook" represents the action to end the call.

 

Orig-hold refers to the ability to keep the call even when the originator goes "onhook" before the operator releases the call. The 911 operator is notified of such event (i.e., the caller has gone "onhook") so that the operator can initiate ringback (a special physical ringing is applied.) When the caller goes "offhook", no "dial tone" is provided. Rather the caller is reconnected to the original call to the 911 operator.  

 

When the caller is served by a softswitch which is connected to the 911 tandem via a SIP interface, SIP support for such functionality is required.

 

Let's assume UA_a represents the caller, and UA_b represents the 911 operator.

 

CMSS has a DCS-OSPS header (tag value = RING) which provides the mechanism for UA_b to request the "physical ringback".  However the following pieces are missing.

1.    Some way to communicate the caller's capabilities, e.g., supports orig-hold or not

2.    Some mechanism to allow UA_b to request UA_a to apply orig-hold for this call.

3.    Some mechanism for UA_b to subscribe to UA_a's "onhook" or "offhook" state changes.  One can argue whether or not these are session states...

4.    Some mechanism for UA_a to notify UA_b the state changes of UA_a

 

For item 1, will the ALLOW header be appropriate?

For item 2, the DCS-OSPS header (tagvalue=RING) can be used

For item 3 and 4, will the SUBSCRIBE / NOTIFY mechanism be appropriate?

 

Any thoughts, comment?

------_=_NextPart_001_01C3F43A.1248057A-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 15 23:21:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12522 for ; Sun, 15 Feb 2004 23:21:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsaFb-0006hk-Mo for sipping-archive@odin.ietf.org; Sun, 15 Feb 2004 23:20:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G4KtGn025766 for sipping-archive@odin.ietf.org; Sun, 15 Feb 2004 23:20:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsaFb-0006hV-DV for sipping-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 23:20:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12491 for ; Sun, 15 Feb 2004 23:20:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsaFZ-000234-00 for sipping-web-archive@ietf.org; Sun, 15 Feb 2004 23:20:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsaEc-00020H-00 for sipping-web-archive@ietf.org; Sun, 15 Feb 2004 23:19:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsaDq-0001y1-00 for sipping-web-archive@ietf.org; Sun, 15 Feb 2004 23:19:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsaDl-0006SR-Fu; Sun, 15 Feb 2004 23:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsaDi-0006S5-PU for sipping@optimus.ietf.org; Sun, 15 Feb 2004 23:18:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12447 for ; Sun, 15 Feb 2004 23:18:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsaDg-0001xY-00 for sipping@ietf.org; Sun, 15 Feb 2004 23:18:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsaCk-0001v4-00 for sipping@ietf.org; Sun, 15 Feb 2004 23:17:58 -0500 Received: from [147.6.42.146] (helo=filter2.kt.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AsaC4-0001pq-00 for sipping@ietf.org; Sun, 15 Feb 2004 23:17:16 -0500 Received: from external ([147.6.9.113]) by filter2 (1.0) id i1G4G3v44458; Mon, 16 Feb 2004 13:16:03 +0900 Message-ID: <004701c3f443$c74d6470$71090693@ROMEO> From: =?utf-8?B?7Zmp7KeE6rK9?= To: "Cullen Jennings" , "sipping" References: Subject: Re: [Sipping] draft-hwang-sipping-infomidcall-00.txt Date: Mon, 16 Feb 2004 13:17:23 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VGhhbmsgeW91IGZvciB0aGUgcXVlc3Rpb24uDQoNCllvdXIgcXVlc3Rpb24gaXMgd2h5IG5ldHdv cmstYmFzZWQgbWlkY2FsbCBpcyBuZWVkZWQgd2l0aCBTSVAuDQoNCk15IGFuc3dlciBpcyB0aGF0 DQpTaW5jZSBzZXJ2aWNlIGNvbXBvbmVudHMgaW4gdGhlIG5leHQgZ2VuIElQIG5ldHdvcmsgYXJl IGJhc2VkIG9uIFNJUCwNCnRoZSBkZWxpdmVyeSBvZiBtaWRjYWxsIGluZm9ybWF0aW9uIHNob3Vs ZCBiZSB0aHJvdWdoIFNJUCBtZXRob2QuDQoNClNpbXBsZSBJTkZPIChmcm9tIHRoZSBTSVAgcGhv bmUgb3IgZnJvbSB0aGUgTUdDKGJ5IHRyYW5zbGF0aW9uKSkgd29ya3MgdmVyeSB3ZWxsLA0KYXMg d2UgaW1wbGVtZW50ZWQgdHJpYWwgc2VydmljZXMgd2l0aCB0aGlzIElORk8gbWlkY2FsbCBmdW5j dGlvbiBib3RoIGluIFNJUCBwaG9uZSBhbmQgU29mdHN3aXRjaC4NCg0KTXkgcHJvcG9zYWwgaXMg dGhhdCBpbiBzdGFuZGFyZCBTSVAgcGhvbmUgKFVBKSBoYXZlIG1pZGNhbGwgYnV0dG9uIHNpbXBs eSBpbml0aWF0aW5nIElORk8gDQp3aGVuIHRoZSBidXR0b24gaXMgcHJlc3NlZC4NCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGl0bGU6IElORk8gVXNhZ2Ug RXhhbXBsZXMgZm9yIE5ldHdvcmstYmFzZWQgTWlkLUNhbGwgU2VydmljZSANCkF1dGhvcjogSmlu a3l1bmcgSHdhbmcgKEtUKQ0KDQpBYnN0cmFjdDoNCg0KICBUaGlzIGRvY3VtZW50IGRlc2NyaWJl cyB0aGUgSU5GTyB1c2FnZSBleGFtcGxlcyBmb3IgbmV0d29yayBiYXNlZCANCiAgbWlkLWNhbGwg c2VydmljZS4gTWlkLWNhbGwgYmFzZWQgc2VydmljZXMgYXJlIGZvciBleGFtcGxlLCBDYWxsIA0K ICBUcmFuc2ZlciwgQ2FsbCBXYWl0aW5nLCBhbmQgVGhyZWUtV2F5IENhbGxpbmcuIE90aGVyIHBv c3NpYmxlIG1pZC0NCiAgY2FsbCBzZXJ2aWNlcyBhcmUgdXNlZnVsIGFuZCBpbXBvcnRhbnQsIGV2 ZW4gbW9yZSBpbiBJUCBtdWx0aW1lZGlhIA0KICBuZXR3b3JrLiBUaGUgY2FzZXMgZGVzY3JpYmVk IGluIFNJUCBzZXJ2aWNlIGV4YW1wbGVzIChkcmFmdC1pZXRmLQ0KICBzaXBwaW5nLXNlcnZpY2Ut ZXhhbXBsZXMtMDUpIGFyZSBUZXJtaW5hbC1iYXNpcy4gU2luY2UgdGhlIHNlcnZpY2UgDQogIHBy b2NlZHVyZXMgYXJlIGZpeGVkIGluIHRoZSBUZXJtaW5hbCwgdGhlIGZlYXR1cmVzIGFyZSBub3Qg ZXh0ZW5zaWJsZS4gDQogIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgbmV0d29yay1iYXNlZCBtaWQt Y2FsbCBjb250cm9sIG1lY2hhbmlzbSB3aXRoIA0KICBJTkZPIGFuZCBzaG93cyBleGFtcGxlcyB0 aGF0IHNpbXBsZSBtaWQtY2FsbCByZXF1ZXN0IChJTkZPKSBmcm9tIHRoZSANCiAgVGVybWluYWws IHRoZW4gdGhlIG5ldHdvcmsgYXBwbGljYXRpb24gc2VydmVyIHByb3ZpZGUgdmFyaW91cyBtaWQt Y2FsbCANCiAgc2VydmljZXMgYnkgcHJvbXB0aW5nIHVzZXIgdGhyb3VnaCB0aGUgTWVkaWEgU2Vy dmVyLCBhY2NvcmRpbmcgdG8gdGhlIA0KICBzdWJzY3JpcHRpb24gaW5mb3JtYXRpb24gb2YgdGhl IHVzZXIuIA0KDQpBIFVSTCBmb3IgdGhpcyBkcmFmdCBpcyANCg0KIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh3YW5nLXNpcHBpbmctaW5mb21pZGNhbGwtMDAudHh0 DQoNCg0KQlINCg0KSmlua3l1bmcgSHdhbmcNCktUDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0gDQpGcm9tOiAiQ3VsbGVuIEplbm5pbmdzIiA8Zmx1ZmZ5QGNpc2NvLmNvbT4NClRvOiAi c2lwcGluZyIgPHNpcHBpbmdAaWV0Zi5vcmc+DQpTZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMTQs IDIwMDQgMToyNiBBTQ0KU3ViamVjdDogW1NpcHBpbmddIGRyYWZ0LWh3YW5nLXNpcHBpbmctaW5m b21pZGNhbGwtMDAudHh0DQoNCg0KPiAgICAgDQo+IFdoeSBub3QganVzdCB1c2UgTUdDUCBpbnN0 ZWFkIG9mIFNJUCBpZiB5b3Ugd2FudCB0byBkbyB0aGlzLiBJdCB3aWxsIHdvcmsNCj4gbXVjaCBi ZXR0ZXIuIA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBTaXBwaW5nIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2lwcGluZw0KPiBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZl bG9wbWVudCBvZiB0aGUgYXBwbGljYXRpb24gb2YgU0lQDQo+IFVzZSBzaXAtaW1wbGVtZW50b3Jz QGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwDQo+IFVzZSBzaXBA aWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb2YgY29yZSBTSVANCj4g _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 16 03:32:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05373 for ; Mon, 16 Feb 2004 03:32:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AseAo-0003xi-4E for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 03:32:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G8WDso015213 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 03:32:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AseAm-0003xI-J1 for sipping-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 03:32:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05320 for ; Mon, 16 Feb 2004 03:32:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AseAk-0001nz-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 03:32:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ase9o-0001j5-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 03:31:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ase8u-0001fK-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 03:30:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ase8j-0003X3-0n; Mon, 16 Feb 2004 03:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArwZM-0005q8-2Y for sipping@optimus.ietf.org; Sat, 14 Feb 2004 04:58:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13599 for ; Sat, 14 Feb 2004 04:58:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArwZI-0000xj-00 for sipping@ietf.org; Sat, 14 Feb 2004 04:58:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArwYO-0000uF-00 for sipping@ietf.org; Sat, 14 Feb 2004 04:57:41 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ArwXq-0000qo-00 for sipping@ietf.org; Sat, 14 Feb 2004 04:57:06 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1E9v6qY001591 for ; Sat, 14 Feb 2004 10:57:07 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 10:57:06 +0100 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJ47NVK; Sat, 14 Feb 2004 10:57:06 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 14 Feb 2004 10:57:30 +0100 Message-ID: <6F936E2F8E16234BA8D88B2EE8338332056E1A73@esealnt912.al.sw.ericsson.se> X-Sybari-Trust: 868966a4 c77f3eb6 787eb308 00000138 From: "Atle Monrad (GR/ETO)" To: Mpierce1@aol.com, hgs@cs.columbia.edu, drage@lucent.com Cc: sipping@ietf.org Subject: RE: [Sipping] Concern within sos ID - user addresses reserved Date: Sat, 14 Feb 2004 10:56:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F2E0.E0A37E94" X-OriginalArrivalTime: 14 Feb 2004 09:57:06.0825 (UTC) FILETIME=[E792A790:01C3F2E0] Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=HTML_FONTCOLOR_BLUE, HTML_MESSAGE autolearn=no version=2.60 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. ------_=_NextPart_001_01C3F2E0.E0A37E94 Content-Type: text/plain; charset="iso-8859-1" Hi, some further 3gpp-comments What would be the first thought of Joe Citizen on vacation somewhere abroad driving off the road desparately needing assistance, calling 911 or the local xyz ?? Due to the mobility, to me it makes sense to do the analysis whether it is an emergency call or not in the handset in 3gpp. With the current mechanisms the network can download local emergency numbers to the handset, and depending on country, availability and configurastion of (U)SIM, the handset decides whether a normal call setup is placed (that may be analyzed in the switch and routed to the emergency centre anyway) or an emergency call setup is placed. This is in the end about end-user perception and tradeoffs between different numbering plans, analyzing the number based on the origin of the caller might be some administrative work.... Be also aware that local policy may decide whether (U)SIM-less emergency calls are allowed or not, and that the support of 118 in 3gpp only apply in case the (U)SIM is not present, thus other calls than emergency will always fail. Another reason for having an EMERGENCY SETUP is that this particular message is easier to recognise by lower layers in the handset as well as the network as it has to recognise the message to perform particular characteristics and priority treatment. Anyway, as already stated by Keith, if the dialled number is analyzed in the handset and found to be an emergency call, is set up without any digits. The optional indication of fire brigade, marine, etc, is to my knowlede not commonly used (if used at all). It is difficult to predict end-user actions for how an accident is perceived. May such indicators may be more useful for e.g. telemetry-style of handsets where the handset report fire or intruders?? To me the most attractive solution for the emergency service is to use ONE number/URI for routing and have indicators that might help the PSAP to act as professional and coordinated as possible. The 911 approac is attractive to me, compared to countries where e.g. 110, 112 and 113 are used for different purposes but end up in the same PSAP. For sure a dedicated URI for targeting e.g. the local police, doctors, vererinary, help for abused childeren or the nearest hard rock cafe may be useful, but outside the scope ;-) To me the emergency service involves two parties; the end user reporting an accident and the PSAP providing appropriate help and coordinating the assistance. /atle Best Regards Atle Monrad ERICSSON Wireless Data Terminals & Solutions Office: + 47 372 93 665 Mobile: + 47 454 10 665 Fax: + 47 372 94 058 E-mail: atle.monrad@ericsson.com Web-site: www.ericsson.com/mobileplatforms -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Mpierce1@aol.com Sent: Friday, February 13, 2004 8:55 PM To: hgs@cs.columbia.edu; drage@lucent.com Cc: sipping@ietf.org Subject: Re: [Sipping] Concern within sos ID - user addresses reserved In a message dated 2/13/2004 8:52:05 AM Eastern Standard Time, hgs@cs.columbia.edu writes: Thanks for the pointer. From the description, Mike should talk to 3GPP about his concerns :-) http://www.3gpp.org/ftp/Specs/archive/22_series/22.101/22101-660.zip (SP-22) has pretty much the mechanisms described in the SOS draft. [MAP] The main different being the lack of a SIM, or personalization device, in the SOS draft. That leaves it with following the GSM case "without SIM", which, as noted below, means that many different numbers, including 118, will be reported as emergency. If it is true that 118 is Directory Assistance in Finland, as the SOS draft states, then this operation (using GSM, 3GPP, SIP, or a rotary dial phone) can not be allowed in Finland). (Anyone in Finland know what is done there?) Guess if I was involved in 3GPP I would take this up with them, but I'm not. Certainly looks like a mistake that the actual dialled digits are not included in the Emergency Setup message, which would allow the switch in the network to sort it out! Note, in particular, in Section 10.1: "The user friendly MMI that specifies the type of emergency directly (e.g. menu) should be supported for use in any (i.e. home or visited) PLMN to avoid the mis-connection in roaming case. This shall be allowed both with and without SIM/USIM being present." and 10.1.1 "a) 112 and 911 shall always be available. These numbers shall be stored on the ME. b) Any emergency number stored on a SIM/USIM when the SIM/USIM is present. c) 000, 08, 110, 999, 118 and 119 when a SIM/USIM is not present. These numbers shall be stored on the ME. d) Additional emergency numbers that may have been downloaded by the serving network when the SIM/USIM is present." Mike Pierce This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. ------_=_NextPart_001_01C3F2E0.E0A37E94 Content-Type: text/html; charset="iso-8859-1"

Hi, some further 3gpp-comments

What would be the first thought of Joe Citizen on vacation somewhere abroad driving off the road desparately needing assistance, calling 911 or the local xyz ??
Due to the mobility, to me it makes sense to do the analysis whether it is an emergency call or not in the handset in 3gpp. With the current mechanisms the network can download local emergency numbers to the handset, and depending on country, availability and configurastion of (U)SIM, the handset decides whether a normal call setup is placed (that may be analyzed in the switch and routed to the emergency centre anyway) or an emergency call setup is placed. This is in the end about end-user perception and tradeoffs between different numbering plans, analyzing the number based on the origin of the caller might be some administrative work....

Be also aware that local policy may decide whether (U)SIM-less emergency calls are allowed or not, and that the support of 118 in 3gpp only apply in case the (U)SIM is not present, thus other calls than emergency will always fail.

Another reason for having an EMERGENCY SETUP is that this particular message is easier to recognise by lower layers in the handset as well as the network as it has to recognise the message to perform particular characteristics and priority treatment.

Anyway, as already stated by Keith, if the dialled number is analyzed in the handset and found to be an emergency call, is set up without any digits. The optional indication of fire brigade, marine, etc, is to my knowlede not commonly used (if used at all). It is difficult to predict end-user actions for how an accident is perceived. May such indicators may be more useful for e.g. telemetry-style of handsets where the handset report fire or intruders??

To me the most attractive solution for the emergency service is to use ONE number/URI for routing and have indicators that might help the PSAP to act as professional and coordinated as possible. The 911 approac is attractive to me, compared to countries where e.g. 110, 112 and 113 are used for different purposes but end up in the same PSAP.

For sure a dedicated URI for targeting e.g. the local police, doctors, vererinary, help for abused childeren or the nearest hard rock cafe may be useful, but outside the scope ;-)
To me the emergency service involves two parties; the end user reporting an accident and the PSAP providing appropriate help and coordinating the assistance.

/atle

Best Regards

Atle Monrad

ERICSSON

Wireless Data Terminals & Solutions

Office: + 47 372 93 665
Mobile: + 47 454 10 665
Fax: + 47 372 94 058
E-mail: atle.monrad@ericsson.com
Web-site: www.ericsson.com/mobileplatforms

-----Original Message-----
From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Mpierce1@aol.com
Sent: Friday, February 13, 2004 8:55 PM
To: hgs@cs.columbia.edu; drage@lucent.com
Cc: sipping@ietf.org
Subject: Re: [Sipping] Concern within sos ID - user addresses reserved

In a message dated 2/13/2004 8:52:05 AM Eastern Standard Time, hgs@cs.columbia.edu writes:


Thanks for the pointer. From the description, Mike should talk to 3GPP
about his concerns :-)

http://www.3gpp.org/ftp/Specs/archive/22_series/22.101/22101-660.zip
(SP-22) has pretty much the mechanisms described in the SOS draft.



[MAP] The main different being the lack of a SIM, or personalization device, in the SOS draft. That leaves it with following the GSM case "without SIM", which, as noted below, means that many different numbers, including 118, will be reported as emergency. If it is true that 118 is Directory Assistance in Finland, as the SOS draft states, then this operation (using GSM, 3GPP, SIP, or a rotary dial phone) can not be allowed in Finland). (Anyone in Finland know what is done there?)

Guess if I was involved in 3GPP I would take this up with them, but I'm not. Certainly looks like a mistake that the actual dialled digits are not included in the Emergency Setup message, which would allow the switch in the network to sort it out!


Note, in particular, in Section 10.1:

"The user friendly MMI that specifies the type of emergency directly
(e.g. menu) should be supported for use in any (i.e. home or visited)
PLMN to avoid the mis-connection in roaming case.  This shall be allowed
both with and without SIM/USIM being present."

and 10.1.1

"a)    112 and 911 shall always be available. These numbers shall be stored
on the ME.
b)    Any emergency number stored on a SIM/USIM when the SIM/USIM is present.
c)    000, 08, 110, 999, 118 and 119 when a SIM/USIM is not present. These
numbers shall be stored on the ME.
d)    Additional emergency numbers that may have been downloaded by the
serving network when the SIM/USIM is present."



Mike Pierce


This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
------_=_NextPart_001_01C3F2E0.E0A37E94-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 16 04:17:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07433 for ; Mon, 16 Feb 2004 04:17:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsesG-0007BO-E9 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 04:17:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G9H8qp027608 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 04:17:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsesE-0007BD-7a for sipping-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 04:17:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07411 for ; Mon, 16 Feb 2004 04:17:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsesA-0004ns-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 04:17:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AserF-0004kY-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 04:16:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AseqN-0004h0-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 04:15:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AseqF-0006yn-Ns; Mon, 16 Feb 2004 04:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsepM-0006xO-Oz for sipping@optimus.ietf.org; Mon, 16 Feb 2004 04:14:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07300 for ; Mon, 16 Feb 2004 04:14:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsepJ-0004dY-00 for sipping@ietf.org; Mon, 16 Feb 2004 04:14:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aseog-0004ak-00 for sipping@ietf.org; Mon, 16 Feb 2004 04:13:28 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1Asenh-0004RL-00 for sipping@ietf.org; Mon, 16 Feb 2004 04:12:26 -0500 Subject: RE: [Sipping] Concern within sos ID - user addresses reserved Date: Mon, 16 Feb 2004 10:17:44 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F46D.BC67F338" Message-ID: <06CF906FE3998C4E944213062009F162233B51@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [Sipping] Concern within sos ID - user addresses reserved Thread-Index: AcP0aCEDMhEAjWuzQlS0Y/aeWDobbgAAt8DA From: "Stastny Richard" To: "Atle Monrad (GR/ETO)" , , , Cc: Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F46D.BC67F338 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Atle Monrad wrote: =20 >Be also aware that local policy may decide whether (U)SIM-less emergency calls are allowed or not, and that the support of 118 >in 3gpp only apply in case the (U)SIM is not present, thus other calls than emergency will always fail. As far as I know it is required in GSM (3gpp) that the handset SHALL be able to make emergency calls to=20 112 if no SIM is available. Of course you also SHALL be able to use 112 in case the SIM in present, but then you also are able to use other local numbers. =20 Since we are primarily not talking only 3gpp here, but SIP in general, especially about VoIP and=20 other IP communications, the problem of _local_ data is still there, even if you use SIM cards. We=20 are currently investigating the usage of SIM cards for SIP-authentication and WiFi roaming and in=20 this case the SIP server and _HLR_ responsible may be anywhere in the world, so you may not be able to download _local_ information being nomadic. =20 So we are back to square one regarding location information. =20 regards Richard =20 -----Original Message----- From: Atle Monrad (GR/ETO) [mailto:atle.monrad@ericsson.com]=20 Sent: Saturday, February 14, 2004 10:57 AM To: Mpierce1@aol.com; hgs@cs.columbia.edu; drage@lucent.com Cc: sipping@ietf.org Subject: RE: [Sipping] Concern within sos ID - user addresses reserved =09 =09 Hi, some further 3gpp-comments What would be the first thought of Joe Citizen on vacation somewhere abroad driving off the road desparately needing assistance, calling 911 or the local xyz ?? Due to the mobility, to me it makes sense to do the analysis whether it is an emergency call or not in the handset in 3gpp. With the current mechanisms the network can download local emergency numbers to the handset, and depending on country, availability and configurastion of (U)SIM, the handset decides whether a normal call setup is placed (that may be analyzed in the switch and routed to the emergency centre anyway) or an emergency call setup is placed. This is in the end about end-user perception and tradeoffs between different numbering plans, analyzing the number based on the origin of the caller might be some administrative work....=20 Be also aware that local policy may decide whether (U)SIM-less emergency calls are allowed or not, and that the support of 118 in 3gpp only apply in case the (U)SIM is not present, thus other calls than emergency will always fail. =09 Another reason for having an EMERGENCY SETUP is that this particular message is easier to recognise by lower layers in the handset as well as the network as it has to recognise the message to perform particular characteristics and priority treatment.=20 Anyway, as already stated by Keith, if the dialled number is analyzed in the handset and found to be an emergency call, is set up without any digits. The optional indication of fire brigade, marine, etc, is to my knowlede not commonly used (if used at all). It is difficult to predict end-user actions for how an accident is perceived. May such indicators may be more useful for e.g. telemetry-style of handsets where the handset report fire or intruders?? To me the most attractive solution for the emergency service is to use ONE number/URI for routing and have indicators that might help the PSAP to act as professional and coordinated as possible. The 911 approac is attractive to me, compared to countries where e.g. 110, 112 and 113 are used for different purposes but end up in the same PSAP. For sure a dedicated URI for targeting e.g. the local police, doctors, vererinary, help for abused childeren or the nearest hard rock cafe may be useful, but outside the scope ;-)=20 To me the emergency service involves two parties; the end user reporting an accident and the PSAP providing appropriate help and coordinating the assistance. /atle Best Regards Atle Monrad ERICSSON Wireless Data Terminals & Solutions =09 Office: + 47 372 93 665 Mobile: + 47 454 10 665 Fax: + 47 372 94 058 E-mail: atle.monrad@ericsson.com Web-site: www.ericsson.com/mobileplatforms -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Mpierce1@aol.com Sent: Friday, February 13, 2004 8:55 PM To: hgs@cs.columbia.edu; drage@lucent.com Cc: sipping@ietf.org Subject: Re: [Sipping] Concern within sos ID - user addresses reserved =09 =09 In a message dated 2/13/2004 8:52:05 AM Eastern Standard Time, hgs@cs.columbia.edu writes:=20 =09 =09 =09 Thanks for the pointer. From the description, Mike should talk to 3GPP=20 about his concerns :-)=20 =09 =09 http://www.3gpp.org/ftp/Specs/archive/22_series/22.101/22101-660.zip=20 (SP-22) has pretty much the mechanisms described in the SOS draft. [MAP] The main different being the lack of a SIM, or personalization device, in the SOS draft. That leaves it with following the GSM case "without SIM", which, as noted below, means that many different numbers, including 118, will be reported as emergency. If it is true that 118 is Directory Assistance in Finland, as the SOS draft states, then this operation (using GSM, 3GPP, SIP, or a rotary dial phone) can not be allowed in Finland). (Anyone in Finland know what is done there?)=20 =09 Guess if I was involved in 3GPP I would take this up with them, but I'm not. Certainly looks like a mistake that the actual dialled digits are not included in the Emergency Setup message, which would allow the switch in the network to sort it out!=20 =09 =09 Note, in particular, in Section 10.1:=20 =09 "The user friendly MMI that specifies the type of emergency directly=20 (e.g. menu) should be supported for use in any (i.e. home or visited)=20 PLMN to avoid the mis-connection in roaming case. This shall be allowed=20 both with and without SIM/USIM being present."=20 =09 and 10.1.1=20 =09 "a) 112 and 911 shall always be available. These numbers shall be stored=20 on the ME.=20 b) Any emergency number stored on a SIM/USIM when the SIM/USIM is present.=20 c) 000, 08, 110, 999, 118 and 119 when a SIM/USIM is not present. These=20 numbers shall be stored on the ME.=20 d) Additional emergency numbers that may have been downloaded by the=20 serving network when the SIM/USIM is present."=20 =09 =09 =09 Mike Pierce=20 =09 =09 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. =09 E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. =09 ------_=_NextPart_001_01C3F46D.BC67F338 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Atle=20 Monrad wrote:
 
>Be also aware that local = policy may=20 decide whether (U)SIM-less emergency calls are allowed or not, and that = the=20 support of 118 >in 3gpp only apply in case the (U)SIM is not present, = thus=20 other calls than emergency will always = fail.
As far=20 as I know it is required in GSM (3gpp) that the handset SHALL be able to = make=20 emergency calls to
112 if=20 no SIM is available. Of course you also SHALL be able to use = 112 in=20 case the SIM in present, but then
you=20 also are able to use other local numbers.
 
Since=20 we are primarily not talking only 3gpp here, but SIP in = general,=20 especially about VoIP and
other=20 IP communications, the problem of _local_ data is still there, = even if you use=20 SIM cards. We
are=20 currently investigating the usage of SIM cards for=20 SIP-authentication and WiFi roaming and in
this=20 case the SIP server and _HLR_ responsible may be anywhere=20 in the world, so you may not be able to download _local_ information = being=20 nomadic.
 
So we=20 are back to square one regarding location = information.
 
regards
Richard
 
-----Original Message-----
From: Atle = Monrad=20 (GR/ETO) [mailto:atle.monrad@ericsson.com]
Sent: Saturday, = February=20 14, 2004 10:57 AM
To: Mpierce1@aol.com; hgs@cs.columbia.edu; = drage@lucent.com
Cc: sipping@ietf.org
Subject: RE: = [Sipping] Concern within sos ID - user addresses = reserved

Hi, some further=20 3gpp-comments

What would be the first thought of Joe Citizen on = vacation=20 somewhere abroad driving off the road desparately needing assistance, = calling=20 911 or the local xyz ??
Due to the mobility, = to me it=20 makes sense to do the analysis whether it is an emergency call or not = in the=20 handset in 3gpp. With the current mechanisms the network can download = local=20 emergency numbers to the handset, and depending on country, = availability and=20 configurastion of (U)SIM, the handset decides whether a normal call = setup is=20 placed (that may be analyzed in the switch and routed to the emergency = centre=20 anyway) or an emergency call setup is placed. This is in the end about = end-user perception and tradeoffs between different numbering plans, = analyzing=20 the number based on the origin of the caller might be some = administrative=20 work....

Be also aware that local policy may decide whether = (U)SIM-less=20 emergency calls are allowed or not, and that the support of 118 in = 3gpp only=20 apply in case the (U)SIM is not present, thus other calls than = emergency will=20 always fail.

Another reason for having an EMERGENCY SETUP is that = this=20 particular message is easier to recognise by lower layers in the = handset=20 as well as the network as = it has to=20 recognise the message to perform particular characteristics and = priority=20 treatment.

Anyway, as already stated by Keith, if the dialled = number is=20 analyzed in the handset and found to be an emergency call, is set up = without=20 any digits. The optional indication of fire brigade, marine, etc, is = to my=20 knowlede not commonly used (if used at all). It is difficult = to predict end-user actions for how an=20 accident is perceived. May such indicators may be more useful for e.g. telemetry-style of handsets = where the=20 handset report fire or intruders??

To me the most attractive solution for the emergency = service is to use ONE = number/URI for=20 routing and have indicators that might help the PSAP to act as = professional=20 and coordinated as possible. The 911 approac is attractive to me, = compared to=20 countries where e.g. 110, 112 and 113 are used for different purposes = but end=20 up in the same PSAP.

For sure a dedicated URI for targeting e.g. the = local police,=20 doctors, vererinary, help for abused childeren or the nearest hard = rock cafe=20 may be useful, but outside the = scope ;-)=20
To me the emergency service involves = two=20 parties; the end user reporting an accident and the PSAP providing = appropriate=20 help and coordinating the assistance.

/atle

Best Regards

Atle Monrad

ERICSSON

Wireless Data Terminals & Solutions

Office: + 47 372 93=20 665
Mobile: + 47 454 10 665
Fax: + 47 372 94 058
E-mail:=20 atle.monrad@ericsson.com
Web-site:=20 www.ericsson.com/mobileplatforms

-----Original Message-----
From: = sipping-admin@ietf.org=20 [mailto:sipping-admin@ietf.org]On Behalf Of=20 Mpierce1@aol.com
Sent: Friday, February 13, 2004 8:55=20 PM
To: hgs@cs.columbia.edu; drage@lucent.com
Cc: = sipping@ietf.org
Subject: Re: [Sipping] Concern within sos = ID -=20 user addresses reserved

In a message dated 2/13/2004 8:52:05 AM = Eastern Standard=20 Time, hgs@cs.columbia.edu writes:


Thanks for the pointer. From the description, Mike = should talk=20 to 3GPP
about his concerns :-)=20 =

http://www.3gpp.org/ftp/Specs/archive/22_series/22.101/22101-660.= zip=20
(SP-22) has pretty much the mechanisms described in the SOS=20 draft.



[MAP] The main different being the = lack of a=20 SIM, or personalization device, in the SOS draft. That leaves it = with=20 following the GSM case "without SIM", which, as noted below, means = that many=20 different numbers, including 118, will be reported as emergency. If = it is=20 true that 118 is Directory Assistance in Finland, as the SOS draft = states,=20 then this operation (using GSM, 3GPP, SIP, or a rotary dial phone) = can not=20 be allowed in Finland). (Anyone in Finland know what is done there?) =

Guess if I was involved in 3GPP I would take this up with = them, but=20 I'm not. Certainly looks like a mistake that the actual dialled = digits are=20 not included in the Emergency Setup message, which would allow the = switch in=20 the network to sort it out!


Note, in particular, in Section 10.1:

"The = user=20 friendly MMI that specifies the type of emergency directly =
(e.g. menu)=20 should be supported for use in any (i.e. home or visited)
PLMN = to=20 avoid the mis-connection in roaming case.  This shall be = allowed=20
both with and without SIM/USIM being present."

and = 10.1.1=20

"a)    112 and 911 shall always be = available. These=20 numbers shall be stored
on the ME.
b) =    Any=20 emergency number stored on a SIM/USIM when the SIM/USIM is = present.
c)=20    000, 08, 110, 999, 118 and 119 when a SIM/USIM = is not=20 present. These
numbers shall be stored on the ME.
d)=20    Additional emergency numbers that may have been=20 downloaded by the
serving network when the SIM/USIM is = present."=20



Mike Pierce=20


This communication is = confidential and=20 intended solely for the addressee(s). Any unauthorized review, use, = disclosure=20 or distribution is prohibited. If you believe this message has been = sent to=20 you in error, please notify the sender by replying to this = transmission and=20 delete the message without disclosing it. Thank you.

E-mail = including=20 attachments is susceptible to data corruption, interruption, = unauthorized=20 amendment, tampering and viruses, and we only send and receive e-mails = on the=20 basis that we are not liable for any such corruption, interception, = amendment,=20 tampering or viruses or any consequences = thereof.
=00 ------_=_NextPart_001_01C3F46D.BC67F338-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 16 04:19:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05372 for ; Mon, 16 Feb 2004 03:32:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AseAo-0003xj-4p for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 03:32:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G8WD2W015219 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 03:32:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AseAn-0003xO-9j for sipping-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 03:32:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05323 for ; Mon, 16 Feb 2004 03:32:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AseAk-0001o6-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 03:32:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ase9q-0001jD-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 03:31:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ase8u-0001fL-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 03:30:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ase8g-0003Wi-Gq; Mon, 16 Feb 2004 03:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqhBu-00030w-7p for sipping@optimus.ietf.org; Tue, 10 Feb 2004 18:21:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29657 for ; Tue, 10 Feb 2004 18:21:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqhBq-0006e1-00 for sipping@ietf.org; Tue, 10 Feb 2004 18:21:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqhAo-0006ZP-00 for sipping@ietf.org; Tue, 10 Feb 2004 18:20:10 -0500 Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx with esmtp (Exim 4.12) id 1AqhAh-0006V1-00 for sipping@ietf.org; Tue, 10 Feb 2004 18:20:03 -0500 Received: from csc.com (va-fch32.csc.com [20.6.39.233]) by amer-mta01.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1ANMRSc022668 for ; Tue, 10 Feb 2004 18:22:27 -0500 (EST) Subject: RE: [Sipping] Concern within sos ID - user addresses reserved To: "James M. Polk" Cc: "Rosen, Brian" , sipping@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Tue, 10 Feb 2004 18:23:29 -0500 X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 6.0.3|September 26, 2003) at 02/10/2004 06:19:50 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I would assume that, in the first case, it would be the same as the circuit switched version. If the coastal jurisdiction currently has separate numbers for "fire house" and "coast guard" (for instance), they must already have some sort of coordination process in place. That process wouldn't need to be modified much. Similarly, in a big city, I assume that the jurisdiction would arrange that all the addresses (fire, police, rescue, etc) would go to the same place, where the human attendant would make the dispatch decision based on the information given, not just the destination address. Janet ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- "James M. Polk" , @cisco.com> cc: Subject: RE: [Sipping] Concern within sos ID - user addresses reserved 02/10/2004 05:52 PM Suppose there is a fire on a boat near a harbor - which do you call? But seriously, suppose there is a fire and the fire department is called only. They show up and a person (who set the fire) is there showing his gun. The fire department won't go near that situation until the police show up. This happens in big cities. Should the fire department now place a new call to the police department for each of its sos@fire calls? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 16 11:51:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04512 for ; Mon, 16 Feb 2004 11:51:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aslxq-0005Hq-HW for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 11:51:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GGpMTi020318 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 11:51:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aslxq-0005Hd-D7 for sipping-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 11:51:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04467 for ; Mon, 16 Feb 2004 11:51:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aslxo-0007Xq-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 11:51:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aslww-0007Vf-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 11:50:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aslwd-0007TR-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 11:50:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslwZ-00055D-0V; Mon, 16 Feb 2004 11:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aslvs-000542-Jk for sipping@optimus.ietf.org; Mon, 16 Feb 2004 11:49:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04401 for ; Mon, 16 Feb 2004 11:49:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aslvr-0007S8-00 for sipping@ietf.org; Mon, 16 Feb 2004 11:49:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asluy-0007Pt-00 for sipping@ietf.org; Mon, 16 Feb 2004 11:48:25 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsluS-0007MJ-00 for sipping@ietf.org; Mon, 16 Feb 2004 11:47:52 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1GGlKNr005070; Mon, 16 Feb 2004 11:47:21 -0500 (EST) Message-ID: <4030F410.1050801@dynamicsoft.com> Date: Mon, 16 Feb 2004 11:47:12 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?7Zmp7KeE6rK9?= CC: Cullen Jennings , sipping Subject: Re: [Sipping] draft-hwang-sipping-infomidcall-00.txt References: <004701c3f443$c74d6470$71090693@ROMEO> In-Reply-To: <004701c3f443$c74d6470$71090693@ROMEO> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id i1GGlKNr005070 Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree that these services are needed. However, mechanisms are in place=20 today for performing these services. Call transfer is done with REFER,=20 call waiting is a local feature on the device, and three way calling can=20 be done locally or through invocation of a centralized conferencing serve= r. In the SIp services model, all of these features do not live in a=20 centralized server in the network. Rather, they are distributed, and=20 implemented in the place most appropriate for that service. In an IP=20 network, the endpoints have greater intelligence than in the PSTN.=20 Having smarter endpoints means that you can have a better overall=20 service experience and support a broader range of devices. MGCP takes the position you are advocating, that the services all live=20 in a centralized place. Cullen's point, I believe, is that, if the aim=20 is to develop protocols to support a model of centralized service=20 control, we already have that - mgcp. Thanks, Jonathan R. =ED=99=A9=EC=A7=84=EA=B2=BD wrote: > Thank you for the question. >=20 > Your question is why network-based midcall is needed with SIP. >=20 > My answer is that > Since service components in the next gen IP network are based on SIP, > the delivery of midcall information should be through SIP method. >=20 > Simple INFO (from the SIP phone or from the MGC(by translation)) works = very well, > as we implemented trial services with this INFO midcall function both i= n SIP phone and Softswitch. >=20 > My proposal is that in standard SIP phone (UA) have midcall button simp= ly initiating INFO=20 > when the button is pressed. >=20 > ------------------------------------------- > Title: INFO Usage Examples for Network-based Mid-Call Service=20 > Author: Jinkyung Hwang (KT) >=20 > Abstract: >=20 > This document describes the INFO usage examples for network based=20 > mid-call service. Mid-call based services are for example, Call=20 > Transfer, Call Waiting, and Three-Way Calling. Other possible mid- > call services are useful and important, even more in IP multimedia=20 > network. The cases described in SIP service examples (draft-ietf- > sipping-service-examples-05) are Terminal-basis. Since the service=20 > procedures are fixed in the Terminal, the features are not extensible= .=20 > This document proposes network-based mid-call control mechanism with=20 > INFO and shows examples that simple mid-call request (INFO) from the=20 > Terminal, then the network application server provide various mid-cal= l=20 > services by prompting user through the Media Server, according to the= =20 > subscription information of the user.=20 >=20 > A URL for this draft is=20 >=20 > http://www.ietf.org/internet-drafts/draft-hwang-sipping-infomidcall-00= .txt >=20 >=20 > BR >=20 > Jinkyung Hwang > KT >=20 > ----- Original Message -----=20 > From: "Cullen Jennings" > To: "sipping" > Sent: Saturday, February 14, 2004 1:26 AM > Subject: [Sipping] draft-hwang-sipping-infomidcall-00.txt >=20 >=20 >=20 >> =20 >>Why not just use MGCP instead of SIP if you want to do this. It will wo= rk >>much better.=20 >> >> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP >>J*ix&j)b bm?=0C0'~ffX)=DF=A3"8bX+=1FDY=D7=AFzZ)ayi'=1A*'=3DK=1E*b^?=1C%= fin~-w.=C8=A9R=C7=AC++=1Dz(}+y"=0F --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 16 13:09:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09772 for ; Mon, 16 Feb 2004 13:09:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsnBQ-0002y2-39 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 13:09:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GI9SAn011402 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 13:09:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsnBP-0002xp-VV for sipping-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 13:09:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09764 for ; Mon, 16 Feb 2004 13:09:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsnBN-0006sa-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 13:09:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsnAS-0006pw-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 13:08:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsnA9-0006nE-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 13:08:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsnA0-0002mW-Sd; Mon, 16 Feb 2004 13:08:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asn9V-0002e7-A1 for sipping@optimus.ietf.org; Mon, 16 Feb 2004 13:07:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09642 for ; Mon, 16 Feb 2004 13:07:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asn9T-0006mT-00 for sipping@ietf.org; Mon, 16 Feb 2004 13:07:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asn8e-0006jG-00 for sipping@ietf.org; Mon, 16 Feb 2004 13:06:37 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Asn7q-0006a2-00 for sipping@ietf.org; Mon, 16 Feb 2004 13:05:46 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1GI5NNr005132 for ; Mon, 16 Feb 2004 13:05:23 -0500 (EST) Message-ID: <4031065B.9050500@dynamicsoft.com> Date: Mon, 16 Feb 2004 13:05:15 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] URGENT: query on another reg-event change Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, Authors 48 hours have started for reg-event. As you may recall, I had found a fatal problem in the schema design, and there was agreement on the list on a proposal to fix it. While making the changes in the schema, another question came up. The question is regarding the "params" attribute of the "contact" element. Currently, this parameter is meant to contain any of the contact parameters not otherwise called out explicitly in other attributes (for example, the q-value is contained in the "q" attribute. So, if I had a contact like this: REGISTER To: sip:user@example.com Contact: sip:user@pc.example.com;q=1.0;newparam=foo;audio then the resulting XML would look like (using the new schema I proposed on the list): sip:user@pc887.example.com Notice how the contact parameters are basically passed untouched in the "params" attribute. This makes sense if that is the only point of exensibility in the schema. But, now with the structured contact, one could represent these "properly" with formal schema definitions. i.e., if we did a reg-event extension to support caller-prefs, it could look like: sip:user@pc887.example.com . The technical drawback here is that whether a parameter appears in unknown-param or whether its in something like callerprefs:audio depends on whether that particular extension (in this case, callerprefs) is supported by the server. Another choice is to not even include unknown parameters in the reg-event notifications, however I think thats a bad idea. The benefit, however, is that it allows us to provide very structured notifications for contact header field extensions, and it avoids the need for implementing, for example, a caller-prefs parser just to receive notifications about caller preferences parameters - all the data is represented using XML constructs. Technically, my preference would be to define the unknown-param in reg-event right now, and have extensions (like callerprefs and gruu) specify xml schema extensions to reg-event for their data. Please provide comments on this proposal within the next few days. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 16 15:43:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20639 for ; Mon, 16 Feb 2004 15:43:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspZv-0003Q8-6A for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 15:42:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GKgtLm013144 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 15:42:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspZv-0003Ps-0l for sipping-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 15:42:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20524 for ; Mon, 16 Feb 2004 15:42:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspZt-0002gx-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 15:42:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AspYz-0002Ys-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 15:41:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AspYH-0002S9-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 15:41:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspY8-0002Wd-5T; Mon, 16 Feb 2004 15:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspXt-0002Qx-Qn for sipping@optimus.ietf.org; Mon, 16 Feb 2004 15:40:49 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20044; Mon, 16 Feb 2004 15:40:47 -0500 (EST) Message-Id: <200402162040.PAA20044@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 16 Feb 2004 15:40:47 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-app-interaction-framework-01.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : A Framework for Application Interaction in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sipping-app-interaction-framework-01.txt Pages : 38 Date : 2004-2-16 This document describes a framework and requirements for the interaction between users and Session Initiation Protocol (SIP) based applications. By interacting with applications, users can guide the way in which they operate. The focus of this framework is stimulus signaling, which allows a user agent to interact with an application without knowledge of the semantics of that application. Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual Tone Multi Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-app-interaction-framework-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-app-interaction-framework-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-app-interaction-framework-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-16123236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-app-interaction-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-app-interaction-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16123236.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 16 15:43:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20656 for ; Mon, 16 Feb 2004 15:43:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspZy-0003VV-Ts for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 15:42:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GKgwnv013475 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 15:42:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspZy-0003UT-OM for sipping-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 15:42:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20528 for ; Mon, 16 Feb 2004 15:42:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspZx-0002hV-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 15:42:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AspZ0-0002Z3-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 15:41:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AspYH-0002SA-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 15:41:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspY9-0002Ym-Qo; Mon, 16 Feb 2004 15:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspY1-0002Rg-3F for sipping@optimus.ietf.org; Mon, 16 Feb 2004 15:40:57 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20059; Mon, 16 Feb 2004 15:40:54 -0500 (EST) Message-Id: <200402162040.PAA20059@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 16 Feb 2004 15:40:54 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-config-framework-02.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : A Framework for SIP User Agent Configuration Author(s) : D. Petrie Filename : draft-ietf-sipping-config-framework-02.txt Pages : 22 Date : 2004-2-16 This document defines the application of a set of protocols for configuring a SIP user agent. The SIP user agent must discover how and from where to retrieve its initial configuration and be notified of changes and updates which impact its configuration. The objective is to define a means for automatically configuring a user agent such that it can be functional without user or administrative intervention. The framework for discovery, delivery, notification and updates of user agent configuration is defined here. This framework is also intended to ease ongoing administration, configuration and upgrading of large scale deployments of SIP user agents. The contents and format of the configuration data to be defined is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-config-framework-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-config-framework-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-16123254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-config-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-config-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16123254.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 16 16:40:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29012 for ; Mon, 16 Feb 2004 16:40:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqTG-0000cz-FT for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 16:40:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GLe5Bw002406 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 16:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqTE-0000cj-MD for sipping-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 16:40:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28971 for ; Mon, 16 Feb 2004 16:40:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqTC-0004RE-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 16:40:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsqSC-0004Ja-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 16:39:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsqRK-0004CP-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 16:38:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqRI-0000O9-L8; Mon, 16 Feb 2004 16:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqQz-0000Hn-Tv for sipping@optimus.ietf.org; Mon, 16 Feb 2004 16:37:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28716 for ; Mon, 16 Feb 2004 16:37:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqQx-000491-00 for sipping@ietf.org; Mon, 16 Feb 2004 16:37:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsqPy-00041f-00 for sipping@ietf.org; Mon, 16 Feb 2004 16:36:43 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsqP1-0003qe-00 for sipping@ietf.org; Mon, 16 Feb 2004 16:35:43 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1GLZBNr005275; Mon, 16 Feb 2004 16:35:15 -0500 (EST) Message-ID: <40313789.3010409@dynamicsoft.com> Date: Mon, 16 Feb 2004 16:35:05 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Xuewen Li CC: sipping@ietf.org Subject: Re: [Sipping] SIP support for hold and ringback for operator / 911 services References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Here is my opinion FWIW. You need to be careful how you define these services. You want to make sure they work and are sensible for a broad range of devices, including, for example, a PC application or a wireless phone, where there is no hook at all. Firstly, I think it makes sense that, when the caller reaches 911, there is information in the 200 OK that indicates that the caller has reached an emergency service center. The callee capabilities framework would allow the 200 OK to INVITE to contain a parameter indicating this, for example, actor="emergency-center". When this is conveyed to the caller, the caller can take whatever UI action is necesary to indicate to them that they shouldnt try to hangup the call. Of course authentication is of the utmost importance here. Henning's emergency architecture draft alludes to such an indication but I didnt see any specific text on it. Should the caller anyway send a BYE, the UAS (the emergency center) can reject that BYE with a new response code, to indicate that the call cannot be disconnected because its an emergency operator. This way, an automata would explicitly know that this was not some normal error, and that the UI should not be dismissed. There is a temptation to try and add a state to the dialog event package so that the emergency operator can know that the caller is still trying to disconnect the call (ie, "on-hook"). This way, if the caller stops trying to disconnect, i.e., goes back "off-hook", the emergency service center would cease any attempts at interacting with the user to get them to pick up. The danger here is that we are effectively using the dialog package to model states of the *user interface*. Thats a dangerous game and a slippery slope. The last thing I want to do is get into a mode where, in order to deploy a new service, I need to add states to the dialog event package to represent some new state in the UI that was added to support the feature.... this is one of the problems with the IN model, IMHO. Indeed, this would lead me to conclude that the local ringback to alert the user to pick up is actually a LOCAL feature on the phone; if the user hangs up, and a BYE is sent, and a response code is received which indicates that the call is NOT terminated, the device itself would generate local rings to indicate to the user that they need to pick up as the call still exists. Such ringback would persist until the operator disconnects the call by sending a BYE. My argument here, and this argument is key - is that **this ringback is needed because of the physical nature of the UI, and the UI should not be of concern to the emergency service center**. In the case of a PC application, if a user clicked "hangup" and received this error response code, it would tell the user about the problem and not terminate the call. In this case, the UI is different, and the "ringback" is not necessary to alert the user of the problem. -Jonathan R. Xuewen Li wrote: > Has anyone looked into how the orig-hold and ringback function should be > supported in SIP? I realize that the wording may not be fully inline > with the SIP model, but this is a real issue to address. > > > > Note that some of the terms below are in quotes since they are TDM > telephony terms but are used in this context to represent logical > equivalent. For example, "offhook" represents the action to initiate a > call and "onhook" represents the action to end the call. > > > > Orig-hold refers to the ability to keep the call even when the > originator goes "onhook" before the operator releases the call. The 911 > operator is notified of such event (i.e., the caller has gone "onhook") > so that the operator can initiate ringback (a special physical ringing > is applied.) When the caller goes "offhook", no "dial tone" is provided. > Rather the caller is reconnected to the original call to the 911 operator. > > > > When the caller is served by a softswitch which is connected to the 911 > tandem via a SIP interface, SIP support for such functionality is required. > > > > Let's assume UA_a represents the caller, and UA_b represents the 911 > operator. > > > > CMSS has a DCS-OSPS header (tag value = RING) which provides the > mechanism for UA_b to request the "physical ringback". However the > following pieces are missing. > > 1. Some way to communicate the caller's capabilities, e.g., supports > orig-hold or not > > 2. Some mechanism to allow UA_b to request UA_a to apply orig-hold > for this call. > > 3. Some mechanism for UA_b to subscribe to UA_a's "onhook" or > "offhook" state changes. One can argue whether or not these are session > states... > > 4. Some mechanism for UA_a to notify UA_b the state changes of UA_a > > > > For item 1, will the ALLOW header be appropriate? > > For item 2, the DCS-OSPS header (tagvalue=RING) can be used > > For item 3 and 4, will the SUBSCRIBE / NOTIFY mechanism be appropriate? > > > > Any thoughts, comment? > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 16 16:47:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29557 for ; Mon, 16 Feb 2004 16:47:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqZY-00012O-55 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 16:46:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GLkaiG003982 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 16:46:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqZY-000129-1D for sipping-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 16:46:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29515 for ; Mon, 16 Feb 2004 16:46:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqZV-0005AJ-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 16:46:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsqYc-00057J-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 16:45:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsqY7-00054D-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 16:45:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqY3-0000qy-9U; Mon, 16 Feb 2004 16:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqXk-0000qF-8Z for sipping@optimus.ietf.org; Mon, 16 Feb 2004 16:44:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29455 for ; Mon, 16 Feb 2004 16:44:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqXi-00053U-00 for sipping@ietf.org; Mon, 16 Feb 2004 16:44:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsqWt-0004zI-00 for sipping@ietf.org; Mon, 16 Feb 2004 16:43:52 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsqW9-0004qC-00 for sipping@ietf.org; Mon, 16 Feb 2004 16:43:05 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1GLgcNr005285 for ; Mon, 16 Feb 2004 16:42:38 -0500 (EST) Message-ID: <40313947.3090803@dynamicsoft.com> Date: Mon, 16 Feb 2004 16:42:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Update to session policy requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I've submitted an update to the session policy requirements. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sipping-session-policy-req-01.txt The changes from the previous version are: * separation of the requirements for policy-specific data (i.e., codec trimming) from policy primitives that are independent of the specific policy. * added requirements for policies that are independent of the session, and learned by the device when it starts No doubt the requirements will evolve as we work the specific protocol proposals. Updates to those drafts are pending as well. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 16 16:49:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29638 for ; Mon, 16 Feb 2004 16:49:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqbT-0001E9-AR for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 16:48:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GLmZl0004711 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 16:48:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqbT-0001Ds-3H for sipping-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 16:48:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29619 for ; Mon, 16 Feb 2004 16:48:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqbQ-0005Ih-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 16:48:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asqab-0005FA-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 16:47:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsqZv-0005C3-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 16:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqZx-00012z-1d; Mon, 16 Feb 2004 16:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqZW-000120-La for sipping@optimus.ietf.org; Mon, 16 Feb 2004 16:46:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29512 for ; Mon, 16 Feb 2004 16:46:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqZU-0005A5-00 for sipping@ietf.org; Mon, 16 Feb 2004 16:46:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsqYb-000574-00 for sipping@ietf.org; Mon, 16 Feb 2004 16:45:38 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsqXo-0004zj-00 for sipping@ietf.org; Mon, 16 Feb 2004 16:44:49 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1GLiNNr005291 for ; Mon, 16 Feb 2004 16:44:24 -0500 (EST) Message-ID: <403139B2.4080509@dynamicsoft.com> Date: Mon, 16 Feb 2004 16:44:18 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Update to caller preferences use cases Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I've submitted a minor update to the caller preferences use case specification. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-sipping-callerprefs-usecases-01.txt The only changes were some bug fixes reported by Paul. There are still a few major todo's, and in particular, documentation of an example of how to implement the matching algorithm. I just didnt get around to it this time. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 16 18:51:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12843 for ; Mon, 16 Feb 2004 18:51:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssWS-00005N-TM for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 18:51:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GNpWJt000323 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 18:51:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssWS-000058-Ok for sipping-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 18:51:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12677 for ; Mon, 16 Feb 2004 18:51:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AssWP-0005Ju-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 18:51:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AssUa-0004ya-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 18:49:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AssTc-0004sa-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 18:48:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AssRE-0006cy-JP for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 18:46:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssR8-00085L-9t; Mon, 16 Feb 2004 18:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssQw-00083p-9V for sipping@optimus.ietf.org; Mon, 16 Feb 2004 18:45:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12194 for ; Mon, 16 Feb 2004 18:45:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AssQt-0004bF-00 for sipping@ietf.org; Mon, 16 Feb 2004 18:45:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AssPt-0004WD-00 for sipping@ietf.org; Mon, 16 Feb 2004 18:44:45 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AssPS-0004S9-00 for sipping@ietf.org; Mon, 16 Feb 2004 18:44:18 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1GNhP5d001686 for ; Mon, 16 Feb 2004 18:43:25 -0500 (EST) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1GNhOH00576 for ; Mon, 16 Feb 2004 18:43:25 -0500 Message-ID: <4031559C.1030600@cs.columbia.edu> Date: Mon, 16 Feb 2004 18:43:24 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] draft-ietf-sipping-config-framework: discovery Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I wonder why the UA doesn't (also) contact its home AOR, rather than just a local server discovered by DHCP. In many cases, this is what I want when I'm in a remote network. Clearly, this requires that the device knows its AOR and thus it can't start from a blank slate, but that information is available in many circumstances. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 16 20:51:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18674 for ; Mon, 16 Feb 2004 20:51:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsuNo-0008E7-Nu for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 20:50:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H1oi4B031619 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 20:50:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsuNo-0008Du-HN for sipping-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 20:50:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18659 for ; Mon, 16 Feb 2004 20:50:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsuNm-00067c-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 20:50:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsuMr-000651-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 20:49:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsuMD-000626-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 20:49:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsuM9-00081g-EL; Mon, 16 Feb 2004 20:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsuLq-000812-Bx for sipping@optimus.ietf.org; Mon, 16 Feb 2004 20:48:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18585 for ; Mon, 16 Feb 2004 20:48:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsuLo-00060c-00 for sipping@ietf.org; Mon, 16 Feb 2004 20:48:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsuKt-0005xf-00 for sipping@ietf.org; Mon, 16 Feb 2004 20:47:44 -0500 Received: from [147.6.42.145] (helo=filter1.kt.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AsuKU-0005ut-00 for sipping@ietf.org; Mon, 16 Feb 2004 20:47:19 -0500 Received: from external ([147.6.9.113]) by filter1 (1.0) id i1H1kD416302; Tue, 17 Feb 2004 10:46:13 +0900 Message-ID: <004901c3f4f7$db4382c0$71090693@ROMEO> From: =?UTF-8?B?7Zmp7KeE6rK9?= To: "Jonathan Rosenberg" Cc: "Cullen Jennings" , "sipping" References: <004701c3f443$c74d6470$71090693@ROMEO> <4030F410.1050801@dynamicsoft.com> Subject: Re: [Sipping] draft-hwang-sipping-infomidcall-00.txt Date: Tue, 17 Feb 2004 10:46:26 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSByZWFsbHkgYXBwcmVjaWF0ZSB5b3VyIHdhcm1pbmcgY29tbWVudHMoOi0pLCBhcyBpdCBpcyBt eSBmaXJzdCBwYXJ0aWNpcGF0aW9uIGluIHRoaXMgV0cuDQoNCi0tLQ0KSSBrbm93IGN1cnJlbnRs eSByaWNoIHNlcnZpY2UgZmVhdHVyZXMgc3VjaCBhcyBDYWxsIHRyYW5zZmVyIGFuZCBDYWxsIHdh aXRpbmcgYXJlIGJhc2VkIG9uIFNJUCBlbmRwb2ludHMuDQoNCkNhbGwgdHJhbnNmZXIgcHJvY2Vk dXJlIGlzIHdlbGwgZGVmaW5lZCBieSB0aGUgUkVGRVIsDQphbmQgb3RoZXJzIGNhbiBiZSBwcm92 aWRlZCAgd2l0aCB0aGUgZnVuY3Rpb25zIG9mIHRoZSBwaG9uZS4NCg0KSG93ZXZlciwgaW4gdGhl IGVtZXJnaW5nIFNJUCBiYXNlZCBuZXh0IGdlbmVyYXRpb24gbmV0d29yaywgDQp0aGUgaW50ZWxs aWdlbmNlICdhbHNvJyBzaG91bGQgYmUgaW4gdGhlIG5ldHdvcmsuDQoNCldoYXQgSSBwcm9wb3Nl IGlzIE5PVCBjaGFuZ2UgY3VycmVudGx5IGRlZmluZWQgQ2FsbCB0cmFuc2ZlciBwcm9jZWR1cmUg QlVUDQpuZXR3b3JrIGJhc2VkIG1pZGNhbGwgZmVhdHVyZXMgYXJlIHRvIGJlIGNvbnNpZGVyZWQs DQpzaW5jZSBzZXJ2aWNlIG9wZXJhdG9yIGNhbiBtYWtlIHRoZSBzZXJ2aWNlcyBtb3JlIGZsZXhp YmxlLCBleHRlbnNpYmxlLCBhbmQgcmljaGVyLg0KDQpJTUhPLCANCnRoZSBTSVBQSU5HIFdHIHN0 YXJ0IHRvIGRpc2N1c3MgYWJvdXQgdGhlIG5ldHdvcmsgYmFzZWQgZmVhdHVyZXMgYW5kIHNlcnZp Y2UgZXhhbXBsZXMuLi4NCihvciBpcyBpdCB0aGUgcm9sZSBsaWtlIDNHUFAgPykNCg0KPiBBIFVS TCBmb3IgdGhpcyBkcmFmdCBpcyANCj4gDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWh3YW5nLXNpcHBpbmctaW5mb21pZGNhbGwtMDAudHh0DQoNCg0KU2luY2Vy ZWx5LA0KSmlua3l1bmcgSHdhbmcNCktUDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQpGcm9tOiAiSm9uYXRoYW4gUm9zZW5iZXJnIiA8amRyb3NlbkBkeW5hbWljc29mdC5jb20+DQpU bzogIu2ZqeynhOqyvSIgPGpraHdhbmdAa3QuY28ua3I+DQpDYzogIkN1bGxlbiBKZW5uaW5ncyIg PGZsdWZmeUBjaXNjby5jb20+OyAic2lwcGluZyIgPHNpcHBpbmdAaWV0Zi5vcmc+DQpTZW50OiBU dWVzZGF5LCBGZWJydWFyeSAxNywgMjAwNCAxOjQ3IEFNDQpTdWJqZWN0OiBSZTogW1NpcHBpbmdd IGRyYWZ0LWh3YW5nLXNpcHBpbmctaW5mb21pZGNhbGwtMDAudHh0DQoNCg0KPiBJIGFncmVlIHRo YXQgdGhlc2Ugc2VydmljZXMgYXJlIG5lZWRlZC4gSG93ZXZlciwgbWVjaGFuaXNtcyBhcmUgaW4g cGxhY2UgDQo+IHRvZGF5IGZvciBwZXJmb3JtaW5nIHRoZXNlIHNlcnZpY2VzLiBDYWxsIHRyYW5z ZmVyIGlzIGRvbmUgd2l0aCBSRUZFUiwgDQo+IGNhbGwgd2FpdGluZyBpcyBhIGxvY2FsIGZlYXR1 cmUgb24gdGhlIGRldmljZSwgYW5kIHRocmVlIHdheSBjYWxsaW5nIGNhbiANCj4gYmUgZG9uZSBs b2NhbGx5IG9yIHRocm91Z2ggaW52b2NhdGlvbiBvZiBhIGNlbnRyYWxpemVkIGNvbmZlcmVuY2lu ZyBzZXJ2ZXIuDQo+IA0KPiBJbiB0aGUgU0lwIHNlcnZpY2VzIG1vZGVsLCBhbGwgb2YgdGhlc2Ug ZmVhdHVyZXMgZG8gbm90IGxpdmUgaW4gYSANCj4gY2VudHJhbGl6ZWQgc2VydmVyIGluIHRoZSBu ZXR3b3JrLiBSYXRoZXIsIHRoZXkgYXJlIGRpc3RyaWJ1dGVkLCBhbmQgDQo+IGltcGxlbWVudGVk IGluIHRoZSBwbGFjZSBtb3N0IGFwcHJvcHJpYXRlIGZvciB0aGF0IHNlcnZpY2UuIEluIGFuIElQ IA0KPiBuZXR3b3JrLCB0aGUgZW5kcG9pbnRzIGhhdmUgZ3JlYXRlciBpbnRlbGxpZ2VuY2UgdGhh biBpbiB0aGUgUFNUTi4gDQo+IEhhdmluZyBzbWFydGVyIGVuZHBvaW50cyBtZWFucyB0aGF0IHlv dSBjYW4gaGF2ZSBhIGJldHRlciBvdmVyYWxsIA0KPiBzZXJ2aWNlIGV4cGVyaWVuY2UgYW5kIHN1 cHBvcnQgYSBicm9hZGVyIHJhbmdlIG9mIGRldmljZXMuDQo+IA0KPiBNR0NQIHRha2VzIHRoZSBw b3NpdGlvbiB5b3UgYXJlIGFkdm9jYXRpbmcsIHRoYXQgdGhlIHNlcnZpY2VzIGFsbCBsaXZlIA0K PiBpbiBhIGNlbnRyYWxpemVkIHBsYWNlLiBDdWxsZW4ncyBwb2ludCwgSSBiZWxpZXZlLCBpcyB0 aGF0LCBpZiB0aGUgYWltIA0KPiBpcyB0byBkZXZlbG9wIHByb3RvY29scyB0byBzdXBwb3J0IGEg bW9kZWwgb2YgY2VudHJhbGl6ZWQgc2VydmljZSANCj4gY29udHJvbCwgd2UgYWxyZWFkeSBoYXZl IHRoYXQgLSBtZ2NwLg0KPiANCj4gVGhhbmtzLA0KPiBKb25hdGhhbiBSLg0KPiANCj4g7Zmp7KeE 6rK9IHdyb3RlOg0KPiANCj4gPiBUaGFuayB5b3UgZm9yIHRoZSBxdWVzdGlvbi4NCj4gPiANCj4g PiBZb3VyIHF1ZXN0aW9uIGlzIHdoeSBuZXR3b3JrLWJhc2VkIG1pZGNhbGwgaXMgbmVlZGVkIHdp dGggU0lQLg0KPiA+IA0KPiA+IE15IGFuc3dlciBpcyB0aGF0DQo+ID4gU2luY2Ugc2VydmljZSBj b21wb25lbnRzIGluIHRoZSBuZXh0IGdlbiBJUCBuZXR3b3JrIGFyZSBiYXNlZCBvbiBTSVAsDQo+ ID4gdGhlIGRlbGl2ZXJ5IG9mIG1pZGNhbGwgaW5mb3JtYXRpb24gc2hvdWxkIGJlIHRocm91Z2gg U0lQIG1ldGhvZC4NCj4gPiANCj4gPiBTaW1wbGUgSU5GTyAoZnJvbSB0aGUgU0lQIHBob25lIG9y IGZyb20gdGhlIE1HQyhieSB0cmFuc2xhdGlvbikpIHdvcmtzIHZlcnkgd2VsbCwNCj4gPiBhcyB3 ZSBpbXBsZW1lbnRlZCB0cmlhbCBzZXJ2aWNlcyB3aXRoIHRoaXMgSU5GTyBtaWRjYWxsIGZ1bmN0 aW9uIGJvdGggaW4gU0lQIHBob25lIGFuZCBTb2Z0c3dpdGNoLg0KPiA+IA0KPiA+IE15IHByb3Bv c2FsIGlzIHRoYXQgaW4gc3RhbmRhcmQgU0lQIHBob25lIChVQSkgaGF2ZSBtaWRjYWxsIGJ1dHRv biBzaW1wbHkgaW5pdGlhdGluZyBJTkZPIA0KPiA+IHdoZW4gdGhlIGJ1dHRvbiBpcyBwcmVzc2Vk Lg0KPiA+IA0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPiBUaXRsZTogSU5GTyBVc2FnZSBFeGFtcGxlcyBmb3IgTmV0d29yay1iYXNlZCBNaWQtQ2Fs bCBTZXJ2aWNlIA0KPiA+IEF1dGhvcjogSmlua3l1bmcgSHdhbmcgKEtUKQ0KPiA+IA0KPiA+IEFi c3RyYWN0Og0KPiA+IA0KPiA+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIElORk8gdXNh Z2UgZXhhbXBsZXMgZm9yIG5ldHdvcmsgYmFzZWQgDQo+ID4gICBtaWQtY2FsbCBzZXJ2aWNlLiBN aWQtY2FsbCBiYXNlZCBzZXJ2aWNlcyBhcmUgZm9yIGV4YW1wbGUsIENhbGwgDQo+ID4gICBUcmFu c2ZlciwgQ2FsbCBXYWl0aW5nLCBhbmQgVGhyZWUtV2F5IENhbGxpbmcuIE90aGVyIHBvc3NpYmxl IG1pZC0NCj4gPiAgIGNhbGwgc2VydmljZXMgYXJlIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVu IG1vcmUgaW4gSVAgbXVsdGltZWRpYSANCj4gPiAgIG5ldHdvcmsuIFRoZSBjYXNlcyBkZXNjcmli ZWQgaW4gU0lQIHNlcnZpY2UgZXhhbXBsZXMgKGRyYWZ0LWlldGYtDQo+ID4gICBzaXBwaW5nLXNl cnZpY2UtZXhhbXBsZXMtMDUpIGFyZSBUZXJtaW5hbC1iYXNpcy4gU2luY2UgdGhlIHNlcnZpY2Ug DQo+ID4gICBwcm9jZWR1cmVzIGFyZSBmaXhlZCBpbiB0aGUgVGVybWluYWwsIHRoZSBmZWF0dXJl cyBhcmUgbm90IGV4dGVuc2libGUuIA0KPiA+ICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyBuZXR3 b3JrLWJhc2VkIG1pZC1jYWxsIGNvbnRyb2wgbWVjaGFuaXNtIHdpdGggDQo+ID4gICBJTkZPIGFu ZCBzaG93cyBleGFtcGxlcyB0aGF0IHNpbXBsZSBtaWQtY2FsbCByZXF1ZXN0IChJTkZPKSBmcm9t IHRoZSANCj4gPiAgIFRlcm1pbmFsLCB0aGVuIHRoZSBuZXR3b3JrIGFwcGxpY2F0aW9uIHNlcnZl ciBwcm92aWRlIHZhcmlvdXMgbWlkLWNhbGwgDQo+ID4gICBzZXJ2aWNlcyBieSBwcm9tcHRpbmcg dXNlciB0aHJvdWdoIHRoZSBNZWRpYSBTZXJ2ZXIsIGFjY29yZGluZyB0byB0aGUgDQo+ID4gICBz dWJzY3JpcHRpb24gaW5mb3JtYXRpb24gb2YgdGhlIHVzZXIuIA0KPiA+IA0KPiA+IEEgVVJMIGZv ciB0aGlzIGRyYWZ0IGlzIA0KPiA+IA0KPiA+ICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1od2FuZy1zaXBwaW5nLWluZm9taWRjYWxsLTAwLnR4dA0KPiA+IA0KPiA+ IA0KPiA+IEJSDQo+ID4gDQo+ID4gSmlua3l1bmcgSHdhbmcNCj4gPiBLVA0KPiA+IA0KPiA+IC0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+ID4gRnJvbTogIkN1bGxlbiBKZW5uaW5ncyIg PGZsdWZmeUBjaXNjby5jb20+DQo+ID4gVG86ICJzaXBwaW5nIiA8c2lwcGluZ0BpZXRmLm9yZz4N Cj4gPiBTZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMTQsIDIwMDQgMToyNiBBTQ0KPiA+IFN1Ympl Y3Q6IFtTaXBwaW5nXSBkcmFmdC1od2FuZy1zaXBwaW5nLWluZm9taWRjYWxsLTAwLnR4dA0KPiA+ IA0KPiA+IA0KPiA+IA0KPiA+PiAgICANCj4gPj5XaHkgbm90IGp1c3QgdXNlIE1HQ1AgaW5zdGVh ZCBvZiBTSVAgaWYgeW91IHdhbnQgdG8gZG8gdGhpcy4gSXQgd2lsbCB3b3JrDQo+ID4+bXVjaCBi ZXR0ZXIuIA0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4+U2lwcGluZyBtYWlsaW5nIGxpc3QgIGh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcHBpbmcNCj4gPj5UaGlzIGxpc3QgaXMg Zm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgYXBwbGljYXRpb24gb2YgU0lQDQo+ID4+VXNlIHNp cC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBz aXANCj4gPj5Vc2Ugc2lwQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9mIGNvcmUgU0lQ DQo+ID4+SippeCZqKWIgYm0/IDAnfmZmWCnfoyI4YlgrH0RZ1696WilheWknGionPUseKmJePxwl Zmlufi13LsipUsesKysdeih9K3kiDw0KPiANCj4gLS0gDQo+IEpvbmF0aGFuIEQuIFJvc2VuYmVy ZywgUGguRC4gICAgICAgICAgICAgICAgNjAwIExhbmlkZXggUGxhemENCj4gQ2hpZWYgVGVjaG5v bG9neSBPZmZpY2VyICAgICAgICAgICAgICAgICAgICBQYXJzaXBwYW55LCBOSiAwNzA1NC0yNzEx DQo+IGR5bmFtaWNzb2Z0DQo+IGpkcm9zZW5AZHluYW1pY3NvZnQuY29tICAgICAgICAgICAgICAg ICAgICAgRkFYOiAgICg5NzMpIDk1Mi01MDUwDQo+IGh0dHA6Ly93d3cuamRyb3Nlbi5uZXQgICAg ICAgICAgICAgICAgICAgICAgUEhPTkU6ICg5NzMpIDk1Mi01MDAwDQo+IGh0dHA6Ly93d3cuZHlu YW1pY3NvZnQuY29tDQo+IA== _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 16 22:43:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24236 for ; Mon, 16 Feb 2004 22:43:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asw8J-0000r3-Sk for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 22:42:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H3gpgq003285 for sipping-archive@odin.ietf.org; Mon, 16 Feb 2004 22:42:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asw8J-0000qu-PN for sipping-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 22:42:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24202 for ; Mon, 16 Feb 2004 22:42:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asw8G-0007j7-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 22:42:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asw7M-0007ek-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 22:41:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asw6c-0007ZB-00 for sipping-web-archive@ietf.org; Mon, 16 Feb 2004 22:41:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asw6a-0000bD-42; Mon, 16 Feb 2004 22:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asw6O-0000a9-Th for sipping@optimus.ietf.org; Mon, 16 Feb 2004 22:40:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24096 for ; Mon, 16 Feb 2004 22:40:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asw6L-0007Ww-00 for sipping@ietf.org; Mon, 16 Feb 2004 22:40:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asw5R-0007NE-00 for sipping@ietf.org; Mon, 16 Feb 2004 22:39:54 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Asw4B-00076Q-00 for sipping@ietf.org; Mon, 16 Feb 2004 22:38:35 -0500 Received: from bear.cs.columbia.edu (IDENT:N47/36bfso5aRBaYe5fY6OBSGX9A80Um@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1H3cR5e011760 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 16 Feb 2004 22:38:27 -0500 (EST) Received: from cs.columbia.edu (pool-141-153-198-80.mad.east.verizon.net [141.153.198.80]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1H3cOmi001389 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 16 Feb 2004 22:38:25 -0500 Message-ID: <40318CA9.9090201@cs.columbia.edu> Date: Mon, 16 Feb 2004 22:38:17 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Jonathan Rosenberg CC: Xuewen Li , sipping@ietf.org Subject: Re: [Sipping] SIP support for hold and ringback for operator / 911 services References: <40313789.3010409@dynamicsoft.com> In-Reply-To: <40313789.3010409@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Jonathan that end system intelligence is the answer here. After all, end systems have an interest in making emergency services work. The -sos- draft (the version -01 that was refused since the -00 version was submitted just before the deadline...) defines the 'service' media feature tag for that, which includes plain 'sos' and the various sub-services (sos.fire, etc.). However, this is only necessary if the caller didn't know already that this was an emergency call. By the mechanism defined in the -sos- draft, it should, in almost all cases know this and thus be able to adjust UI behavior accordingly. A simple 403 (Forbidden), in conjunction with the callee capabilities tag, should be sufficient as response to a premature BYE. The problem with the approach of having the callee identify itself as a emergency call center and thereby modify caller behavior is that lends itself to pranks. Call my number and you can't hang up the phone until I let you. Telemarketers will love that feature :-) (If the calling UA knows it's an emergency call, there is no need for the feature tag indication to control services.) Jonathan Rosenberg wrote: > Firstly, I think it makes sense that, when the caller reaches 911, there > is information in the 200 OK that indicates that the caller has reached > an emergency service center. The callee capabilities framework would > allow the 200 OK to INVITE to contain a parameter indicating this, for > example, actor="emergency-center". When this is conveyed to the caller, > the caller can take whatever UI action is necesary to indicate to them > that they shouldnt try to hangup the call. Of course authentication is > of the utmost importance here. Henning's emergency architecture draft > alludes to such an indication but I didnt see any specific text on it. > > Should the caller anyway send a BYE, the UAS (the emergency center) can > reject that BYE with a new response code, to indicate that the call > cannot be disconnected because its an emergency operator. This way, an > automata would explicitly know that this was not some normal error, and > that the UI should not be dismissed. > > There is a temptation to try and add a state to the dialog event package > so that the emergency operator can know that the caller is still trying > to disconnect the call (ie, "on-hook"). This way, if the caller stops > trying to disconnect, i.e., goes back "off-hook", the emergency service > center would cease any attempts at interacting with the user to get them > to pick up. > > The danger here is that we are effectively using the dialog package to > model states of the *user interface*. Thats a dangerous game and a > slippery slope. The last thing I want to do is get into a mode where, in > order to deploy a new service, I need to add states to the dialog event > package to represent some new state in the UI that was added to support > the feature.... this is one of the problems with the IN model, IMHO. > > Indeed, this would lead me to conclude that the local ringback to alert > the user to pick up is actually a LOCAL feature on the phone; if the > user hangs up, and a BYE is sent, and a response code is received which > indicates that the call is NOT terminated, the device itself would > generate local rings to indicate to the user that they need to pick up > as the call still exists. Such ringback would persist until the operator > disconnects the call by sending a BYE. My argument here, and this > argument is key - is that **this ringback is needed because of the > physical nature of the UI, and the UI should not be of concern to the > emergency service center**. > > In the case of a PC application, if a user clicked "hangup" and received > this error response code, it would tell the user about the problem and > not terminate the call. In this case, the UI is different, and the > "ringback" is not necessary to alert the user of the problem. > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 02:02:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02415 for ; Tue, 17 Feb 2004 02:02:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AszEv-0006Wt-F6 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 02:01:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H71rwu025087 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 02:01:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AszEu-0006WR-Lh for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 02:01:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01829 for ; Tue, 17 Feb 2004 02:01:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AszEr-0002hs-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 02:01:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AszDw-0002ek-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 02:00:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AszDF-0002by-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 02:00:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AszDA-0005j0-Lc; Tue, 17 Feb 2004 02:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AszCz-0005hK-UO for sipping@optimus.ietf.org; Tue, 17 Feb 2004 01:59:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29697 for ; Tue, 17 Feb 2004 01:59:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AszCw-0002bS-00 for sipping@ietf.org; Tue, 17 Feb 2004 01:59:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AszC5-0002Z1-00 for sipping@ietf.org; Tue, 17 Feb 2004 01:58:58 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AszBo-0002WC-00 for sipping@ietf.org; Tue, 17 Feb 2004 01:58:40 -0500 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1H6wBNr005526; Tue, 17 Feb 2004 01:58:12 -0500 (EST) Message-ID: <4031BB7A.2040702@dynamicsoft.com> Date: Tue, 17 Feb 2004 01:58:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Xuewen Li , sipping@ietf.org Subject: Re: [Sipping] SIP support for hold and ringback for operator / 911 services References: <40313789.3010409@dynamicsoft.com> <40318CA9.9090201@cs.columbia.edu> In-Reply-To: <40318CA9.9090201@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I agree with Jonathan that end system intelligence is the answer here. > After all, end systems have an interest in making emergency services work. > > The -sos- draft (the version -01 that was refused since the -00 version > was submitted just before the deadline...) defines the 'service' media > feature tag for that, which includes plain 'sos' and the various > sub-services (sos.fire, etc.). However, this is only necessary if the > caller didn't know already that this was an emergency call. By the > mechanism defined in the -sos- draft, it should, in almost all cases > know this and thus be able to adjust UI behavior accordingly. > > A simple 403 (Forbidden), in conjunction with the callee capabilities > tag, should be sufficient as response to a premature BYE. I really think you will want a new response code here. My concern is that an application will effectively ignore the 403 and terminate the call anyway. I'd rather have a very explicit response code, so that its clear that the call cannot be terminated because its an emergency call. > > The problem with the approach of having the callee identify itself as a > emergency call center and thereby modify caller behavior is that lends > itself to pranks. Call my number and you can't hang up the phone until I > let you. Telemarketers will love that feature :-) This seems like an S/MIME application that might actually even be deployable. In principal, I would think that someone (NENA??) could hand out certs that do, in fact, certify that a user is an operator in an emergency service center. If a call I make completes to an user that has a cert declaring them as an emergency operation, my UA wouldn't allow me to terminate the call. > > (If the calling UA knows it's an emergency call, there is no need for > the feature tag indication to control services.) True. However, I can imagine cases where the call doesnt start as an emergency call, but turns into one. For example, what if I use some kind of call routing app where the destination number can be entered via stimulus (i.e., prepaid calling?). Maybe this is unsolvable, but the case does exist. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 02:55:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15362 for ; Tue, 17 Feb 2004 02:55:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At04F-0002BL-72 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 02:54:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H7stMO008381 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 02:54:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At04E-0002B6-R3 for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 02:54:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15335 for ; Tue, 17 Feb 2004 02:54:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At04A-0006ph-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 02:54:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At03G-0006mP-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 02:53:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At02O-0006j8-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 02:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At02Q-0001y5-NI; Tue, 17 Feb 2004 02:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsjHR-0007p1-FH for sipping@optimus.ietf.org; Mon, 16 Feb 2004 08:59:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18478 for ; Mon, 16 Feb 2004 08:59:22 -0500 (EST) From: schatterjee@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsjHP-0005t5-00 for sipping@ietf.org; Mon, 16 Feb 2004 08:59:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsjGU-0005ke-00 for sipping@ietf.org; Mon, 16 Feb 2004 08:58:26 -0500 Received: from [164.164.94.116] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1AsjFQ-0005dM-00; Mon, 16 Feb 2004 08:57:21 -0500 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i1GDtrD20441; Mon, 16 Feb 2004 19:26:03 +0530 To: sipping@ietf.org, sip@ietf.org, schulzrinne@cs.columbia.edu, jmpolk@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Mon, 16 Feb 2004 19:26:30 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 02/16/2004 07:26:56 PM, Serialize complete at 02/16/2004 07:26:56 PM Content-Type: multipart/alternative; boundary="=_alternative 004C9F4365256E3C_=" Subject: [Sipping] Question regarding resource-priority header Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 004C9F4365256E3C_= Content-Type: text/plain; charset="US-ASCII" Hi, In draft-ietf-sip-resource-priority-01.txt, it looks like there is a printing mistake in the grammar defined for Resource-Priority header . Its given as Resource-Priority = "Resource-Priority" HCOLON (*COMMA Resource-value) But I guess, no header can start with a COMMA . It should actually be Resource-Priority = "Resource-Priority" HCOLON Resource-value(*COMMA Resource-value) This is the way the grammar is given for Accept-Resource-Priority. Can anyone confirm on this pls? thanks in advance... --=_alternative 004C9F4365256E3C_= Content-Type: text/html; charset="US-ASCII"
Hi,

In draft-ietf-sip-resource-priority-01.txt, it looks like there is a printing mistake in the grammar defined for Resource-Priority header . Its given as
       Resource-Priority  =  "Resource-Priority" HCOLON
                              (*COMMA Resource-value)
 
But I guess, no header can start with a COMMA . It should actually be
       Resource-Priority  =  "Resource-Priority" HCOLON
                              Resource-value(*COMMA Resource-value)

This is the way the grammar is given for Accept-Resource-Priority.
Can anyone confirm on this pls?

thanks in advance...
--=_alternative 004C9F4365256E3C_=-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 09:27:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29626 for ; Tue, 17 Feb 2004 09:27:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6Bl-0003VM-8f for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 09:27:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HER5pc013466 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 09:27:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6Bk-0003V7-K8 for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 09:27:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29583 for ; Tue, 17 Feb 2004 09:27:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6Bi-0002vc-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 09:27:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6An-0002s7-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 09:26:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At69y-0002pW-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 09:25:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At69n-0003KF-Dd; Tue, 17 Feb 2004 09:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At68z-0003Hs-6h for sipping@optimus.ietf.org; Tue, 17 Feb 2004 09:24:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29408 for ; Tue, 17 Feb 2004 09:24:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At68x-0002ky-00 for sipping@ietf.org; Tue, 17 Feb 2004 09:24:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At686-0002gW-00 for sipping@ietf.org; Tue, 17 Feb 2004 09:23:18 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1At67C-0002Xx-00 for sipping@ietf.org; Tue, 17 Feb 2004 09:22:22 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2004 06:30:35 +0000 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 i1HELn4U027861; Tue, 17 Feb 2004 06:21:49 -0800 (PST) Received: from oranpb.cisco.com (oranpb.cisco.com [64.101.150.196]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMK24952; Tue, 17 Feb 2004 06:21:48 -0800 (PST) Date: Mon, 16 Feb 2004 16:31:15 -0500 From: "David R. Oran" To: Jonathan Rosenberg , sipping Subject: Re: [Sipping] URGENT: query on another reg-event change Message-ID: <2147483647.1076949075@localhost> In-Reply-To: <4031065B.9050500@dynamicsoft.com> References: <4031065B.9050500@dynamicsoft.com> X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========EF0732482CC930D821A4==========" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=DATE_IN_PAST_06_12 autolearn=no version=2.60 --==========EF0732482CC930D821A4========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Monday, February 16, 2004 1:05 PM -0500 Jonathan Rosenberg=20 wrote: > Folks, > [snip] > Technically, my preference would be to define the unknown-param in > reg-event right now, and have extensions (like callerprefs and gruu) > specify xml schema extensions to reg-event for their data. > I agree pretty strongly. The more precision and granularity we can give to=20 the data model, along with the ability to naturally extend this schema=20 without an ever-increasing "garbage can" of opaque data, the better off we=20 will be going forward. I don't think it's such a burden for a client to=20 have to look in two places to deal with servers that haven't caught up with = the schema changes. Dave. > Please provide comments on this proposal within the next few days. > > Thanks, > Jonathan R. > --==========EF0732482CC930D821A4========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAMTajjWaEtlTdKuYRAg6WAKD02Op5/ABccVRZts9qxTMXhzWPpgCgqzsd 2Vbfqyd9/7AayFrB8FW9ARc= =e0ca -----END PGP SIGNATURE----- --==========EF0732482CC930D821A4==========-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 10:00:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01105 for ; Tue, 17 Feb 2004 10:00:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6hl-0006jh-LR for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 10:00:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HF09NP025887 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 10:00:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6hj-0006gm-WE for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 10:00:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01046 for ; Tue, 17 Feb 2004 10:00:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6hh-0005Jh-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 10:00:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6gl-0005FU-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 09:59:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At6ft-0005B5-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 09:58:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6fi-0006LP-3i; Tue, 17 Feb 2004 09:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6eq-0006Ja-1q for sipping@optimus.ietf.org; Tue, 17 Feb 2004 09:57:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00809 for ; Tue, 17 Feb 2004 09:57:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6eo-00055S-00 for sipping@ietf.org; Tue, 17 Feb 2004 09:57:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6du-00051W-00 for sipping@ietf.org; Tue, 17 Feb 2004 09:56:11 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1At6d0-0004xI-00 for sipping@ietf.org; Tue, 17 Feb 2004 09:55:14 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1HEtC5d025688; Tue, 17 Feb 2004 09:55:12 -0500 (EST) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1HEtCH05012; Tue, 17 Feb 2004 09:55:12 -0500 Message-ID: <40322B50.9040907@cs.columbia.edu> Date: Tue, 17 Feb 2004 09:55:12 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Xuewen Li , sipping@ietf.org Subject: Re: [Sipping] SIP support for hold and ringback for operator / 911 services References: <40313789.3010409@dynamicsoft.com> <40318CA9.9090201@cs.columbia.edu> <4031BB7A.2040702@dynamicsoft.com> In-Reply-To: <4031BB7A.2040702@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > This seems like an S/MIME application that might actually even be > deployable. > > In principal, I would think that someone (NENA??) could hand out certs > that do, in fact, certify that a user is an operator in an emergency > service center. If a call I make completes to an user that has a cert > declaring them as an emergency operation, my UA wouldn't allow me to > terminate the call. We've talked about this in the various emergency calling discussions and nobody who knows anything about the current 911 system, which is highly localized and decentralized, had any hope that this can work in the foreseeable future. We won't even talk about the difficulties of making this work internationally. This gets more complicated in practice since you have the various 'telematics' providers such as OnStar. This is even more difficult than asserting an identity; Jon's trait-based auth draft, if I read it right, essentially says that trait (or role-based) authentication is only going to work in either a single administration or a federated one. The 911 system in the US is the opposite of both :-) I've suggested to various NENA folks that they should look into this as a long-term goal, as it would simplify other things, but given that the solution is already specified for the callee caps case (in sos-01), there's probably not much you can do. The 'cannot hang up during emergency calls' is mostly a canard - many existing analog systems don't have that property and nobody has been able to find a rule that says that this is a required feature. Given the many other ways you can lose contact with the ECC/PSAP, it is unclear that this adds much value in practice. The emergency-arch draft (like most existing systems) does specify call-back capability, which seems more useful and practical. > > >> >> (If the calling UA knows it's an emergency call, there is no need for >> the feature tag indication to control services.) > > > True. However, I can imagine cases where the call doesnt start as an > emergency call, but turns into one. For example, what if I use some kind > of call routing app where the destination number can be entered via > stimulus (i.e., prepaid calling?). Maybe this is unsolvable, but the > case does exist. I'm not disagreeing with the desirability of indicating that somebody answering is an emergency call taker. I'm concerned that we simply do "and then magic happens and everybody agrees on a CA for emergency calls" since the problem is then somebody else's. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 11:06:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10525 for ; Tue, 17 Feb 2004 11:06:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7jp-0006PM-Dr for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 11:06:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HG6LoK024632 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 11:06:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7jo-0006PD-Mj for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 11:06:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10376 for ; Tue, 17 Feb 2004 11:06:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7jm-0005tl-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:06:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7iE-0005YZ-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:04:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At7fj-0004zV-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:02:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7fd-0005ai-U6; Tue, 17 Feb 2004 11:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7fM-0005Yv-BJ for sipping@optimus.ietf.org; Tue, 17 Feb 2004 11:01:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09409 for ; Tue, 17 Feb 2004 11:01:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7fJ-0004u8-00 for sipping@ietf.org; Tue, 17 Feb 2004 11:01:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7cd-0004MF-00 for sipping@ietf.org; Tue, 17 Feb 2004 10:58:56 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1At7bB-00044v-00 for sipping@ietf.org; Tue, 17 Feb 2004 10:57:25 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 17 Feb 2004 07:57:24 -0800 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 i1HFuq1m004299; Tue, 17 Feb 2004 07:56:53 -0800 (PST) Received: from [192.168.1.101] (sjc-vpn4-345.cisco.com [10.21.81.89]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMK29820; Tue, 17 Feb 2004 07:56:52 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 17 Feb 2004 07:56:51 -0800 From: Cullen Jennings To: Brian Rosen , "'sipping@ietf.org'" Message-ID: In-Reply-To: <313680C9A886D511A06000204840E1CF070B63E0@whq-msgusr-02.pit.comms.marconi.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] comments on rosen-dns-sos Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One small nit on polygons. Need to specify that the vertexes are in clockwise order. Failing to do this caused endless arguments in air traffic control specifications of airspaces. Probably needs a way to deal with what geographic coordinate grid is being used or fix it. Should warn implementers that polygon will include the poles and the vertex may even be a pole. Polar flights have caused more than one geographic information system to crash. Many systems translate the 3 tupple coordinates into 4 tupple coordinates for all calculations to avoid the singularities that a spherical coordinate system introduces. Probably need a header format that allows an arbitrary number of vertexes - the top level polygons are going to be big. I don't like the implied additive subtractive form of the poly. I would prefer poly explicitly identify as additive or subtractive with the region covered being formed by taking the union of all the additive then subtracting each of the subtractive polygons. Points on a vertex or edge would be considered in the region for additive polygons and out for subtractive polygons. None of the polygons forming a region are allowed to share an edge. The altitudes need to be altitude ranges to specify a volume that can be clipped. Seems like you need this to figure out which floor in a building I am on. Recommend that min alt is include in the volume but max alt is outside the volume. The specification of points on the surface of the volume being in or out is important or users can, excuse the pun, fall thought the cracks. I was not sold on DNS to start with but your arguments about the pleasures of forming a new global root convinced me DNS is right if it will work. More text explaining it would work would make me feel warm and fluffy. Cullen _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 11:07:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10733 for ; Tue, 17 Feb 2004 11:07:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7kr-0006lJ-Fj for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 11:07:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HG7Odm025984 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 11:07:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7kq-0006kq-Fo for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 11:07:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10670 for ; Tue, 17 Feb 2004 11:07:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7kn-00065w-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:07:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7ju-0005vd-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:06:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At7iY-0005cK-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:05:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7iZ-0005tU-FI; Tue, 17 Feb 2004 11:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7hz-0005se-Ss for sipping@optimus.ietf.org; Tue, 17 Feb 2004 11:04:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09947 for ; Tue, 17 Feb 2004 11:04:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7hw-0005Um-00 for sipping@ietf.org; Tue, 17 Feb 2004 11:04:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7fF-0004tH-00 for sipping@ietf.org; Tue, 17 Feb 2004 11:01:39 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1At7cZ-0004Gf-00 for sipping@ietf.org; Tue, 17 Feb 2004 10:58:51 -0500 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 i1HFwIuA021002; Tue, 17 Feb 2004 07:58:19 -0800 (PST) Received: from [192.168.1.101] (sjc-vpn4-345.cisco.com [10.21.81.89]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMK29953; Tue, 17 Feb 2004 07:58:17 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 17 Feb 2004 07:58:16 -0800 From: Cullen Jennings To: Henning Schulzrinne , Message-ID: In-Reply-To: <402BEAD0.4080101@cs.columbia.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] sos - dead or alive Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think that a phone informing a user that SOS was broken is very important for this to work when it is needed. I would like to see a bit more text around the current text of: It is RECOMMENDED that user agents periodically automatically check for the availability of the "sos" identifier and alert the user if the check fails. The period of such automated checks SHOULDNOT be less than once per day and MUST be randomly placed over the testing interval. Some random not well thought out ideas off the top of my head... I would prefer MUST to RECOMMENDED since a recent informal poll at sipit made it quiet clear that most implementers view SHOULD level requirements as something to consider in the next lifetime. I'm not arguing that this poll means we should not use SHOULD in general, but I think due to the critical nature of this specification, we should be a little stronger than normal. I don't want vendors saying they support this RFC fully when they can't detect that a safety critical system is broken. I would prefer specific test times - something like the test should be performed at a random time between 12 and 36 hours. Phones must prominently display the information that 911 is broken using a display or by changing the dial tone on all calls. Would be nice to consider the impact of every phone doing this. Phones SHOULD not do a test immediately after booting. Phones MAY provide a UI to allow a user to manual imitate a test - this is very useful for someone that is trying to check a 911 system but does not want to wait 36 hours. Cullen _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 11:08:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10818 for ; Tue, 17 Feb 2004 11:08:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7lS-00079M-BO for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 11:08:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HG82kM027478 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 11:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7lR-000797-Rc for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 11:08:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10757 for ; Tue, 17 Feb 2004 11:07:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7lP-0006BS-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:07:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7kV-00061h-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:07:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At7jU-0005oq-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7jV-000668-Rx; Tue, 17 Feb 2004 11:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7j4-00063G-J3 for sipping@optimus.ietf.org; Tue, 17 Feb 2004 11:05:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10173 for ; Tue, 17 Feb 2004 11:05:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7j2-0005jI-00 for sipping@ietf.org; Tue, 17 Feb 2004 11:05:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7gh-0005EN-00 for sipping@ietf.org; Tue, 17 Feb 2004 11:03:10 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1At7e1-0004Wj-00 for sipping@ietf.org; Tue, 17 Feb 2004 11:00:21 -0500 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 i1HFxm4U001320; Tue, 17 Feb 2004 07:59:49 -0800 (PST) Received: from [192.168.1.101] (sjc-vpn4-345.cisco.com [10.21.81.89]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMK30061; Tue, 17 Feb 2004 07:59:47 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 17 Feb 2004 07:59:46 -0800 From: Cullen Jennings To: , "Elwell, John" Message-ID: In-Reply-To: <200401201505.KAA02437@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] comments on :draft-ietf-sipping-qsig2sip-04.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One major concern, Section 9.1.3 and 9.2.3 - PAI won't work for this as described in draft-jennings-sipping-connected-00. I highly recommend we talk about this on a phone call or in Korea and get it sorted out. Suggesting a solution here will just make solving this problem more complex. Even if you think that it does work, it is definitely a new semantic meaning of PAI that is not covered in any the current documents. This would require the qsig2sip document to be dealt with in the sip WG instead of sipping it it is going to extend the meaning of PAI. It is recognized that SIP is lacking in this area, there have been multiple drafts proposing solutions (including the work in draft-elwell-sip-state-update). I think it would be better to get one of theses solutions moving and just use it here. Few minor things: If the GW signs a sipfrag, what should be in the SubjectAltName of the certificate? Section 9.1 (and other places) The terminology "the gw trusts the next hop" is wrong and should be something more like "the GW is in the same trust domain (as defined in RFC 3325) as the next hop" Section 9.2.2 If the From is Anonymous, and there is no privacy value, then it should be treated as if there was a privacy value of id. NIT: I find reference style of "as described in [10]" much harder to read than " as described in RFC 3261 [10]" Cullen On 1/20/04 7:05 AM, "Internet-Drafts@ietf.org" wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Proposal Investigation > Working Group of the IETF. > > Title : Interworking between SIP and QSIG > Author(s) : J. Elwell > Filename : draft-ietf-sipping-qsig2sip-04.txt > Pages : 61 > Date : 2004-1-19 > > This document specifies interworking between the Session Initiation > Protocol (SIP) and QSIG within corporate telecommunication networks > (also known as enterprise networks). SIP is an Internet application- > layer control (signalling) protocol for creating, modifying, and > terminating sessions with one or more participants. These sessions > include, in particular, telephone calls. QSIG is a signalling > protocol for creating, modifying and terminating circuit-switched > calls, in particular telephone calls, within Private Integrated > Services Networks (PISNs). QSIG is specified in a number of ECMA > Standards and published also as ISO/IEC standards. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-04.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sipping-qsig2sip-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sipping-qsig2sip-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > Content-Type: text/plain > Content-ID: <2004-1-20102746.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-sipping-qsig2sip-04.txt > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 11:08:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10858 for ; Tue, 17 Feb 2004 11:08:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7lb-0007BS-E1 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 11:08:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HG8BPo027603 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 11:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7la-0007Aw-Kq for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 11:08:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10764 for ; Tue, 17 Feb 2004 11:08:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7lX-0006DP-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:08:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7kX-000627-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:07:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At7jW-0005p2-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7jX-0006AV-I8; Tue, 17 Feb 2004 11:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7jS-00065P-22 for sipping@optimus.ietf.org; Tue, 17 Feb 2004 11:05:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10244 for ; Tue, 17 Feb 2004 11:05:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7jP-0005nd-00 for sipping@ietf.org; Tue, 17 Feb 2004 11:05:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7hU-0005OI-00 for sipping@ietf.org; Tue, 17 Feb 2004 11:03:57 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1At7ev-0004hi-00 for sipping@ietf.org; Tue, 17 Feb 2004 11:01:18 -0500 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 i1HG0juA024472 for ; Tue, 17 Feb 2004 08:00:45 -0800 (PST) Received: from [192.168.1.101] (sjc-vpn4-345.cisco.com [10.21.81.89]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMK30145; Tue, 17 Feb 2004 08:00:44 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 17 Feb 2004 08:00:43 -0800 From: Cullen Jennings To: sipping Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] SDP in draft-ietf-sipping-transc-3pcc-00 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit SDP is a scary place so using SDP to separate the SDP bodies for A and B is scary. Consider the following use case: I have a transcoder that takes a audio from a UA connected to a microphone and another camera UA that sends video. I am going to feed both of these to a transcoder and produce a single mpeg output stream that contains both audio video. Here I need so specify that the input SDP has two IP addresses and the output has one. This would be even more complicated if one UA did the offer/ans in INV/200 while the other used the 200/ACK. Also related to all this, would be nice to be confident that pre conditions stuff worked while using all this. Anyways, I like the overall solution to all this stuff. I wish there was a better solution to separating the A+B, TA+TB information to the transcoder than adding more semantics to SDP. Cullen _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 11:25:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13257 for ; Tue, 17 Feb 2004 11:25:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At81r-0000JQ-H5 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 11:24:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HGOxKL001194 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 11:24:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At81r-0000JB-A9 for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 11:24:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13239 for ; Tue, 17 Feb 2004 11:24:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At81q-0001SD-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:24:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At80J-0001Ap-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:23:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1At7zA-00010G-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:22:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1At7zA-0004X5-9z for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:22:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7yz-0008On-68; Tue, 17 Feb 2004 11:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7yO-0008Ng-F1 for sipping@optimus.ietf.org; Tue, 17 Feb 2004 11:21:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12907 for ; Tue, 17 Feb 2004 11:21:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7yN-0000uL-00 for sipping@ietf.org; Tue, 17 Feb 2004 11:21:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7xS-0000l8-00 for sipping@ietf.org; Tue, 17 Feb 2004 11:20:27 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1At7w5-0000QR-00 for sipping@ietf.org; Tue, 17 Feb 2004 11:19:01 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1HGIW5d015698; Tue, 17 Feb 2004 11:18:32 -0500 (EST) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1HGIWH12502; Tue, 17 Feb 2004 11:18:32 -0500 Message-ID: <40323ED8.4090206@cs.columbia.edu> Date: Tue, 17 Feb 2004 11:18:32 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: sipping@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: sos - dead or alive Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I would prefer MUST to RECOMMENDED since a recent informal poll at sipit > made it quiet clear that most implementers view SHOULD level requirements as > something to consider in the next lifetime. I'm not arguing that this poll > means we should not use SHOULD in general, but I think due to the critical > nature of this specification, we should be a little stronger than normal. I > don't want vendors saying they support this RFC fully when they can't detect > that a safety critical system is broken. Gladly obliged. > > I would prefer specific test times - something like the test should be > performed at a random time between 12 and 36 hours. Phones must prominently Currently, there are about 200 million real 911 calls a year. Testing once per day would essentially impose this load once per day. While I don't think building proxies that can handle this is a bad idea (among other advantages, it provides ample margin of safety and load-resistance since real calls are then a tiny fraction of the test traffic), it does need to be considered. From local usage, I know that fire alarm bells at Columbia are tested weekly, so that may be a more reasonable schedule. > display the information that 911 is broken using a display or by changing > the dial tone on all calls. Would be nice to consider the impact of every > phone doing this. Phones SHOULD not do a test immediately after booting. > Phones MAY provide a UI to allow a user to manual imitate a test - this is > very useful for someone that is trying to check a 911 system but does not > want to wait 36 hours. I like the gist of this and have added appropriate text. > > Cullen > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 11:37:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14909 for ; Tue, 17 Feb 2004 11:37:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8Dj-0001Oc-Oz for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 11:37:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HGbFnt005357 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 11:37:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8Dj-0001OK-FU for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 11:37:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14858 for ; Tue, 17 Feb 2004 11:37:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At8Di-00036d-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:37:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At8Cr-00032R-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:36:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At8C3-0002yN-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 11:35:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8Bb-0000xb-9T; Tue, 17 Feb 2004 11:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8Ai-0000w4-UD for sipping@optimus.ietf.org; Tue, 17 Feb 2004 11:34:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14638 for ; Tue, 17 Feb 2004 11:34:06 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At8Ah-0002pv-00 for sipping@ietf.org; Tue, 17 Feb 2004 11:34:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At89l-0002kh-00 for sipping@ietf.org; Tue, 17 Feb 2004 11:33:10 -0500 Received: from imo-r07.mx.aol.com ([152.163.225.103]) by ietf-mx with esmtp (Exim 4.12) id 1At88s-0002cf-00 for sipping@ietf.org; Tue, 17 Feb 2004 11:32:14 -0500 Received: from Mpierce1@aol.com by imo-r07.mx.aol.com (mail_out_v36_r4.14.) id 7.122.2b7916de (25711); Tue, 17 Feb 2004 11:31:13 -0500 (EST) Message-ID: <122.2b7916de.2d639bd1@aol.com> Date: Tue, 17 Feb 2004 11:31:13 EST Subject: Re: [Sipping] SIP support for hold and ringback for operator / 911 services To: hgs@cs.columbia.edu, jdrosen@dynamicsoft.com CC: mli@nortelnetworks.com, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_122.2b7916de.2d639bd1_boundary" X-Mailer: 6.0 for Windows XP sub 51 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 --part1_122.2b7916de.2d639bd1_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/16/2004 10:42:05 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > I agree with Jonathan that end system intelligence is the answer here. > After all, end systems have an interest in making emergency services work. > > > The problem with the approach of having the callee identify itself as a > emergency call center and thereby modify caller behavior is that lends > itself to pranks. Call my number and you can't hang up the phone until I > let you. Telemarketers will love that feature :-) > > (If the calling UA knows it's an emergency call, there is no need for > the feature tag indication to control services.) > I agree, if one is only considering the requirement for calls to an emergency center. It would be better if the operation (holding of the call until the callee says to release it) occurs without instructions coming back from the callee. In the case of the call to an energency center, I believe the desire is that this same operation will occur if someone calls 911 and hangs up before the call even gets to the emergency center. In today's network, the originating side equipment (central office) can know to do this when someone dials an emergency number. For the SIP case, if the originating device can do this (recognize the emergency number) or an outbound proxy does it, fine. But, looking at another part of the issue: When the emergency center gets a call, it should be able to assume that the operation will comply with this requirement and it has control of releasing the call. Of course, the problem with SIP (as with any evolving protocol) is that older devices would not support this capability, so I suppose we need to add a function so the originating device can tell the emergency center that it can do with (called party control of release). Perhaps the existance of the SOS URI could imply this. Another part of the issue regards the "ringback" function, which allows the emergency center to re-ring the phone of someone who has gone "on-hook" (or whatever similar function is used on the SIP phone to indicate end-of-call). One of the earlier e-mails suggested that, if the phone recognized 911, it could immediately re-ring the phone if the person "hangs-up". I don't believe this meets the requirement. The re-ring needs to be under the control of the emergency center, so they can decide whether a re-ring is necessary or not. Also, someone needs to look into the possible requirement to allow the emergency center to alert the user even while they are "off-hook" while the connection is being held. The American National Standard (for ISDN) included this function. Also, note that the subject of these e-mails includes mention of "operator". The function of hold/ringback may not just be limited to calls to emergency. There is another use of the holding function in today's network: tracing of malicious calls. In this case, the request to hold the call must come from the called end (but not the called party). I guess one of the things about SIP and the environment it is used in is that it should not be neccessary to hold a "connection" in order to provide malicious call trace. However, we need to consider what happens for various packet/Circuit switched interworking cases. What this points out is the need to agree on the functional requirements for Support for Hold and Ringback before doing detailed protocol work. Mike Pierce Artel --part1_122.2b7916de.2d639bd1_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/16/2004 10:42:05 PM Eastern Standard Time, hgs@cs.columbia.edu write= s:


I agree with Jonathan that=20= end system intelligence is the answer here.=20
After all, end systems have an interest in making emergency services wor= k.

<snip>
The problem with the approach of having the callee identify itself as a=20
emergency call center and thereby modify caller behavior is that lends=20
itself to pranks. Call my number and you can't hang up the phone until I= =20
let you. Telemarketers will love that feature :-)

(If the calling UA knows it's an emergency call, there is no need for=20
the feature tag indication to control services.)



I agree, if one is only considering the requirement for calls to an emer= gency center. It would be better if the operation (holding of the call until= the callee says to release it) occurs without instructions coming back from= the callee. In the case of the call to an energency center, I believe the d= esire is that this same operation will occur if someone calls 911 and hangs=20= up before the call even gets to the emergency center. In today's network, th= e originating side equipment (central office) can know to do this when someo= ne dials an emergency number. For the SIP case, if the originating device ca= n do this (recognize the emergency number) or an outbound proxy does it, fin= e.

But, looking at another part of the issue: When the emergency center get= s a call, it should be able to assume that the operation will comply with th= is requirement and it has control of releasing the call. Of course, the prob= lem with SIP (as with any evolving protocol) is that older devices would not= support this capability, so I suppose we need to add a function so the orig= inating device can tell the emergency center that it can do with (called par= ty control of release). Perhaps the existance of the SOS URI could imply thi= s.

Another part of the issue regards the "ringback" function, which allows=20= the emergency center to re-ring the phone of someone who has gone "on-hook"=20= (or whatever similar function is used on the SIP phone to indicate end-of-ca= ll). One of the earlier e-mails suggested that, if the phone recognized 911,= it could immediately re-ring the phone if the person "hangs-up". I don't be= lieve this meets the requirement. The re-ring needs to be under the control=20= of the emergency center, so they can decide whether a re-ring is necessary o= r not.

Also, someone needs to look into the possible requirement to allow the e= mergency center to alert the user even while they are "off-hook" while the c= onnection is being held. The American National Standard (for ISDN) included=20= this function.

Also, note that the subject of these e-mails includes mention of "operat= or". The function of hold/ringback may not just be limited to calls to emerg= ency.

There is another use of the holding function in today's network: tracing= of malicious calls. In this case, the request to hold the call must come fr= om the called end (but not the called party). I guess one of the things abou= t SIP and the environment it is used in is that it should not be neccessary=20= to hold a "connection" in order to provide malicious call trace. However, we= need to consider what happens for various packet/Circuit switched interwork= ing cases.

What this points out is the need to agree on the functional requirements= for Support for Hold and Ringback before doing detailed protocol work.

Mike Pierce
Artel

--part1_122.2b7916de.2d639bd1_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 14:19:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28078 for ; Tue, 17 Feb 2004 14:19:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAkg-0002sN-4r for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 14:19:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HJJQsO011050 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 14:19:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAkf-0002s9-Vq for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 14:19:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28072 for ; Tue, 17 Feb 2004 14:19:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtAkd-0004IC-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 14:19:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAjk-0004EH-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 14:18:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtAjM-00049v-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 14:18:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAjI-0002Y9-Pu; Tue, 17 Feb 2004 14:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAiY-0002WL-OE for sipping@optimus.ietf.org; Tue, 17 Feb 2004 14:17:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27928 for ; Tue, 17 Feb 2004 14:17:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtAiW-00046r-00 for sipping@ietf.org; Tue, 17 Feb 2004 14:17:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAhX-00042s-00 for sipping@ietf.org; Tue, 17 Feb 2004 14:16:12 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AtAgZ-0003xq-00 for sipping@ietf.org; Tue, 17 Feb 2004 14:15:11 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1HJEw5d028124; Tue, 17 Feb 2004 14:14:58 -0500 (EST) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1HJEwH28509; Tue, 17 Feb 2004 14:14:58 -0500 Message-ID: <40326832.5050001@cs.columbia.edu> Date: Tue, 17 Feb 2004 14:14:58 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Janet P Gunn CC: Cullen Jennings , sipping@ietf.org Subject: Re: [Sipping] Re: sos - dead or alive References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The OPTIONS mechanism does exactly that - it's mechanical only. Janet P Gunn wrote: > Bear in mind that the "most scarce resource" in the emergency response > system is usually the human operators. > > So any kind of regular, scheduled test should be designed so it does NOT > tie up the operators. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 15:04:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00557 for ; Tue, 17 Feb 2004 15:04:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBRZ-0003At-CQ for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:03:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HK3j3n012166 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:03:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBRY-00039v-VP for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 15:03:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00524 for ; Tue, 17 Feb 2004 15:03:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBRV-0007U0-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:03:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBQa-0007OV-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:02:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtBPx-0007IZ-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBPt-0001A1-Jm; Tue, 17 Feb 2004 15:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBPO-0000hJ-Vn for sipping@optimus.ietf.org; Tue, 17 Feb 2004 15:01:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00405 for ; Tue, 17 Feb 2004 15:01:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBPM-0007GG-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:01:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBOT-0007AV-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:00:34 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AtBNX-0006zq-00 for sipping@ietf.org; Tue, 17 Feb 2004 14:59:35 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCN5RF>; Tue, 17 Feb 2004 14:59:04 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63F5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , Henning Schulzrinne Cc: Xuewen Li , sipping@ietf.org Subject: RE: [Sipping] SIP support for hold and ringback for operator / 91 1 services Date: Tue, 17 Feb 2004 14:59:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > In principal, I would think that someone (NENA??) could hand > out certs > that do, in fact, certify that a user is an operator in an emergency > service center. If a call I make completes to an user that has a cert > declaring them as an emergency operation, my UA wouldn't allow me to > terminate the call. > I looked into this when the privacy folks wanted to make sure that emergency calls in fact reached an emergency service provider. I was told this would take a treaty. Basically, the nations won't recognize any specific agency as the root CA. I keep hoping we can get ITU to do it as part of the delegation of sos.arpa. I really do want a cryptographic way to authenticate stuff in my sos.arpa DNS tree, and I really do want to authenticate a PSAP. It guaranteed to be a problem if any organization that looks vaguely US in origin was doing it. NENA could be the CA for the U.S. of course, but to work really well, you want its key to be signed by the international CA. Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 15:12:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01643 for ; Tue, 17 Feb 2004 15:12:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBZz-0007q2-Vm for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:12:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HKCRq6030127 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:12:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBZz-0007pq-SF for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 15:12:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01616 for ; Tue, 17 Feb 2004 15:12:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBZy-0000Qr-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:12:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBYw-0000N7-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:11:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtBYc-0000Jv-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:11:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBYc-0007Li-Gv; Tue, 17 Feb 2004 15:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBY2-0007Dl-He for sipping@optimus.ietf.org; Tue, 17 Feb 2004 15:10:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01395 for ; Tue, 17 Feb 2004 15:10:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBXz-0000JO-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:10:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBX7-0000GD-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:09:30 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AtBWp-0000Bp-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:09:11 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCN57L>; Tue, 17 Feb 2004 15:08:41 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63F6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Cullen Jennings'" , "'sipping@ietf.org'" Date: Tue, 17 Feb 2004 15:08:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] RE: comments on rosen-dns-sos Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Thanks for the comments. I'll include most of them as you suggest. The proposal copies the "datum" code from the DHCP draft. I'd welcome any suggestions for what to advise clients to do when two entries use different datums and they are trying to determine inclusion. I wondered if just saying "its WGS84, convert on entry" isn't the right way, but so many other folks have flamed out trying to fix the datum that I gave up on it. The Floor problem is solved I think. The DNS entry would have a floor as one of the levels, which would presumably have the correct geos with altitude in meters. There is also the floor count format of the data, also copied from the DHCP draft. Agree I need text on how to describe the polygons for floors. Brian > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, February 17, 2004 10:57 AM > To: Brian Rosen; 'sipping@ietf.org' > Subject: comments on rosen-dns-sos > > > > One small nit on polygons. Need to specify that the vertexes are in > clockwise order. Failing to do this caused endless arguments > in air traffic > control specifications of airspaces. Probably needs a way to > deal with what > geographic coordinate grid is being used or fix it. Should > warn implementers > that polygon will include the poles and the vertex may even > be a pole. Polar > flights have caused more than one geographic information > system to crash. > Many systems translate the 3 tupple coordinates into 4 tupple > coordinates > for all calculations to avoid the singularities that a > spherical coordinate > system introduces. Probably need a header format that allows > an arbitrary > number of vertexes - the top level polygons are going to be > big. I don't > like the implied additive subtractive form of the poly. I > would prefer poly > explicitly identify as additive or subtractive with the > region covered being > formed by taking the union of all the additive then > subtracting each of the > subtractive polygons. Points on a vertex or edge would be > considered in the > region for additive polygons and out for subtractive > polygons. None of the > polygons forming a region are allowed to share an edge. The > altitudes need > to be altitude ranges to specify a volume that can be > clipped. Seems like > you need this to figure out which floor in a building I am > on. Recommend > that min alt is include in the volume but max alt is outside > the volume. The > specification of points on the surface of the volume being in > or out is > important or users can, excuse the pun, fall thought the cracks. > > I was not sold on DNS to start with but your arguments about > the pleasures > of forming a new global root convinced me DNS is right if it > will work. More > text explaining it would work would make me feel warm and fluffy. > > Cullen > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 15:16:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02058 for ; Tue, 17 Feb 2004 15:16:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBd7-0000Xa-0T for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:15:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HKFeOF002071 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:15:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBd6-0000XH-TG for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 15:15:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02005 for ; Tue, 17 Feb 2004 15:15:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBd5-0000hT-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:15:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBc6-0000cg-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:14:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtBbW-0000X5-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBbW-0008Oh-2l; Tue, 17 Feb 2004 15:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBb0-0008H3-4V for sipping@optimus.ietf.org; Tue, 17 Feb 2004 15:13:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01755 for ; Tue, 17 Feb 2004 15:13:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBay-0000Vz-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:13:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBa8-0000SL-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:12:37 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AtBZh-0000NL-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:12:09 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCN6AH>; Tue, 17 Feb 2004 15:11:39 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63F7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Cullen Jennings'" , Henning Schulzrinne , sipping@ietf.org Subject: RE: [Sipping] sos - dead or alive Date: Tue, 17 Feb 2004 15:11:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Probably need a separate URI for this; don't want to have even a possibility for overwhelming the real proxy server. It would be easy for the test one to heartbeat the real one to keep them in sync. We could define a more precise algorithm based on lsbs of IP address to randomize test times. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, February 17, 2004 10:58 AM > To: Henning Schulzrinne; sipping@ietf.org > Subject: [Sipping] sos - dead or alive > > > > I think that a phone informing a user that SOS was broken is > very important > for this to work when it is needed. I would like to see a bit > more text > around the current text of: > > It is RECOMMENDED that user agents > periodically automatically check for the availability of the "sos" > identifier and alert the user if the check fails. The > period of such > automated checks SHOULDNOT be less than once per day and MUST be > randomly placed over the testing interval. > > Some random not well thought out ideas off the top of my head... > > I would prefer MUST to RECOMMENDED since a recent informal > poll at sipit > made it quiet clear that most implementers view SHOULD level > requirements as > something to consider in the next lifetime. I'm not arguing > that this poll > means we should not use SHOULD in general, but I think due to > the critical > nature of this specification, we should be a little stronger > than normal. I > don't want vendors saying they support this RFC fully when > they can't detect > that a safety critical system is broken. > > I would prefer specific test times - something like the test should be > performed at a random time between 12 and 36 hours. Phones > must prominently > display the information that 911 is broken using a display or > by changing > the dial tone on all calls. Would be nice to consider the > impact of every > phone doing this. Phones SHOULD not do a test immediately > after booting. > Phones MAY provide a UI to allow a user to manual imitate a > test - this is > very useful for someone that is trying to check a 911 system > but does not > want to wait 36 hours. > > Cullen > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 15:30:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02937 for ; Tue, 17 Feb 2004 15:30:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBqb-0003Yp-5c for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:29:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HKTb7c013682 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:29:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBqb-0003Yb-2T for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 15:29:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02924 for ; Tue, 17 Feb 2004 15:29:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBqZ-0001pl-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:29:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBpj-0001kR-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:28:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtBp6-0001f8-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:28:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBp3-0003Lf-ER; Tue, 17 Feb 2004 15:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBoR-0003It-0O for sipping@optimus.ietf.org; Tue, 17 Feb 2004 15:27:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02810 for ; Tue, 17 Feb 2004 15:27:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBoP-0001aq-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:27:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBnU-0001Vb-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:26:25 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AtBmd-0001Ln-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:25:32 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 17 Feb 2004 12:25:34 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1HKOxuA020659 for ; Tue, 17 Feb 2004 12:25:00 -0800 (PST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGC69151; Tue, 17 Feb 2004 15:24:59 -0500 (EST) Message-ID: <4032789A.2070607@cisco.com> Date: Tue, 17 Feb 2004 15:24:58 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org References: <200402171537.KAA05867@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: draft-ietf-sipping-cc-transfer-02 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sections 6.2 and 6.3 have been changed, adding "Supported: gruu". But if these examples are gruus, they at presumably aren't ones that have been dynamically constructed by the registrar, which would presumably use some other form of contact. This seems to raise the expectation that a UA just knows if its natural contact address is globally routable and uses it as a gruu. Is that what we want to show in an example? Paul Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. > > Title : Session Initiation Protocol Call Control - Transfer > Author(s) : R. Sparks, A. Johnston > Filename : draft-ietf-sipping-cc-transfer-02.txt > Pages : 37 > Date : 2004-2-17 > > This document describes providing Call Transfer capabilities in the > Session Initiation Protocol (SIP). This work is part of the SIP > Multiparty Call Control Framework. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-02.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sipping-cc-transfer-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sipping-cc-transfer-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 15:34:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03249 for ; Tue, 17 Feb 2004 15:34:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBvK-00041Z-Dg for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:34:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HKYUTw015463 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:34:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBvK-00041K-7F for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 15:34:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03200 for ; Tue, 17 Feb 2004 15:34:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBvI-0002D6-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:34:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBuI-00028R-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:33:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtBtt-00024Z-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBtt-0003nY-AT; Tue, 17 Feb 2004 15:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBtC-0003lc-9h for sipping@optimus.ietf.org; Tue, 17 Feb 2004 15:32:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03104 for ; Tue, 17 Feb 2004 15:32:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBtA-00022o-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:32:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBsG-0001zR-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:31:21 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AtBrP-0001tW-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:30:27 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1HKRb5d020929; Tue, 17 Feb 2004 15:27:37 -0500 (EST) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1HKRWH02251; Tue, 17 Feb 2004 15:27:32 -0500 Message-ID: <40327934.7080303@cs.columbia.edu> Date: Tue, 17 Feb 2004 15:27:32 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Cullen Jennings'" , sipping@ietf.org Subject: Re: [Sipping] sos - dead or alive References: <313680C9A886D511A06000204840E1CF070B63F7@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B63F7@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > Probably need a separate URI for this; don't want to have even a > possibility for overwhelming the real proxy server. It would be easy > for the test one to heartbeat the real one to keep them in sync. While you can obviously do method-based routing, I would worry about building any such knowledge into the UA. After all, you want to test as much of the whole chain as you can. To improve scaling, an outbound proxy could answer all such OPTIONS requests to keep testing load local, depending on our perception of where the likely failures are. (The emergency-call-aware outbound proxy could then in turn exercise the path from itself to the ECCs of interest, but you'd then have one per company or provider, instead of 10,000 tests per campus.) > > We could define a more precise algorithm based on lsbs of IP address to > randomize test times. I don't think that helps much beyond simple randomization. We have reasonably good experience with randomization in RTCP after all. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 15:42:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04049 for ; Tue, 17 Feb 2004 15:42:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtC2A-0004zF-RD for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:41:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HKfYgG019163 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:41:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtC2A-0004z0-Nt for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 15:41:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03971 for ; Tue, 17 Feb 2004 15:41:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtC28-0003AK-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:41:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtC1I-000369-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:40:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtC0m-00030Y-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:40:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtC0j-0004iQ-CR; Tue, 17 Feb 2004 15:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtC04-0004fc-15 for sipping@optimus.ietf.org; Tue, 17 Feb 2004 15:39:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03802 for ; Tue, 17 Feb 2004 15:39:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtC02-0002x7-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:39:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBzP-0002sE-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:38:43 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AtByn-0002gT-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:38:05 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCN7AZ>; Tue, 17 Feb 2004 15:37:36 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63FA@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" Cc: "'Cullen Jennings'" , sipping@ietf.org Subject: RE: [Sipping] sos - dead or alive Date: Tue, 17 Feb 2004 15:37:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 If the SIP URI for a PSAP was sip:anyone@emergency.chicago.il.us, and the test URI was sip:test@test.chicago.il.us, I don't think we have any routing problems. The router for chicago.il.us would get exercised for test code, but not the proxy. I like the scaling idea. RTCP has never been tested with a billion phones randomly trying anything. I think we need to be careful. Very careful. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, February 17, 2004 3:28 PM > To: Rosen, Brian > Cc: 'Cullen Jennings'; sipping@ietf.org > Subject: Re: [Sipping] sos - dead or alive > > > > > Rosen, Brian wrote: > > > Probably need a separate URI for this; don't want to have even a > > possibility for overwhelming the real proxy server. It > would be easy > > for the test one to heartbeat the real one to keep them in sync. > > While you can obviously do method-based routing, I would worry about > building any such knowledge into the UA. After all, you want > to test as > much of the whole chain as you can. > > To improve scaling, an outbound proxy could answer all such OPTIONS > requests to keep testing load local, depending on our perception of > where the likely failures are. (The emergency-call-aware > outbound proxy > could then in turn exercise the path from itself to the ECCs of > interest, but you'd then have one per company or provider, instead of > 10,000 tests per campus.) > > > > > We could define a more precise algorithm based on lsbs of > IP address to > > randomize test times. > > I don't think that helps much beyond simple randomization. We have > reasonably good experience with randomization in RTCP after all. > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 15:45:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04263 for ; Tue, 17 Feb 2004 15:45:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtC5u-0005H4-5r for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:45:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HKjQ9E020268 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:45:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtC5u-0005Gp-23 for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 15:45:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04251 for ; Tue, 17 Feb 2004 15:45:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtC5s-0003Rk-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:45:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtC4u-0003OQ-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:44:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtC4a-0003LP-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtC4X-00054z-8H; Tue, 17 Feb 2004 15:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtC3s-00053D-Mk for sipping@optimus.ietf.org; Tue, 17 Feb 2004 15:43:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04151 for ; Tue, 17 Feb 2004 15:43:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtC3r-0003JM-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:43:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtC31-0003F2-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:42:28 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtC2M-00038C-00; Tue, 17 Feb 2004 15:41:47 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1HKfE4U012681; Tue, 17 Feb 2004 12:41:14 -0800 (PST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGC70734; Tue, 17 Feb 2004 15:41:13 -0500 (EST) Message-ID: <40327C69.3010305@cisco.com> Date: Tue, 17 Feb 2004 15:41:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Internet-Drafts@ietf.org CC: IETF-Announce:, ";"@cisco.com, sipping@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-service-examples-06.txt References: <200402171537.KAA05881@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As with the transfer examples, the changes here give the impression that things will be wonderful if you add "Supported: gruu" and continue to use your old contact address. If examples are to be given that depend upon gruus, then I think we need to show that the gruu is something special - not the same as the UA's normal contact address. Paul Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. > > Title : Session Initiation Protocol Service Examples > Author(s) : A. Johnston, R. Sparks > Filename : draft-ietf-sipping-service-examples-06.txt > Pages : 169 > Date : 2004-2-17 > > This document gives examples of Session Initiation Protocol (SIP) > services. This covers most features offered in so-called IP Centrex > offerings from local exchange carriers and PBX (Private Branch > Exchange) features. Most of the services shown in this document are > implemented in the SIP User Agents, although some require the > assistance of a SIP Proxy. Some require some extensions to SIP > including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces > and Join headers. These features are not intended to be an exhaustive > set, but rather show implementations of common features likely to be > implemented on SIP IP telephones in a business environment. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-06.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sipping-service-examples-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sipping-service-examples-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 15:49:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04531 for ; Tue, 17 Feb 2004 15:49:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtC9h-0005jI-18 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:49:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HKnKx0022018 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:49:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtC9g-0005j3-Tx for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 15:49:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04520 for ; Tue, 17 Feb 2004 15:49:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtC9f-0003hn-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:49:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtC8i-0003em-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:48:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtC8P-0003cH-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtC8Q-0005LB-5S; Tue, 17 Feb 2004 15:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtC7v-0005KS-33 for sipping@optimus.ietf.org; Tue, 17 Feb 2004 15:47:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04474 for ; Tue, 17 Feb 2004 15:47:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtC7t-0003cA-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:47:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtC75-0003YY-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:46:40 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AtC6c-0003Tg-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:46:10 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1HKjR5d024219; Tue, 17 Feb 2004 15:45:27 -0500 (EST) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1HKjQH04126; Tue, 17 Feb 2004 15:45:26 -0500 Message-ID: <40327D66.5080600@cs.columbia.edu> Date: Tue, 17 Feb 2004 15:45:26 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Cullen Jennings'" , sipping@ietf.org Subject: Re: [Sipping] sos - dead or alive References: <313680C9A886D511A06000204840E1CF070B63FA@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B63FA@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Unless this is identified in the mapping algorithm (location -> ECC), I don't see how a device can find the test destination. Rosen, Brian wrote: > If the SIP URI for a PSAP was sip:anyone@emergency.chicago.il.us, and the > test > URI was sip:test@test.chicago.il.us, I don't think we have any routing > problems. The router for chicago.il.us would get exercised for test code, > but not the proxy. > > I like the scaling idea. > > RTCP has never been tested with a billion phones randomly trying anything. > I think we need to be careful. Very careful. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 15:55:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04738 for ; Tue, 17 Feb 2004 15:55:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCEk-0006Lp-UJ for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:54:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HKsYm5024407 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 15:54:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCEk-0006La-R2 for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 15:54:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04725 for ; Tue, 17 Feb 2004 15:54:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtCEi-00042V-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:54:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtCDd-0003yR-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:53:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtCDG-0003uv-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 15:53:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCDF-00068w-CF; Tue, 17 Feb 2004 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCCY-00060z-2V for sipping@optimus.ietf.org; Tue, 17 Feb 2004 15:52:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04644 for ; Tue, 17 Feb 2004 15:52:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtCCW-0003tB-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:52:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtCBb-0003qP-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:51:19 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AtCAo-0003k0-00 for sipping@ietf.org; Tue, 17 Feb 2004 15:50:30 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCN7P4>; Tue, 17 Feb 2004 15:50:01 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63FB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" Cc: "'Cullen Jennings'" , sipping@ietf.org Subject: RE: [Sipping] sos - dead or alive Date: Tue, 17 Feb 2004 15:49:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 You put another NAPTR in the ECC entry in the DNS :) Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, February 17, 2004 3:45 PM > To: Rosen, Brian > Cc: 'Cullen Jennings'; sipping@ietf.org > Subject: Re: [Sipping] sos - dead or alive > > > Unless this is identified in the mapping algorithm (location > -> ECC), I > don't see how a device can find the test destination. > > Rosen, Brian wrote: > > > If the SIP URI for a PSAP was > sip:anyone@emergency.chicago.il.us, and the > > test > > URI was sip:test@test.chicago.il.us, I don't think we have > any routing > > problems. The router for chicago.il.us would get exercised > for test code, > > but not the proxy. > > > > I like the scaling idea. > > > > RTCP has never been tested with a billion phones randomly > trying anything. > > I think we need to be careful. Very careful. > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 16:41:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07904 for ; Tue, 17 Feb 2004 16:41:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCy8-0002i8-H0 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 16:41:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HLfSLe010416 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 16:41:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCy8-0002hv-BQ for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 16:41:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07901 for ; Tue, 17 Feb 2004 16:41:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtCy6-0000JL-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 16:41:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtCxA-0000Fu-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 16:40:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtCws-0000CJ-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 16:40:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCwn-0002TH-CO; Tue, 17 Feb 2004 16:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCw9-0002Ra-Jl for sipping@optimus.ietf.org; Tue, 17 Feb 2004 16:39:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07727; Tue, 17 Feb 2004 16:39:22 -0500 (EST) Message-Id: <200402172139.QAA07727@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 17 Feb 2004 16:39:22 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-cc-conferencing-03.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Session Initiation Protocol Call Control - Conferencing for User Agents Author(s) : A. Johnston, O. Levin Filename : draft-ietf-sipping-cc-conferencing-03.txt Pages : 34 Date : 2004-2-17 This document defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from different user agent (UA) types perspective: conference-unaware, conference-aware and focus UAs. The use of URIs in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conferencing-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-cc-conferencing-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-cc-conferencing-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-17165951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-cc-conferencing-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-cc-conferencing-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-17165951.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 17:24:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12488 for ; Tue, 17 Feb 2004 17:24:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDcu-0006ox-Tu for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 17:23:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HMNa9F026215 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 17:23:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDcu-0006ok-PN for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 17:23:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12451 for ; Tue, 17 Feb 2004 17:23:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDcs-0005op-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 17:23:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDc0-0005kL-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 17:22:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtDbU-0005fI-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 17:22:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDbM-0006U2-PY; Tue, 17 Feb 2004 17:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDan-0006Qa-Dw for sipping@optimus.ietf.org; Tue, 17 Feb 2004 17:21:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12286 for ; Tue, 17 Feb 2004 17:21:21 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDal-0005cN-00 for sipping@ietf.org; Tue, 17 Feb 2004 17:21:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDZr-0005Ya-00 for sipping@ietf.org; Tue, 17 Feb 2004 17:20:27 -0500 Received: from imo-m28.mx.aol.com ([64.12.137.9]) by ietf-mx with esmtp (Exim 4.12) id 1AtDZ4-0005Pe-00 for sipping@ietf.org; Tue, 17 Feb 2004 17:19:39 -0500 Received: from Mpierce1@aol.com by imo-m28.mx.aol.com (mail_out_v36_r4.14.) id e.1db.1a3a9a99 (17526); Tue, 17 Feb 2004 17:18:45 -0500 (EST) Message-ID: <1db.1a3a9a99.2d63ed45@aol.com> Date: Tue, 17 Feb 2004 17:18:45 EST Subject: Re: [Sipping] SIP support for hold and ringback for operator / 91 1 services To: Brian.Rosen@marconi.com, jdrosen@dynamicsoft.com, hgs@cs.columbia.edu CC: mli@nortelnetworks.com, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1db.1a3a9a99.2d63ed45_boundary" X-Mailer: 6.0 for Windows XP sub 51 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 --part1_1db.1a3a9a99.2d63ed45_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/17/2004 3:02:49 PM Eastern Standard Time, Brian.Rosen@marconi.com writes: > Basically, the nations won't recognize any specific agency as the > root CA. I keep hoping we can get ITU to do it as part of the > delegation of sos.arpa. I really do want a cryptographic way to > authenticate stuff in my sos.arpa DNS tree, and I really do want to > authenticate a PSAP. > > It guaranteed to be a problem if any organization that looks vaguely > US in origin was doing it. NENA could be the CA for the U.S. of course, > but to work really well, you want its key to be signed by the international > CA. > Well, the answer to all this is quite simple - just recognize that emergency calling, connection holding, ringback, etc. are national matters and do not have to cross boundaries (except maybe where adjacent countries set up specific agreements, including CAs if necessary). Anything more than that seems to be beyond our ability to deal with. Mike Pierce --part1_1db.1a3a9a99.2d63ed45_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/17/2004 3:02:49 PM Eastern Standard Time, Brian.Rosen@marconi.com wr= ites:


Basically, the nations won'= t recognize any specific agency as the
root CA.  I keep hoping we can get ITU to do it as part of the
delegation of sos.arpa.  I really do want a cryptographic way to
authenticate stuff in my sos.arpa DNS tree, and I really do want to
authenticate a PSAP.

It guaranteed to be a problem if any organization that looks vaguely
US in origin was doing it.  NENA could be the CA for the U.S. of co= urse,
but to work really well, you want its key to be signed by the internatio= nal
CA.



Well, the answer to all this is quite simple - just recognize that emerg= ency calling, connection holding, ringback, etc. are national matters and do= not have to cross boundaries (except maybe where adjacent countries set up=20= specific agreements, including CAs if necessary). Anything more than that se= ems to be beyond our ability to deal with.

Mike Pierce
--part1_1db.1a3a9a99.2d63ed45_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 17:47:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13579 for ; Tue, 17 Feb 2004 17:47:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDzw-0000ZH-NP for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 17:47:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HMlO9l002177 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 17:47:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDzw-0000Z2-Fn for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 17:47:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13571 for ; Tue, 17 Feb 2004 17:47:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDzt-0007Yq-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 17:47:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDyw-0007WE-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 17:46:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtDyf-0007U7-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 17:46:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDyc-0000Od-Kn; Tue, 17 Feb 2004 17:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDy0-0000O5-Sx for sipping@optimus.ietf.org; Tue, 17 Feb 2004 17:45:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13534 for ; Tue, 17 Feb 2004 17:45:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDxy-0007Td-00 for sipping@ietf.org; Tue, 17 Feb 2004 17:45:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDx7-0007R7-00 for sipping@ietf.org; Tue, 17 Feb 2004 17:44:30 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AtDwS-0007LD-00 for sipping@ietf.org; Tue, 17 Feb 2004 17:43:48 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSC3AD3>; Tue, 17 Feb 2004 17:43:19 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6402@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Mpierce1@aol.com'" , jdrosen@dynamicsoft.com, hgs@cs.columbia.edu Cc: mli@nortelnetworks.com, sipping@ietf.org Subject: RE: [Sipping] SIP support for hold and ringback for operator / 91 1 services Date: Tue, 17 Feb 2004 17:43:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 We don't do national variants in the IETF. It does matter. If you can spoof, you can create your own imitation sos.arpa tree, with your own us.sos.arpa, with your own public key. No one will be the wiser. We can broadly disseminate the us.sos.arpa public key within the U.S., but in general, it's not possible to securely disseminate every nation's sos.arpa public key. Having a root CA to certify them would make a basically insecure system a secure system. Brian -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Tuesday, February 17, 2004 5:19 PM To: Brian.Rosen@marconi.com; jdrosen@dynamicsoft.com; hgs@cs.columbia.edu Cc: mli@nortelnetworks.com; sipping@ietf.org Subject: Re: [Sipping] SIP support for hold and ringback for operator / 91 1 services In a message dated 2/17/2004 3:02:49 PM Eastern Standard Time, Brian.Rosen@marconi.com writes: Basically, the nations won't recognize any specific agency as the root CA. I keep hoping we can get ITU to do it as part of the delegation of sos.arpa. I really do want a cryptographic way to authenticate stuff in my sos.arpa DNS tree, and I really do want to authenticate a PSAP. It guaranteed to be a problem if any organization that looks vaguely US in origin was doing it. NENA could be the CA for the U.S. of course, but to work really well, you want its key to be signed by the international CA. Well, the answer to all this is quite simple - just recognize that emergency calling, connection holding, ringback, etc. are national matters and do not have to cross boundaries (except maybe where adjacent countries set up specific agreements, including CAs if necessary). Anything more than that seems to be beyond our ability to deal with. Mike Pierce _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 18:05:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14359 for ; Tue, 17 Feb 2004 18:05:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEHO-00049r-96 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 18:05:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HN5QwI015977 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 18:05:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEHO-00049c-3a for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 18:05:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14313 for ; Tue, 17 Feb 2004 18:05:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtEHL-0000pa-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 18:05:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtEGT-0000n8-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 18:04:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtEG3-0000jv-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 18:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEG1-0003ft-Sf; Tue, 17 Feb 2004 18:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEFO-0003Vx-S7 for sipping@optimus.ietf.org; Tue, 17 Feb 2004 18:03:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14065 for ; Tue, 17 Feb 2004 18:03:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtEFM-0000hL-00 for sipping@ietf.org; Tue, 17 Feb 2004 18:03:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtEEP-0000eS-00 for sipping@ietf.org; Tue, 17 Feb 2004 18:02:22 -0500 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx with esmtp (Exim 4.12) id 1AtEDf-0000Yw-00 for sipping@ietf.org; Tue, 17 Feb 2004 18:01:35 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HT900F6Z3NH8R@firewall.mci.com> for sipping@ietf.org; Tue, 17 Feb 2004 22:54:53 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HT900E013NHLT@pmismtp02.mcilink.com>; Tue, 17 Feb 2004 22:54:53 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.135.150]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HT900DK03NFLH@pmismtp02.mcilink.com>; Tue, 17 Feb 2004 22:54:53 +0000 (GMT) Date: Tue, 17 Feb 2004 16:54:25 -0600 From: Alan Johnston Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-service-examples-06.txt In-reply-to: <40327C69.3010305@cisco.com> X-Sender: Alan.Johnston@pop.mcit.com To: Paul Kyzivat Cc: sipping@ietf.org Message-id: <5.2.1.1.0.20040217165050.01579530@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <200402171537.KAA05881@ietf.org> Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 At 03:41 PM 2/17/2004 -0500, Paul Kyzivat wrote: >As with the transfer examples, the changes here give the impression that >things will be wonderful if you add "Supported: gruu" and continue to use >your old contact address. > >If examples are to be given that depend upon gruus, then I think we need >to show that the gruu is something special - not the same as the UA's >normal contact address. Paul, What do you have in mind? A GRUU is identical to any other URI - it just meets the requirements in the draft. A GRUU doesn't need to look different from any other URI - in fact, no one can tell by inspection if a URI is a GRUU. Do you just want the example GRUUs to *look* different?? Thanks, Alan Johnston MCI sip:alan@sipstation.com > Paul > >Internet-Drafts@ietf.org wrote: >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >>This draft is a work item of the Session Initiation Proposal >>Investigation Working Group of the IETF. >> Title : Session Initiation Protocol Service Examples >> Author(s) : A. Johnston, R. Sparks >> Filename : draft-ietf-sipping-service-examples-06.txt >> Pages : 169 >> Date : 2004-2-17 >> >>This document gives examples of Session Initiation Protocol (SIP) >>services. This covers most features offered in so-called IP Centrex >>offerings from local exchange carriers and PBX (Private Branch >>Exchange) features. Most of the services shown in this document are >>implemented in the SIP User Agents, although some require the >>assistance of a SIP Proxy. Some require some extensions to SIP >>including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces >>and Join headers. These features are not intended to be an exhaustive >>set, but rather show implementations of common features likely to be >>implemented on SIP IP telephones in a business environment. >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-06.txt >>To remove yourself from the IETF Announcement list, send a message to >>ietf-announce-request with the word unsubscribe in the body of the message. >>Internet-Drafts are also available by anonymous FTP. Login with the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-ietf-sipping-service-examples-06.txt". >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >>Internet-Drafts can also be obtained by e-mail. >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-ietf-sipping-service-examples-06.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 18:26:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16418 for ; Tue, 17 Feb 2004 18:26:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEbo-0002DP-Jg for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 18:26:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HNQWrT008509 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 18:26:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEbo-0002DA-Fy for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 18:26:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16401 for ; Tue, 17 Feb 2004 18:26:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtEbl-0002HC-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 18:26:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtEat-0002DY-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 18:25:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtEaN-00029X-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 18:25:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEaM-00020l-7z; Tue, 17 Feb 2004 18:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEZj-0001zH-Ji for sipping@optimus.ietf.org; Tue, 17 Feb 2004 18:24:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16290 for ; Tue, 17 Feb 2004 18:24:19 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtEZg-00027X-00 for sipping@ietf.org; Tue, 17 Feb 2004 18:24:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtEYn-00024u-00 for sipping@ietf.org; Tue, 17 Feb 2004 18:23:26 -0500 Received: from imo-d04.mx.aol.com ([205.188.157.36]) by ietf-mx with esmtp (Exim 4.12) id 1AtEXx-0001z7-00 for sipping@ietf.org; Tue, 17 Feb 2004 18:22:33 -0500 Received: from Mpierce1@aol.com by imo-d04.mx.aol.com (mail_out_v36_r4.14.) id e.103.3f6fb7fa (18251); Tue, 17 Feb 2004 18:21:52 -0500 (EST) Message-ID: <103.3f6fb7fa.2d63fc0f@aol.com> Date: Tue, 17 Feb 2004 18:21:51 EST Subject: Re: [Sipping] SIP support for hold and ringback for operator / 91 1 services To: Brian.Rosen@marconi.com CC: sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_103.3f6fb7fa.2d63fc0f_boundary" X-Mailer: 6.0 for Windows XP sub 51 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 --part1_103.3f6fb7fa.2d63fc0f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/17/2004 5:43:57 PM Eastern Standard Time, Brian.Rosen@marconi.com writes: > We don't do national variants in the IETF. I didn't suggest doing a national variant. I said "recognize that emergency calling, connection holding, ringback, etc. are national matters". Then, all that the IETF needs to do is make sure it has generic protocols and security procedures in place so each country can define ways to use them so that people in that country can call emergency centers in that country according to the rules and laws applicable in that country. Mike Pierce --part1_103.3f6fb7fa.2d63fc0f_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/17/2004 5:43:57 PM Eastern Standard Time, Brian.Rosen@marconi.com wr= ites:


We don't do national varian= ts in the IETF.

I didn't suggest doing a national variant. I said "recognize that emerge= ncy calling, connection holding, ringback, etc. are national matters". Then,= all that the IETF needs to do is make sure it has generic protocols and sec= urity procedures in place so each country can define ways to use them so tha= t people in that country can call emergency centers in that country accordin= g to the rules and laws applicable in that country.

Mike Pierce
--part1_103.3f6fb7fa.2d63fc0f_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 18:31:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16702 for ; Tue, 17 Feb 2004 18:31:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEgd-0002XV-1Q for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 18:31:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HNVV66009758 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 18:31:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEgc-0002XJ-R1 for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 18:31:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16682 for ; Tue, 17 Feb 2004 18:31:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtEgZ-0002bB-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 18:31:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtEfe-0002YC-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 18:30:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtEfA-0002UZ-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 18:30:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEfC-0002MD-F3; Tue, 17 Feb 2004 18:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEeb-0002KT-Hf for sipping@optimus.ietf.org; Tue, 17 Feb 2004 18:29:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16545 for ; Tue, 17 Feb 2004 18:29:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtEeY-0002Tb-00 for sipping@ietf.org; Tue, 17 Feb 2004 18:29:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtEdl-0002RH-00 for sipping@ietf.org; Tue, 17 Feb 2004 18:28:34 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AtEdH-0002Nw-00 for sipping@ietf.org; Tue, 17 Feb 2004 18:28:03 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1HNRw5d023292; Tue, 17 Feb 2004 18:27:58 -0500 (EST) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1HNRvH19078; Tue, 17 Feb 2004 18:27:57 -0500 Message-ID: <4032A37D.9000007@cs.columbia.edu> Date: Tue, 17 Feb 2004 18:27:57 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: jdrosen@dynamicsoft.com, mli@nortelnetworks.com, sipping@ietf.org Subject: Re: [Sipping] SIP support for hold and ringback for operator / 911 services References: <122.2b7916de.2d639bd1@aol.com> In-Reply-To: <122.2b7916de.2d639bd1@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > someone calls 911 and hangs up before the call even gets to the > emergency center. In today's network, the originating side equipment > (central office) can know to do this when someone dials an emergency > number. For the SIP case, if the originating device can do this > (recognize the emergency number) or an outbound proxy does it, fine. Repeating my earlier comments: even in today's modern networks (E911, ISUP, etc.), the callee-control is neither mandated nor universally supported. At least, I'm still waiting for a spec that says so. That said, the whole process of recognizing digits and sending 'sos' is also meant to trigger whatever caller-side behavior is appropriate. > Another part of the issue regards the "ringback" function, which allows > the emergency center to re-ring the phone of someone who has gone > "on-hook" (or whatever similar function is used on the SIP phone to > indicate end-of-call). One of the earlier e-mails suggested that, if the > phone recognized 911, it could immediately re-ring the phone if the > person "hangs-up". I don't believe this meets the requirement. The > re-ring needs to be under the control of the emergency center, so they > can decide whether a re-ring is necessary or not. Callback is described in emergency-arc. > > Also, someone needs to look into the possible requirement to allow the > emergency center to alert the user even while they are "off-hook" while > the connection is being held. The American National Standard (for ISDN) > included this function. Can you cite chapter and verse? > There is another use of the holding function in today's network: tracing > of malicious calls. In this case, the request to hold the call must come > from the called end (but not the called party). I guess one of the > things about SIP and the environment it is used in is that it should not > be neccessary to hold a "connection" in order to provide malicious call > trace. However, we need to consider what happens for various > packet/Circuit switched interworking cases. I'm sure a malicious caller will faithfully follow all SIP standards :-) > > What this points out is the need to agree on the functional requirements > for Support for Hold and Ringback before doing detailed protocol work. > > Mike Pierce > Artel > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 18:42:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17172 for ; Tue, 17 Feb 2004 18:42:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEqM-0003Mk-Tx for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 18:41:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HNfYOa012932 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 18:41:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEqM-0003MV-PY for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 18:41:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17169 for ; Tue, 17 Feb 2004 18:41:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtEqJ-0003KK-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 18:41:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtEpS-0003H0-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 18:40:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtEoz-0003Ck-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 18:40:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEou-00038O-HY; Tue, 17 Feb 2004 18:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEoT-00036x-9F for sipping@optimus.ietf.org; Tue, 17 Feb 2004 18:39:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17042 for ; Tue, 17 Feb 2004 18:39:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtEoQ-0003A0-00 for sipping@ietf.org; Tue, 17 Feb 2004 18:39:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtEnd-00034M-00 for sipping@ietf.org; Tue, 17 Feb 2004 18:38:45 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtEmh-0002t0-00 for sipping@ietf.org; Tue, 17 Feb 2004 18:37:47 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1HNbEuA025359; Tue, 17 Feb 2004 15:37:15 -0800 (PST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGC86489; Tue, 17 Feb 2004 18:37:13 -0500 (EST) Message-ID: <4032A5A9.9000001@cisco.com> Date: Tue, 17 Feb 2004 18:37:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston CC: sipping@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-service-examples-06.txt References: <200402171537.KAA05881@ietf.org> <5.2.1.1.0.20040217165050.01579530@pop.mcit.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alan Johnston wrote: > At 03:41 PM 2/17/2004 -0500, Paul Kyzivat wrote: > >> As with the transfer examples, the changes here give the impression >> that things will be wonderful if you add "Supported: gruu" and >> continue to use your old contact address. >> >> If examples are to be given that depend upon gruus, then I think we >> need to show that the gruu is something special - not the same as the >> UA's normal contact address. > > > Paul, > > What do you have in mind? A GRUU is identical to any other URI - it > just meets the requirements in the draft. A GRUU doesn't need to look > different from any other URI - in fact, no one can tell by inspection if > a URI is a GRUU. > > Do you just want the example GRUUs to *look* different?? There are two possibilities here: - include in the call flows the REGISTER message that gets the gruu. Then it is entirely clear. - just make the GRUUs look different, in a suggestive way. It is especially deceptive if one example that doesn't use gruu uses the same contact address as another example that does use gruu. And using what is obviously intended to be the dns address of the endpoint itself, or worse the same address as is used for media addresses, is especially misleading. Something on the order of GRUUnnn@proxy.com would go a long way. Including a REGISTER in every example that uses gruus would probably be overkill. But it might be worthwhile to at least include examples that do obtain gruus appropriate for the examples that use them. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 17 20:33:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21936 for ; Tue, 17 Feb 2004 20:33:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtGZv-0005EY-2k for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 20:32:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I1WheQ020112 for sipping-archive@odin.ietf.org; Tue, 17 Feb 2004 20:32:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtGZu-0005EJ-U8 for sipping-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 20:32:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21922 for ; Tue, 17 Feb 2004 20:32:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtGZs-0003uj-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 20:32:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtGYt-0003rC-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 20:31:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtGYK-0003nA-00 for sipping-web-archive@ietf.org; Tue, 17 Feb 2004 20:31:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtGYH-000520-A4; Tue, 17 Feb 2004 20:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtGXk-00051H-QH for sipping@optimus.ietf.org; Tue, 17 Feb 2004 20:30:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21816 for ; Tue, 17 Feb 2004 20:30:26 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtGXi-0003kg-00 for sipping@ietf.org; Tue, 17 Feb 2004 20:30:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtGWh-0003gN-00 for sipping@ietf.org; Tue, 17 Feb 2004 20:29:24 -0500 Received: from imo-d05.mx.aol.com ([205.188.157.37]) by ietf-mx with esmtp (Exim 4.12) id 1AtGVl-0003Ys-00 for sipping@ietf.org; Tue, 17 Feb 2004 20:28:26 -0500 Received: from Mpierce1@aol.com by imo-d05.mx.aol.com (mail_out_v36_r4.14.) id 7.199.25f993cb (17079); Tue, 17 Feb 2004 20:26:16 -0500 (EST) Message-ID: <199.25f993cb.2d641937@aol.com> Date: Tue, 17 Feb 2004 20:26:15 EST Subject: Re: [Sipping] SIP support for hold and ringback for operator / 911 services To: hgs@cs.columbia.edu CC: jdrosen@dynamicsoft.com, mli@nortelnetworks.com, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_199.25f993cb.2d641937_boundary" X-Mailer: 6.0 for Windows XP sub 51 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 --part1_199.25f993cb.2d641937_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/17/2004 6:28:23 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > > > > Also, someone needs to look into the possible requirement to allow the > > emergency center to alert the user even while they are "off-hook" while > > the connection is being held. The American National Standard (for ISDN) > > included this function. > > Can you cite chapter and verse? > This capability was included in American National Standard T1.628a, Paragraph 6.2.8.1. I have to admit that I don't know of a document that actually describes the requirement to do this. It's unfortunate that many standards bodies, T1 included, often write protocol for things for which there is no hard requirement. I don't know about this case. I only mentioned it hoping that someone would know of a specific requirement. Mike --part1_199.25f993cb.2d641937_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/17/2004 6:28:23 PM Eastern Standard Time, hgs@cs.columbia.edu writes= :


>=20
> Also, someone needs to look into the possible requirement to allow=20= the=20
> emergency center to alert the user even while they are "off-hook" w= hile=20
> the connection is being held. The American National Standard (for I= SDN)=20
> included this function.

Can you cite chapter and verse?


This capability was included in American National Standard T1.628a, Para= graph 6.2.8.1. I have to admit that I don't know of a document that actually= describes the requirement to do this. It's unfortunate that many standards=20= bodies, T1 included, often write protocol for things for which there is no h= ard requirement. I don't know about this case. I only mentioned it hoping th= at someone would know of a specific requirement.

Mike
--part1_199.25f993cb.2d641937_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 18 09:21:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12094 for ; Wed, 18 Feb 2004 09:21:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSZU-0001tj-5G for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 09:21:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IEL4pT007294 for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 09:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSZU-0001tZ-1L for sipping-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 09:21:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12069 for ; Wed, 18 Feb 2004 09:21:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtSZS-0001Sd-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 09:21:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtSYP-0001Nl-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 09:19:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtSXb-0001KB-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 09:19:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSXX-0001gJ-F1; Wed, 18 Feb 2004 09:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSXU-0001fh-6n for sipping@optimus.ietf.org; Wed, 18 Feb 2004 09:19:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11978 for ; Wed, 18 Feb 2004 09:18:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtSXS-0001In-00 for sipping@ietf.org; Wed, 18 Feb 2004 09:18:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtSWU-0001Eg-00 for sipping@ietf.org; Wed, 18 Feb 2004 09:17:59 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AtSVs-00019A-00 for sipping@ietf.org; Wed, 18 Feb 2004 09:17:20 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 18 Feb 2004 06:16:52 -0800 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 i1IEGl4U027602; Wed, 18 Feb 2004 06:16:47 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQJ66663; Wed, 18 Feb 2004 06:16:46 -0800 (PST) In-Reply-To: <40293C6B.4060404@dynamicsoft.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797704@esebe019.ntc.nokia.com> <40293C6B.4060404@dynamicsoft.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26C87A2E-621D-11D8-9B6B-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: hisham.khartabil@nokia.com, sipping@ietf.org From: Rohan Mahy Subject: Re: [Sipping] Conference policy URI Date: Wed, 18 Feb 2004 06:17:15 -0800 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I believe the SIPPING working group has come down with a bad case of Ianaus Registritus. This rare, but preventable disease is caused by trying to register every possible field or parameter mentioned in a set of standards track documents. It is highly contagious to other related working groups. Treatment consists of deleting IANA Registration sections until the symptoms subside. The patient should begin feeling better immediately. Seriously, I like the new Call-Info purpose, but I think the IANA Registry goes way too far overboard. Remember that there is an administrative and political cost to setting up new IANA Registries. thansk, -rohan On Feb 10, 2004, at 12:17 PM, Jonathan Rosenberg wrote: > Thanks for doing this. Some comments. > > Firstly, on the registry itself. You need to give clearer guidance to > IANA on the registry. I would suggest including a table that shows how > it should look like. You need to tell IANA what information needs to > be provided in future RFCs that register additional values (value, RFC > number, registrant, etc.). Please take a look at rfc2434 > (ftp://ftp.rfc-editor.org/in-notes/rfc2434.txt). > > Secondly, on the "policy-uri" value - you need to specify, I think, > what the URI type is, and what the content is at that URI (at least a > mandatory to implement one) in order to get interoperability. Unlike > the other stuff, which is just rendered for user information, this > resource is processed by an automata, and I think you need to say more > about it. > > Thanks, > Jonathan R. > > hisham.khartabil@nokia.com wrote: > >> Thanks Jonathan. A draft has been submitted to the SIP WG. >> http://www.ietf.org/internet-drafts/draft-khartabil-sip-policy-uri- >> call-info-purpose-00.txt >> Regards, >> Hisham >>> -----Original Message----- >>> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>> Sent: 24.January.2004 04:44 >>> To: Khartabil Hisham (Nokia-TP/Helsinki) >>> Cc: sipping@ietf.org >>> Subject: Re: [Sipping] Conference policy URI >>> >>> >>> I think this is a reasonable usage of Call-Info. However, it can >>> only be done if a "purpose" tag value is registered with IANA, as >>> indicated by section 20.9. However, it ocurred to me, when reading >>> this, that we never set up an IANA registry for call-info purpose >>> tokens! Oops! Thats easily rectifiable; when the draft defining the >>> 'policy-uri' (or whatever its called) purpose tag is written, it >>> should also create the registry and register the other tokens >>> defined in rfc3261. >>> >>> -Jonathan R. >>> >>> hisham.khartabil@nokia.com wrote: >>> >>> >>>> Hi, >>>> >>>> There was consensus on the XCON mailing list that the conference >>>> state event package needs to include in the notification the >>>> conference policy URI. >>>> >>>> There was also consensus that some participants may not want to >>>> subscribe to the conference package but would still like to learn >>>> the conference policy URI. In this case, it was suggested that the >>>> Call-info header carries such information. Perhaps the >>>> cc-conferencing draft can include examples of that. >>>> >>>> Thanks, Hisham >>>> >>>> _______________________________________________ Sipping mailing >>>> list https://www1.ietf.org/mailman/listinfo/sipping This list is >>>> for NEW development of the application of SIP Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sip@ietf.org for new developments of core SIP >>>> >>> >>> -- >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>> Chief Technology Officer Parsippany, NJ 07054-2711 >>> dynamicsoft >>> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>> http://www.jdrosen.net PHONE: (973) 952-5000 >>> http://www.dynamicsoft.com >>> >>> > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 18 13:33:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07362 for ; Wed, 18 Feb 2004 13:33:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWVJ-0004w3-6S for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 13:33:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IIX1oK018970 for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 13:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWVJ-0004vt-2D for sipping-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 13:33:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07316 for ; Wed, 18 Feb 2004 13:32:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtWVG-0006wN-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 13:32:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtWUK-0006sv-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 13:32:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtWTT-0006qB-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 13:31:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWTN-0004gR-15; Wed, 18 Feb 2004 13:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWSg-0004eq-9g for sipping@optimus.ietf.org; Wed, 18 Feb 2004 13:30:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07110 for ; Wed, 18 Feb 2004 13:30:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtWSe-0006lt-00 for sipping@ietf.org; Wed, 18 Feb 2004 13:30:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtWRo-0006g9-00 for sipping@ietf.org; Wed, 18 Feb 2004 13:29:25 -0500 Received: from omzesmtp03.mci.com ([199.249.17.11]) by ietf-mx with esmtp (Exim 4.12) id 1AtWR3-0006V7-00 for sipping@ietf.org; Wed, 18 Feb 2004 13:28:37 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTA00K3XLYV69@firewall.mci.com> for sipping@ietf.org; Wed, 18 Feb 2004 18:28:07 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTA00601LYTQZ@pmismtp01.mcilink.com> for sipping@ietf.org; Wed, 18 Feb 2004 18:28:07 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.104.121]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTA006OFLYT7Q@pmismtp01.mcilink.com> for sipping@ietf.org; Wed, 18 Feb 2004 18:28:06 +0000 (GMT) Date: Wed, 18 Feb 2004 12:27:45 -0600 From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: sipping@ietf.org Message-id: <5.2.1.1.0.20040218122551.027555d0@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [Sipping] Fwd: I-D ACTION:draft-johnston-sipping-rtcp-summary-02.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 FYI - an update to the RTCP Summary Report Delivery to SIP Third Parties. The document now makes a first attempt at defining the event package and has some example call flows and messages. Comments/suggestions are most welcome. Thanks, Alan Johnston MCI sip:alan@sipstation.com >Date: Tue, 17 Feb 2004 16:37:22 -0500 >From: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-johnston-sipping-rtcp-summary-02.txt >Sender: owner-ietf-announce@ietf.org >To: IETF-Announce: ; >Reply-to: Internet-Drafts@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : RTCP Summary Report Delivery to SIP Third Parties > Author(s) : A. Johnston > Filename : draft-johnston-sipping-rtcp-summary-02.txt > Pages : 17 > Date : 2004-2-17 > >This document discusses the motivation and requirements for the >delivery of RTCP extended reports and other summary reports to >non-participants in the session. Several solution mechanisms are >also discussed and compared. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-johnston-sipping-rtcp-summary-02.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-johnston-sipping-rtcp-summary-02.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-johnston-sipping-rtcp-summary-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-2-17165549.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-johnston-sipping-rtcp-summary-02.txt > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 18 13:43:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07817 for ; Wed, 18 Feb 2004 13:43:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWf0-00068L-6w for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 13:43:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IIh2k5023571 for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 13:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWf0-000686-1i for sipping-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 13:43:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07772 for ; Wed, 18 Feb 2004 13:42:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtWex-0007eK-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 13:42:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtWe0-0007a8-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 13:42:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtWd5-0007WJ-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 13:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWd5-0005vd-0C; Wed, 18 Feb 2004 13:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWc9-0005ta-6H for sipping@optimus.ietf.org; Wed, 18 Feb 2004 13:40:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07661 for ; Wed, 18 Feb 2004 13:40:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtWc6-0007SE-00 for sipping@ietf.org; Wed, 18 Feb 2004 13:40:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtWbB-0007Nl-00 for sipping@ietf.org; Wed, 18 Feb 2004 13:39:06 -0500 Received: from [66.192.6.226] (helo=pope.teraglobal.com) by ietf-mx with esmtp (Exim 4.12) id 1AtWaF-0007F1-00 for sipping@ietf.org; Wed, 18 Feb 2004 13:38:07 -0500 Received: from WXPvhegde ([66.192.6.37]) by pope.teraglobal.com (Netscape Messaging Server 4.15) with SMTP id HTAMVN00.GIV for ; Wed, 18 Feb 2004 10:47:47 -0800 From: "Veda Hegde" To: Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-conference-package-03.txt Date: Wed, 18 Feb 2004 10:37:30 -0800 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200402181518.KAA19180@ietf.org> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I don't see anything that would indicate the state of individual media streams offered by user. If a user is offering audio and video, focus might choose to mix just the audio and not the video. In that case, is there a way to indicate that just the video stream was muted by the focus? Thanks, Veda -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, February 18, 2004 7:18 AM To: IETF-Announce: Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-conference-package-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : A Session Initiation Protocol (SIP) Event Package for Conference State Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sipping-conference-package-03.txt Pages : 27 Date : 2004-2-18 This document defines a conference event package for the Session Initiation Protocol (SIP) Events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference URI. Notifications are sent about changes in the membership of this conference, the status of users' participation in the conference, and the sidebars in the conference. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-conference-package-03 .txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-conference-package-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-conference-package-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 18 14:11:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10223 for ; Wed, 18 Feb 2004 14:11:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtX6S-0008Pn-GX for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 14:11:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IJBO68032341 for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 14:11:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtX6S-0008PY-A0 for sipping-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 14:11:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10120 for ; Wed, 18 Feb 2004 14:11:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtX6P-0003Fw-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 14:11:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtX49-0002jH-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 14:09:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AtX2G-0002LN-02 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 14:07:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AtWnn-0001Wg-Eh for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 13:52:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWnh-0006Sj-Ke; Wed, 18 Feb 2004 13:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWmk-0006OU-Nq for sipping@optimus.ietf.org; Wed, 18 Feb 2004 13:51:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08377 for ; Wed, 18 Feb 2004 13:51:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtWmi-0000cb-00 for sipping@ietf.org; Wed, 18 Feb 2004 13:51:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtWlr-0000WY-00 for sipping@ietf.org; Wed, 18 Feb 2004 13:50:07 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtWky-0000P9-00 for sipping@ietf.org; Wed, 18 Feb 2004 13:49:13 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 Feb 2004 10:57:40 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1IIme1m009721; Wed, 18 Feb 2004 10:48:40 -0800 (PST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGD38387; Wed, 18 Feb 2004 13:48:39 -0500 (EST) Message-ID: <4033B387.2030100@cisco.com> Date: Wed, 18 Feb 2004 13:48:39 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seanol@microsoft.com, oritl@microsoft.com CC: sipping@ietf.org References: <200402181438.JAA13470@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: draft-olson-sipping-refer-extensions-01.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Wow! You made a lot of changes in this version. I do have a number of comments about this version, below. I think I was happier with it before. This one seems to have run amuck. Paul First, a nit: The introduction says: Finally, there are situations where the party issuing the REFER request does not need the NOTIFY associated with the REFER, perhaps because that agent is already subscribed to the appropriate package outside of the REFER request. I agree there are situations where the referring party doesn't need the NOTIFY, but not because it is already subscribed for it. There is no way to independently subscribe to the refer event package. ---------- Section 7 says: The REFER-Issuer MAY specify the request for subscription to a specific package by including the MIME type in an Accept header. Yuk! All kinds of problems with this: - event packages are not defined by mime-types, they are defined by event package names. It is possible for several event packages to share a mime-type for their notifications, and for multiple mime-types to be permissible for a single event package. - subscribing to an event package requires both the event package name and the event id. (In the case of the special refer event package, the event id is defined by the cseq of the REFER message itself.) - If bundling REFER with an implicit subscription to the refer event package was a bad idea (as most seem to think) then bundling it with the establishment of arbitrary subscriptions is an even worse idea. - Based on the examples, this isn't really a matter of subscribing to a different event package. The event package named in the NOTIFY is still "refer", but the content-type is changed. So the effect is of redefining the refer event package so that it may return content equivalent to that of any other event package. This is at best a kludge. It also probably violates the rules for defining of event packages. In this model it isn't at all clear what defines how the content of the notifies is obtained, or when it is generated, since that is generally defined as part of an unnamed event package. If you really want to do this, then I think you must ammend the definition of the refer event package to include (presumably by reference) most of the definition of any of the other event packages that you might want to request this way. But I still think this is a bad idea. Even if it requires extra messages, I think subscriptions to anthing but the refer event package should be established first, before sending the refer. --------- Later in that section, another nit: In the INVITE example, two things that are generally lacking from the message/sipfrag content are the dialog identifier (Call-ID plus local and remote tags) and the state of the dialog. Not coincidentally, this is the same information available in the application/ dialog-info+xml MIME type [7] used for the dialog event package. The dialog-id can be available using the sipfrag content if refer-recipient chooses to provide them. They are available if the fragment contains the to, from, and call-id from the invite response. (I agree that certain dialog status may not be determined via the refer event package.) ---------- norefersub: While I think this is a good feature to support, I think it is a stretch to encode it as a required option. That mechanism is normally used for more general functionality that transcends a particular request. It would be good to have a way to specify this in a way that is more specific to refer. One alternative might be to add a norefersub parameter to the Refer-To header. (Also note that returning a 481 in response to the first NOTIFY may not always be a cheap way to cancel the subscription without norefersub. If the refer was sent within a preexisting dialog, returning a 481 to the notify might be construed as absence of the entire dialog. If so, all the things sharing the dialog might also be terminated. So in that case it may be necessary to cancel by sending a subscribe with expires:0, requiring 5 messages rather than one.) ------------ In general there seem to be far more option tags than are needed. I think it would be sufficient to define one new option tag indicating support for all the functionality in this draft. Requesting of specific features can be via other parameters or headers. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 18 15:41:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19136 for ; Wed, 18 Feb 2004 15:41:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYVH-0001nE-1W for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 15:41:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IKf6BW006888 for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 15:41:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYVF-0001mz-Kz for sipping-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 15:41:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19088 for ; Wed, 18 Feb 2004 15:41:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtYVE-0005vx-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 15:41:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtYUG-0005r3-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 15:40:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtYTH-0005n4-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 15:39:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYTF-0001R8-G7; Wed, 18 Feb 2004 15:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYST-0001Mu-2Q for sipping@optimus.ietf.org; Wed, 18 Feb 2004 15:38:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19015 for ; Wed, 18 Feb 2004 15:38:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtYSR-0005lJ-00 for sipping@ietf.org; Wed, 18 Feb 2004 15:38:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtYRZ-0005jQ-00 for sipping@ietf.org; Wed, 18 Feb 2004 15:37:18 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AtYRE-0005ge-00 for sipping@ietf.org; Wed, 18 Feb 2004 15:36:56 -0500 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 i1IKaO4U010501; Wed, 18 Feb 2004 12:36:24 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQK06038; Wed, 18 Feb 2004 12:36:23 -0800 (PST) In-Reply-To: <4031065B.9050500@dynamicsoft.com> References: <4031065B.9050500@dynamicsoft.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2E8EDAF6-6252-11D8-9B6B-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: sipping From: Rohan Mahy Subject: Re: [Sipping] URGENT: query on another reg-event change Date: Wed, 18 Feb 2004 12:36:51 -0800 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan, The current rev of the dialog package takes a middle approach. Rather than stick everything in a single string or apply semantics to every tag, the target tag (the equivalent of the contact tag in the registration package) can have sub-elements for contact parameters I think this would work just fine for the registration package. thanks, -rohan On Feb 16, 2004, at 10:05 AM, Jonathan Rosenberg wrote: > Folks, > > Authors 48 hours have started for reg-event. As you may recall, I had > found a fatal problem in the schema design, and there was agreement on > the list on a proposal to fix it. While making the changes in the > schema, another question came up. > > The question is regarding the "params" attribute of the "contact" > element. Currently, this parameter is meant to contain any of the > contact parameters not otherwise called out explicitly in other > attributes (for example, the q-value is contained in the "q" > attribute. So, if I had a contact like this: > > REGISTER > To: sip:user@example.com > Contact: sip:user@pc.example.com;q=1.0;newparam=foo;audio > > then the resulting XML would look like (using the new schema I > proposed on the list): > > > version="0" state="full"> > state="active"> > duration-registered="7322" > q="0.8" params="newparam=foo;audio"> > sip:user@pc887.example.com > > > > > Notice how the contact parameters are basically passed untouched in > the "params" attribute. This makes sense if that is the only point of > exensibility in the schema. But, now with the structured contact, one > could represent these "properly" with formal schema definitions. i.e., > if we did a reg-event extension to support caller-prefs, it could look > like: > > > xmlns:callerprefs="urn:ietf:params:xml:ns:callerprefs" > version="0" state="full"> > state="active"> > duration-registered="7322" > q="0.8" params="newparam=foo;audio"> > sip:user@pc887.example.com > > in reg-event that is used for unknown params, and for those that are > known to the server, and for which more structured xml specifications > exist, you could have things like . > > The technical drawback here is that whether a parameter appears in > unknown-param or whether its in something like callerprefs:audio > depends on whether that particular extension (in this case, > callerprefs) is supported by the server. Another choice is to not even > include unknown parameters in the reg-event notifications, however I > think thats a bad idea. > > The benefit, however, is that it allows us to provide very structured > notifications for contact header field extensions, and it avoids the > need for implementing, for example, a caller-prefs parser just to > receive notifications about caller preferences parameters - all the > data is represented using XML constructs. > > Technically, my preference would be to define the unknown-param in > reg-event right now, and have extensions (like callerprefs and gruu) > specify xml schema extensions to reg-event for their data. > > Please provide comments on this proposal within the next few days. > > Thanks, > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 18 16:28:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22499 for ; Wed, 18 Feb 2004 16:28:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZEK-0008DN-Pu for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 16:27:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ILRePi031571 for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 16:27:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZEK-0008D8-M3 for sipping-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 16:27:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22474 for ; Wed, 18 Feb 2004 16:27:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtZEI-0001jE-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 16:27:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtZDR-0001gj-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 16:26:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtZCm-0001eR-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 16:26:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZCk-0007v1-Gg; Wed, 18 Feb 2004 16:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZCN-0007lo-Fo for sipping@optimus.ietf.org; Wed, 18 Feb 2004 16:25:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22362 for ; Wed, 18 Feb 2004 16:25:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtZCL-0001cu-00 for sipping@ietf.org; Wed, 18 Feb 2004 16:25:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtZBU-0001an-00 for sipping@ietf.org; Wed, 18 Feb 2004 16:24:45 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AtZAl-0001U8-00 for sipping@ietf.org; Wed, 18 Feb 2004 16:24:00 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Feb 2004 13:25:07 -0800 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 18 Feb 2004 13:23:14 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Feb 2004 13:23:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-conference-package-03.txt Date: Wed, 18 Feb 2004 13:23:30 -0800 Message-ID: Thread-Topic: [Sipping] I-D ACTION:draft-ietf-sipping-conference-package-03.txt Thread-Index: AcP2TsXbvduGCvUtS/WUy5hNu8iExQAFFpqw From: "Orit Levin" To: "Veda Hegde" , X-OriginalArrivalTime: 18 Feb 2004 21:23:26.0121 (UTC) FILETIME=[71FF9190:01C3F665] Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable No, there is none ... By design. This draft defines a basic conference package. There are may useful things that we could add, but decided to leave out in order to agree on minimal set of useful and stable definitions. "Mute" status has been a topic of controversy in the past: what side does the mute? What streams are affected? Etc. The current version proposed to resolve the controversy when still keeping this useful status alive. Only "mute by focus" is reflected in the package. Also, as a general concept, it indicates that the user does not contribute to the conference an any way. I would say that if voice and/or IM is not muted, but just a noisy video is - the user is NOT muted-by-focus. The alternative to this approach would be NOT to have the mute status at all for the basic conference package... I obviously voted to have it in the format proposed in the latest version. I hope that it will still be useful to your applications, Orit. -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Veda Hegde Sent: Wednesday, February 18, 2004 10:38 AM To: sipping@ietf.org Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-conference-package-03.txt Hi, I don't see anything that would indicate the state of individual media streams offered by user. If a user is offering audio and video, focus might choose to mix just the audio and not the video. In that case, is there a way to indicate that just the video stream was muted by the focus? Thanks, Veda -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, February 18, 2004 7:18 AM To: IETF-Announce: Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-conference-package-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : A Session Initiation Protocol (SIP) Event Package for Conference State Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sipping-conference-package-03.txt Pages : 27 Date : 2004-2-18 This document defines a conference event package for the Session Initiation Protocol (SIP) Events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference URI. Notifications are sent about changes in the membership of this conference, the status of users' participation in the conference, and the sidebars in the conference. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-conference-packag e-03 .txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-conference-package-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-conference-package-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 18 16:58:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24890 for ; Wed, 18 Feb 2004 16:58:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZhq-0002mS-UE for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 16:58:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ILwAMX010682 for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 16:58:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZhq-0002mD-Q5 for sipping-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 16:58:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24780 for ; Wed, 18 Feb 2004 16:58:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtZho-0003wu-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 16:58:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtZgJ-0003i9-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 16:56:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AtZfK-0003Yp-01 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 16:55:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AtZTE-0005F5-5j for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 16:43:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZTB-00015y-7N; Wed, 18 Feb 2004 16:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZSz-00015C-BO for sipping@optimus.ietf.org; Wed, 18 Feb 2004 16:42:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24010 for ; Wed, 18 Feb 2004 16:42:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtZSx-00034A-00 for sipping@ietf.org; Wed, 18 Feb 2004 16:42:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtZSI-0002yI-00 for sipping@ietf.org; Wed, 18 Feb 2004 16:42:07 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AtZR5-0002hz-00 for sipping@ietf.org; Wed, 18 Feb 2004 16:40:51 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 18 Feb 2004 13:39:45 -0800 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 18 Feb 2004 13:39:31 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 18 Feb 2004 13:39:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Feb 2004 13:39:38 -0800 Message-ID: Thread-Topic: draft-olson-sipping-refer-extensions-01.txt Thread-Index: AcP2T9F1BPprEm6CQqWBhqN0YRpStgAFalYA From: "Orit Levin" To: "Paul Kyzivat" , "Sean Olson" Cc: X-OriginalArrivalTime: 18 Feb 2004 21:39:34.0173 (UTC) FILETIME=[B30094D0:01C3F667] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: draft-olson-sipping-refer-extensions-01.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks a lot for your comments! Answers are inline, Orit.=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Wednesday, February 18, 2004 10:49 AM To: Sean Olson; Orit Levin Cc: sipping@ietf.org Subject: Re: draft-olson-sipping-refer-extensions-01.txt Wow! You made a lot of changes in this version. I do have a number of comments about this version, below. I think I was happier with it before. This one seems to have run amuck. OL: At least it draws attention and generates useful comments:-)=20 Paul First, a nit: The introduction says: Finally, there are situations where the party issuing the REFER request does not need the NOTIFY associated with the REFER, perhaps because that agent is already subscribed to the appropriate package outside of the REFER request. I agree there are situations where the referring party doesn't need the NOTIFY, but not because it is already subscribed for it. There is no way to independently subscribe to the refer event package. OL: Agreed. ---------- Section 7 says: The REFER-Issuer MAY specify the request for subscription to a specific package by including the MIME type in an Accept header. Yuk! All kinds of problems with this: OL: I agree that it is much simpler to just suppress the implicit subscription (and subscribe to whatever package you need independently). From authors' perspective, it will meet our requirements. My inclination is that we stick to this feature only if we solve all the problems associated with it. We definitely need to work more on this part. - event packages are not defined by mime-types, they are defined by event package names. It is possible for several event packages to share a mime-type for their notifications, and for multiple mime-types to be permissible for a single event package. - subscribing to an event package requires both the event package name and the event id. (In the case of the special refer event package, the event id is defined by the cseq of the REFER message itself.) - If bundling REFER with an implicit subscription to the refer event package was a bad idea (as most seem to think) then bundling it with the establishment of arbitrary subscriptions is an even worse idea. - Based on the examples, this isn't really a matter of subscribing to a different event package. The event package named in the NOTIFY is still "refer", but the content-type is changed. So the effect is of redefining the refer event package so that it may return content equivalent to that of any other event package. This is at best a kludge. It also probably violates the rules for defining of event packages. In this model it isn't at all clear what defines how the content of the notifies is obtained, or when it is generated, since that is generally defined as part of an unnamed event package. If you really want to do this, then I think you must ammend the definition of the refer event package to include (presumably by reference) most of the definition of any of the other event packages that you might want to request this way. But I still think this is a bad idea. Even if it requires extra messages, I think subscriptions to anthing but the refer event package should be established first, before sending the refer. --------- Later in that section, another nit: In the INVITE example, two things that are generally lacking from the message/sipfrag content are the dialog identifier (Call-ID plus local and remote tags) and the state of the dialog. Not coincidentally, this is the same information available in the application/ dialog-info+xml MIME type [7] used for the dialog event package. The dialog-id can be available using the sipfrag content if refer-recipient chooses to provide them. They are available if the fragment contains the to, from, and call-id from the invite response. OL: Will refine the text. (I agree that certain dialog status may not be determined via the refer event package.) ---------- norefersub: While I think this is a good feature to support, I think it is a stretch to encode it as a required option. That mechanism is normally used for more general functionality that transcends a particular request. It would be good to have a way to specify this in a way that is more specific to refer. One alternative might be to add a norefersub parameter to the Refer-To header. OL: I agree. What level of support to request should be left up to the REFER-Issuer decision. (Also note that returning a 481 in response to the first NOTIFY may not always be a cheap way to cancel the subscription without norefersub. If the refer was sent within a preexisting dialog, returning a 481 to the notify might be construed as absence of the entire dialog. If so, all the things sharing the dialog might also be terminated. So in that case it may be necessary to cancel by sending a subscribe with expires:0, requiring 5 messages rather than one.) ------------ In general there seem to be far more option tags than are needed. I think it would be sufficient to define one new option tag indicating support for all the functionality in this draft. Requesting of specific features can be via other parameters or headers. OL: Yes, it is one of the issues I am going to raise in the meeting: What level of granularity we need for these extensions. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 18 18:15:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00214 for ; Wed, 18 Feb 2004 18:15:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atatx-00080O-Of for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 18:14:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1INEjor030765 for sipping-archive@odin.ietf.org; Wed, 18 Feb 2004 18:14:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atatx-000808-H2 for sipping-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 18:14:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00141 for ; Wed, 18 Feb 2004 18:14:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atatu-0000wh-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 18:14:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atasy-0000tV-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 18:13:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtasP-0000rO-00 for sipping-web-archive@ietf.org; Wed, 18 Feb 2004 18:13:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtasI-0007EW-IG; Wed, 18 Feb 2004 18:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atas4-0007BK-V0 for sipping@optimus.ietf.org; Wed, 18 Feb 2004 18:12:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29946 for ; Wed, 18 Feb 2004 18:12:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atas2-0000qt-00 for sipping@ietf.org; Wed, 18 Feb 2004 18:12:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atar5-0000ol-00 for sipping@ietf.org; Wed, 18 Feb 2004 18:11:48 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Ataqs-0000mW-00 for sipping@ietf.org; Wed, 18 Feb 2004 18:11:34 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 18 Feb 2004 15:12:41 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1INB30K003281; Wed, 18 Feb 2004 18:11:03 -0500 (EST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGD63355; Wed, 18 Feb 2004 18:11:02 -0500 (EST) Message-ID: <4033F106.2030605@cisco.com> Date: Wed, 18 Feb 2004 18:11:02 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sipping References: <402C8194.1080109@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: draft-camarillo-sipping-uri-list-01 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In section 3, the following is a sleeper: Network administrators should note that they need to configure proxies to route correctly Request-URIs that contain a "list" parameter and are addressed to their domain. AFAIK there is no definition of what "route correctly" means, nor is there anything in 3261 that would suggest that proxies be configurable to do this. I presume what you mean is that when a a proxy is routing a request that was addressed to an AOR it controls, and that address contains a url parameter named "list", a copy of the list parameter should be inserted into each selected target sip or sips uri. If that is what you mean, then this needs to be called out as a 3261 extension. I suppose it doesn't need an option name, because the exploder won't be referenced unless it has first been deployed, and it can't be deployed unless there is a proxy that supports this option. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 19 00:03:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13309 for ; Thu, 19 Feb 2004 00:03:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgKn-0003xm-B5 for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 00:02:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J52nLq015230 for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 00:02:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgKn-0003xZ-7P for sipping-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 00:02:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13293 for ; Thu, 19 Feb 2004 00:02:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtgKk-0001wF-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 00:02:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtgJn-0001uY-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 00:01:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtgJA-0001te-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 00:01:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgJ5-0003eR-F5; Thu, 19 Feb 2004 00:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgIt-0003dm-0V for sipping@optimus.ietf.org; Thu, 19 Feb 2004 00:00:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13278 for ; Thu, 19 Feb 2004 00:00:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtgIq-0001tE-00 for sipping@ietf.org; Thu, 19 Feb 2004 00:00:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtgHx-0001s7-00 for sipping@ietf.org; Wed, 18 Feb 2004 23:59:54 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx with esmtp (Exim 4.12) id 1AtgHj-0001qZ-00 for sipping@ietf.org; Wed, 18 Feb 2004 23:59:39 -0500 Received: from harvest.india.hp.com (harvest.india.hp.com [15.76.216.203]) by atlrel9.hp.com (Postfix) with ESMTP id D47C71C007BB for ; Wed, 18 Feb 2004 23:59:38 -0500 (EST) Received: from nt13192 (nt13192.india.hp.com [15.76.113.192]) by harvest.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id KAA03404 for ; Thu, 19 Feb 2004 10:31:26 +0530 (IST) From: "Banibrata Dutta" To: "'sipping'" Date: Thu, 19 Feb 2004 10:29:23 +0530 Message-ID: <002501c3f6a5$240d6440$c0714c0f@nt13192> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C3F6D3.3DC5A040" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Sipping] OFF-TOPIC : stripping headers from TXT I-D's Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C3F6D3.3DC5A040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit hi, many of the I-D's submitted have header/footers cutting accross a diagram in many text files. this is not desirable many a times, for e.g. when i want to take a hard-copy for future reference, it's always easy reading if the full diagram or table fits one page and not split of 2 (unless it's unavoidable because of it's size). so, won't it be better to add this as a guideline to I-D submitters i.e. the pagination takes care of this (although i've not idea how to do it, as the pagination program is not that smart unless it's modified to identify pre-existing ^L's and take that as page-breaks. finally, i doubt that the above wish would be fulfilled anytime soon, so wanted to ask if there's a way to remove the headers/footers smartly, i.e only the 2/3/4 lines added by a header/ footer are removed, and all other blank-lines / white-space containing lines are not touched. a multi-line search-replace is what is required. thanks & regards, Banibrata Dutta Hewlett-Packard ISO Pvt. Ltd, 29, Cunningham Road, Bangalore - 560052, India. Tel: +91-80-22051796 ------=_NextPart_000_0026_01C3F6D3.3DC5A040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
hi,
 
many = of the I-D's=20 submitted have header/footers cutting accross a diagram in many text=20 files.
this = is not=20 desirable many a times, for e.g. when i want to take a hard-copy for = future=20 reference,
it's = always easy=20 reading if the full diagram or table fits one page and not split of 2 = (unless=20 it's
unavoidable because=20 of it's size).
 
so, = won't it be=20 better to add this as a guideline to I-D submitters i.e. the pagination=20 takes
care = of this=20 (although i've not idea how to do it, as the pagination program is not = that=20 smart
unless = it's modified=20 to identify pre-existing ^L's and take that as = page-breaks.
 
finally, i doubt=20 that the above wish would be fulfilled anytime soon, so wanted to ask if = there's
a way = to remove the=20 headers/footers smartly, i.e only the 2/3/4 lines added by a=20 header/
footer = are removed,=20 and all other blank-lines / white-space containing lines are not=20 touched.
a = multi-line=20 search-replace is what is required.
 

thanks & regards,
Banibrata Dutta
 =20 Hewlett-Packard ISO Pvt. Ltd,
  29, Cunningham Road,
  = Bangalore=20 - 560052, India.
  Tel: +91-80-22051796
 =20

------=_NextPart_000_0026_01C3F6D3.3DC5A040-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 19 01:59:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17296 for ; Thu, 19 Feb 2004 01:59:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ati9F-00040e-GV for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 01:59:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J6x1la015398 for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 01:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ati9E-00040D-If for sipping-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 01:59:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17272 for ; Thu, 19 Feb 2004 01:58:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ati9A-0007Vy-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 01:58:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ati8C-0007So-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 01:57:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ati7O-0007Qj-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 01:57:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ati7J-0003fY-V1; Thu, 19 Feb 2004 01:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAds-0002Dj-5k for sipping@optimus.ietf.org; Tue, 17 Feb 2004 14:12:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27771 for ; Tue, 17 Feb 2004 14:12:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtAdp-0003n6-00 for sipping@ietf.org; Tue, 17 Feb 2004 14:12:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAcv-0003jn-00 for sipping@ietf.org; Tue, 17 Feb 2004 14:11:25 -0500 Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx with esmtp (Exim 4.12) id 1AtAcb-0003gA-00 for sipping@ietf.org; Tue, 17 Feb 2004 14:11:05 -0500 Received: from csc.com (va-fch32.csc.com [20.6.39.233]) by amer-mta01.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1HJDcSc022174 for ; Tue, 17 Feb 2004 14:13:38 -0500 (EST) Subject: Re: [Sipping] Re: sos - dead or alive To: "Henning Schulzrinne" Cc: "Cullen Jennings" , sipping@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Tue, 17 Feb 2004 14:09:48 -0500 X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 6.0.3|September 26, 2003) at 02/17/2004 02:10:54 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Bear in mind that the "most scarce resource" in the emergency response system is usually the human operators. So any kind of regular, scheduled test should be designed so it does NOT tie up the operators. Janet ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- "Henning Schulzrinne" To: "Cullen Jennings" @cs.columbia.edu Subject: [Sipping] Re: sos - dead or alive > 02/17/2004 11:18 AM > I would prefer MUST to RECOMMENDED since a recent informal poll at sipit > made it quiet clear that most implementers view SHOULD level requirements as > something to consider in the next lifetime. I'm not arguing that this poll > means we should not use SHOULD in general, but I think due to the critical > nature of this specification, we should be a little stronger than normal. I > don't want vendors saying they support this RFC fully when they can't detect > that a safety critical system is broken. Gladly obliged. > > I would prefer specific test times - something like the test should be > performed at a random time between 12 and 36 hours. Phones must prominently Currently, there are about 200 million real 911 calls a year. Testing once per day would essentially impose this load once per day. While I don't think building proxies that can handle this is a bad idea (among other advantages, it provides ample margin of safety and load-resistance since real calls are then a tiny fraction of the test traffic), it does need to be considered. From local usage, I know that fire alarm bells at Columbia are tested weekly, so that may be a more reasonable schedule. > display the information that 911 is broken using a display or by changing > the dial tone on all calls. Would be nice to consider the impact of every > phone doing this. Phones SHOULD not do a test immediately after booting. > Phones MAY provide a UI to allow a user to manual imitate a test - this is > very useful for someone that is trying to check a 911 system but does not > want to wait 36 hours. I like the gist of this and have added appropriate text. > > Cullen > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 19 01:59:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17313 for ; Thu, 19 Feb 2004 01:59:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ati9G-00041U-OE for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 01:59:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J6x2Vg015458 for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 01:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ati9G-00041F-JY for sipping-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 01:59:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17276 for ; Thu, 19 Feb 2004 01:59:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ati9D-0007WJ-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 01:58:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ati8D-0007T0-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 01:57:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ati7O-0007Qk-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 01:57:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ati7K-0003ft-Sz; Thu, 19 Feb 2004 01:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAtL-0004C8-AS for sipping@optimus.ietf.org; Tue, 17 Feb 2004 14:28:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28579 for ; Tue, 17 Feb 2004 14:28:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtAtI-0004zF-00 for sipping@ietf.org; Tue, 17 Feb 2004 14:28:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAsI-0004sC-00 for sipping@ietf.org; Tue, 17 Feb 2004 14:27:18 -0500 Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx with esmtp (Exim 4.12) id 1AtArK-0004la-00 for sipping@ietf.org; Tue, 17 Feb 2004 14:26:18 -0500 Received: from csc.com (va-fch32.csc.com [20.6.39.233]) by amer-mta02.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1HJRMi6008693 for ; Tue, 17 Feb 2004 14:27:22 -0500 (EST) Subject: Re: [Sipping] Re: sos - dead or alive To: Henning Schulzrinne Cc: Cullen Jennings , sipping@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Tue, 17 Feb 2004 14:24:52 -0500 X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 6.0.3|September 26, 2003) at 02/17/2004 02:26:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sounds good then. ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- Henning Schulzrinne @cs.columbia.edu cc: Cullen Jennings , sipping@ietf.org > Subject: Re: [Sipping] Re: sos - dead or alive 02/17/2004 02:14 PM The OPTIONS mechanism does exactly that - it's mechanical only. Janet P Gunn wrote: > Bear in mind that the "most scarce resource" in the emergency response > system is usually the human operators. > > So any kind of regular, scheduled test should be designed so it does NOT > tie up the operators. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 19 02:42:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03881 for ; Thu, 19 Feb 2004 02:42:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atios-0007vy-1D for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 02:42:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J7g1eB030490 for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 02:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atior-0007vb-AE for sipping-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 02:42:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03863 for ; Thu, 19 Feb 2004 02:41:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ation-00023N-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 02:41:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atint-0001zi-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 02:41:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtinE-0001x8-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 02:40:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atimz-0007dF-UR; Thu, 19 Feb 2004 02:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atimh-0007ak-8o for sipping@optimus.ietf.org; Thu, 19 Feb 2004 02:39:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03093 for ; Thu, 19 Feb 2004 02:39:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atimd-0001rq-00 for sipping@ietf.org; Thu, 19 Feb 2004 02:39:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atila-0001i7-00 for sipping@ietf.org; Thu, 19 Feb 2004 02:38:39 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AtikM-0001Yq-00 for sipping@ietf.org; Thu, 19 Feb 2004 02:37:22 -0500 Received: from [147.6.42.146] (helo=filter2.kt.co.kr) by mx2.foretec.com with esmtp (Exim 4.24) id 1AtiSf-0003Gz-8i for sipping@ietf.org; Thu, 19 Feb 2004 02:19:05 -0500 Received: from external ([147.6.42.21]) by filter2 (1.0) id i1J7Hcu42981; Thu, 19 Feb 2004 16:17:38 +0900 Received: from MAIL01CL ([147.6.42.211]) by SMTP01.oasys.kt.co.kr with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Feb 2004 16:23:19 +0900 Received: from mail01a ([147.6.42.214]) by MAIL01CL with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Feb 2004 16:23:19 +0900 Priority: normal Thread-Topic: Re: [Sipping] draft-cgkim-sipping-info-00 thread-index: AcP2uT+yOV5DtTOpS4OyU1Fp7oJXAg== Reply-To: =?ks_c_5601-1987?B?sejD4bHU?= From: =?ks_c_5601-1987?B?sejD4bHU?= To: "Henning Schulzrinne" , Cc: Subject: RE: Re: [Sipping] draft-cgkim-sipping-info-00 Date: Thu, 19 Feb 2004 16:23:19 +0900 Message-ID: <4b7b501c3f6b9$3fb27af0$d32a0693@oasys.kt.co.kr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_4B7B6_01C3F704.AF9A22F0" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-OriginalArrivalTime: 19 Feb 2004 07:23:19.0455 (UTC) FILETIME=[3FB27AF0:01C3F6B9] Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.3 required=5.0 tests=AWL,HTML_MESSAGE, MIME_BASE64_TEXT,MIME_HTML_NO_CHARSET autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_4B7B6_01C3F704.AF9A22F0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable IM seems to be appropriate for PTZ control and MRCP for exchanging = sesison commands under RTP circumstances if I define some applications = specific to this project.=0A= Camera control, however, needs to be implemented quite simplely to = reduce the cost of stacking SIP in the control unit.=0A= It seems to me that this suggestions are heavy a little bit for this = purpose, though. =0A= Aren't they ?=0A= =0A= =0A= -----=BF=F8=BA=BB =B8=DE=BD=C3=C1=F6-----=0A= =BA=B8=B3=BD =BB=E7=B6=F7: "Henning Schulzrinne" =0A= =BA=B8=B3=BD =B3=AF=C2=A5: 2004-02-15 =BF=C0=C0=FC 2:36:59=0A= =B9=DE=B4=C2 =BB=E7=B6=F7: "Cullen Jennings" =0A= =C2=FC=C1=B6: "sipping" <>=0A= =C1=A6=B8=F1: Re: [Sipping] draft-cgkim-sipping-info-00=0A= =0A= =0A= IM works quite well for this and similar applications. We use it to=0A= control other devices beyond cameras, too, as sending an IM saying "look=0A= at me" and "move camera 20 degrees" are semantically rather similar.=0A= =0A= Should this be in MMUSIC?=0A= =0A= Cullen Jennings wrote:=0A= =0A= > I think this topic of far end camera control is important but I don't = think=0A= > this is the right way to do it. It seems like it would work better to = use=0A= > SIP to set up a session and use the data in this session to do the = control.=0A= > Sort of like MRCPv2 or session mode IM does. Have you considered = something=0A= > like using session mode IM to send mime bodies controlled the camera. = One=0A= > could define a mime type like application/fecc and send IM with a body = like=0A= >=0A= > =0A= >=0A= > To pan clockwise by 20 degrees from the present position. Anyway, I = don't=0A= > know the best way to do this and we should probably figure out = requirements=0A= > before jumping into solutions but I would be glad to see some work = like this=0A= > get done. Not sure that sipping is the best place for it.=0A= >=0A= > Cullen=0A= >=0A= >=0A= > =0A= >=0A= >=0A= > _______________________________________________=0A= > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping=0A= > This list is for NEW development of the application of SIP=0A= > Use sip-implementors@cs.columbia.edu for questions on current sip=0A= > Use sip@ietf.org for new developments of core SIP=0A= =0A= _______________________________________________=0A= Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping=0A= This list is for NEW development of the application of SIP=0A= Use sip-implementors@cs.columbia.edu for questions on current sip=0A= Use sip@ietf.org for new developments of core SIP ------=_NextPart_000_4B7B6_01C3F704.AF9A22F0 Content-Type: text/html Content-Transfer-Encoding: base64 PERJViBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4siI+CjxESVY+SU0g c2VlbXMgdG8gYmUgYXBwcm9wcmlhdGUgZm9yIFBUWiBjb250cm9sIGFuZCBNUkNQIGZvciZuYnNw O2V4Y2hhbmdpbmcgc2VzaXNvbiBjb21tYW5kcyB1bmRlciBSVFAgY2lyY3Vtc3RhbmNlcyBpZiBJ IGRlZmluZSBzb21lIGFwcGxpY2F0aW9ucyBzcGVjaWZpYyB0byB0aGlzIHByb2plY3QuPC9ESVY+ CjxESVY+Q2FtZXJhIGNvbnRyb2wsIGhvd2V2ZXIsJm5ic3A7bmVlZHMgdG8gYmUgaW1wbGVtZW50 ZWQmbmJzcDtxdWl0ZSBzaW1wbGVseSB0byByZWR1Y2UgdGhlIGNvc3Qgb2Ygc3RhY2tpbmcgU0lQ IGluIHRoZSBjb250cm9sIHVuaXQuPC9ESVY+CjxESVY+SXQgc2VlbXMgdG8gbWUgdGhhdCB0aGlz Jm5ic3A7c3VnZ2VzdGlvbnMmbmJzcDthcmUgaGVhdnkgYSBsaXR0bGUgYml0IGZvciB0aGlzIHB1 cnBvc2UsIHRob3VnaC4mbmJzcDs8L0RJVj4KPERJVj5BcmVuJ3QgdGhleSA/PC9ESVY+CjxESVY+ PEJSPjxCUj4tLS0tLb/4ursguN69w8H2LS0tLS08QlI+PEI+urizvSC757b3OjwvQj4gIkhlbm5p bmcgU2NodWx6cmlubmUiICZsdDtoZ3NAY3MuY29sdW1iaWEuZWR1Jmd0OzxCUj48Qj66uLO9ILOv wqU6PC9CPiAyMDA0LTAyLTE1IL/AwPwgMjozNjo1OTxCUj48Qj653rTCILvntvc6PC9CPiAiQ3Vs bGVuIEplbm5pbmdzIiAmbHQ7Zmx1ZmZ5QGNpc2NvLmNvbSZndDs8QlI+PEI+wvzBtjo8L0I+ICJz aXBwaW5nIiAmbHQ7Jmd0OzxCUj48Qj7BprjxOjwvQj4gUmU6IFtTaXBwaW5nXSBkcmFmdC1jZ2tp bS1zaXBwaW5nLWluZm8tMDA8QlI+PEJSPjwvRElWPgo8TUVUQSBjb250ZW50PSJNUyBFeGNoYW5n ZSBTZXJ2ZXIgdmVyc2lvbiA2LjAuNjQ5OS4wIiBuYW1lPUdlbmVyYXRvcj48IS0tIENvbnZlcnRl ZCBmcm9tIHRleHQvcGxhaW4gZm9ybWF0IC0tPgo8UD48Rk9OVCBzaXplPTI+SU0gd29ya3MgcXVp dGUgd2VsbCBmb3IgdGhpcyBhbmQgc2ltaWxhciBhcHBsaWNhdGlvbnMuIFdlIHVzZSBpdCB0bzxC Uj5jb250cm9sIG90aGVyIGRldmljZXMgYmV5b25kIGNhbWVyYXMsIHRvbywgYXMgc2VuZGluZyBh biBJTSBzYXlpbmcgImxvb2s8QlI+YXQgbWUiIGFuZCAibW92ZSBjYW1lcmEgMjAgZGVncmVlcyIg YXJlIHNlbWFudGljYWxseSByYXRoZXIgc2ltaWxhci48QlI+PEJSPlNob3VsZCB0aGlzIGJlIGlu IE1NVVNJQz88QlI+PEJSPkN1bGxlbiBKZW5uaW5ncyB3cm90ZTo8QlI+PEJSPiZndDsgSSB0aGlu ayB0aGlzIHRvcGljIG9mIGZhciBlbmQgY2FtZXJhIGNvbnRyb2wgaXMgaW1wb3J0YW50IGJ1dCBJ IGRvbid0IHRoaW5rPEJSPiZndDsgdGhpcyBpcyB0aGUgcmlnaHQgd2F5IHRvIGRvIGl0LiBJdCBz ZWVtcyBsaWtlIGl0IHdvdWxkIHdvcmsgYmV0dGVyIHRvIHVzZTxCUj4mZ3Q7IFNJUCB0byBzZXQg dXAgYSBzZXNzaW9uIGFuZCB1c2UgdGhlIGRhdGEgaW4gdGhpcyBzZXNzaW9uIHRvIGRvIHRoZSBj b250cm9sLjxCUj4mZ3Q7IFNvcnQgb2YgbGlrZSBNUkNQdjIgb3Igc2Vzc2lvbiBtb2RlIElNIGRv ZXMuIEhhdmUgeW91IGNvbnNpZGVyZWQgc29tZXRoaW5nPEJSPiZndDsgbGlrZSB1c2luZyBzZXNz aW9uIG1vZGUgSU0gdG8gc2VuZCBtaW1lIGJvZGllcyBjb250cm9sbGVkIHRoZSBjYW1lcmEuIE9u ZTxCUj4mZ3Q7IGNvdWxkIGRlZmluZSBhIG1pbWUgdHlwZSBsaWtlIGFwcGxpY2F0aW9uL2ZlY2Mg YW5kIHNlbmQgSU0gd2l0aCBhIGJvZHkgbGlrZTxCUj4mZ3Q7PEJSPiZndDsgJmx0O3Bhbi1yZWxh dGl2ZSBhbmdsZT0iMjAiIFwmZ3Q7PEJSPiZndDs8QlI+Jmd0OyBUbyBwYW4gY2xvY2t3aXNlIGJ5 IDIwIGRlZ3JlZXMgZnJvbSB0aGUgcHJlc2VudCBwb3NpdGlvbi4gQW55d2F5LCBJIGRvbid0PEJS PiZndDsga25vdyB0aGUgYmVzdCB3YXkgdG8gZG8gdGhpcyBhbmQgd2Ugc2hvdWxkIHByb2JhYmx5 IGZpZ3VyZSBvdXQgcmVxdWlyZW1lbnRzPEJSPiZndDsgYmVmb3JlIGp1bXBpbmcgaW50byBzb2x1 dGlvbnMgYnV0IEkgd291bGQgYmUgZ2xhZCB0byBzZWUgc29tZSB3b3JrIGxpa2UgdGhpczxCUj4m Z3Q7IGdldCBkb25lLiBOb3Qgc3VyZSB0aGF0IHNpcHBpbmcgaXMgdGhlIGJlc3QgcGxhY2UgZm9y IGl0LjxCUj4mZ3Q7PEJSPiZndDsgQ3VsbGVuPEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7Jm5ic3A7 PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPEJSPiZndDsgU2lwcGluZyBtYWlsaW5nIGxpc3QmbmJzcDsgPEEgaHJl Zj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwcGluZyI+aHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwcGluZzwvQT48QlI+Jmd0OyBUaGlz IGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgYXBwbGljYXRpb24gb2YgU0lQPEJS PiZndDsgVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMg b24gY3VycmVudCBzaXA8QlI+Jmd0OyBVc2Ugc2lwQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1l bnRzIG9mIGNvcmUgU0lQPEJSPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxCUj5TaXBwaW5nIG1haWxpbmcgbGlzdCZuYnNwOyA8QSBocmVmPSJodHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBwaW5nIj5odHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBwaW5nPC9BPjxCUj5UaGlzIGxpc3QgaXMgZm9y IE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgYXBwbGljYXRpb24gb2YgU0lQPEJSPlVzZSBzaXAtaW1w bGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwPEJS PlVzZSBzaXBAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb2YgY29yZSBTSVA8QlI+PEJS PjwvRk9OVD48L1A+PC9ESVY+PEJSPg== ------=_NextPart_000_4B7B6_01C3F704.AF9A22F0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 19 09:09:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19166 for ; Thu, 19 Feb 2004 09:09:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtorT-0005Zi-VI for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 09:09:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JE97BY021426 for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 09:09:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtorT-0005ZV-OZ for sipping-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 09:09:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19114 for ; Thu, 19 Feb 2004 09:09:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtorS-00066B-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 09:09:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtoqU-00062G-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 09:08:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atopa-0005zH-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 09:07:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtopR-0004iK-EV; Thu, 19 Feb 2004 09:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atooe-0004gY-WA for sipping@optimus.ietf.org; Thu, 19 Feb 2004 09:06:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19025 for ; Thu, 19 Feb 2004 09:06:10 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atood-0005w5-00 for sipping@ietf.org; Thu, 19 Feb 2004 09:06:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atona-0005t8-00 for sipping@ietf.org; Thu, 19 Feb 2004 09:05:06 -0500 Received: from imo-m21.mx.aol.com ([64.12.137.2]) by ietf-mx with esmtp (Exim 4.12) id 1Atomd-0005p7-00 for sipping@ietf.org; Thu, 19 Feb 2004 09:04:07 -0500 Received: from Mpierce1@aol.com by imo-m21.mx.aol.com (mail_out_v36_r4.14.) id t.3d.3ae4ae03 (17377); Thu, 19 Feb 2004 09:03:29 -0500 (EST) Message-ID: <3d.3ae4ae03.2d661c31@aol.com> Date: Thu, 19 Feb 2004 09:03:29 EST Subject: Re: [Sipping] Re: sos - dead or alive To: jgunn6@csc.com, hgs@cs.columbia.edu CC: sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_3d.3ae4ae03.2d661c31_boundary" X-Mailer: 6.0 for Windows XP sub 51 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 --part1_3d.3ae4ae03.2d661c31_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/19/2004 1:58:18 AM Eastern Standard Time, jgunn6@csc.com writes: > So any kind of regular, scheduled test should be designed so it does NOT > tie up the operators. > I believe the test must be devised so that it does not involve the emergency center or any of the equipment directly supporting the emergency center at all. Mike --part1_3d.3ae4ae03.2d661c31_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/19/2004 1:58:18 AM Eastern Standard Time, jgunn6@csc.com writes:


So any kind of regular, sch= eduled test should be designed so it does  NOT
tie up the operators.

I believe the test must be devised so that it does not involve the em= ergency center or any of the equipment directly supporting the emergency cen= ter at all.

Mike

--part1_3d.3ae4ae03.2d661c31_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 19 09:34:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20030 for ; Thu, 19 Feb 2004 09:34:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtpFh-0002Lx-4M for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 09:34:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JEY91u009045 for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 09:34:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtpFh-0002Ln-0j for sipping-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 09:34:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19965 for ; Thu, 19 Feb 2004 09:34:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtpFf-0007TN-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 09:34:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtpEg-0007OZ-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 09:33:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtpDi-0007Km-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 09:32:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtpDe-0001xt-So; Thu, 19 Feb 2004 09:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtpCx-0001wx-8M for sipping@optimus.ietf.org; Thu, 19 Feb 2004 09:31:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19872 for ; Thu, 19 Feb 2004 09:31:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtpCv-0007IM-00 for sipping@ietf.org; Thu, 19 Feb 2004 09:31:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtpBw-0007FR-00 for sipping@ietf.org; Thu, 19 Feb 2004 09:30:17 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AtpBL-0007AD-00 for sipping@ietf.org; Thu, 19 Feb 2004 09:29:39 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCPS6B>; Thu, 19 Feb 2004 09:29:09 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6418@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Mpierce1@aol.com'" , jgunn6@csc.com, hgs@cs.columbia.edu Cc: sipping@ietf.org Subject: RE: [Sipping] Re: sos - dead or alive Date: Thu, 19 Feb 2004 09:29:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I don't agree. To be effective, you have to know you can get to a system that itself has certain knowledge that the call will reach an emergency call taker. Since there is not necessarily any "carrier" involved, you have to get to a system that is run by the emergency response system in the jurisdiction that you are located. It has to route (in the IP sense) the same as a real emergency call would route. It doesn't have to get all the way to an operator, but it does have to get close. If the result of the process (such as my suggestion in draft-rosen-dns-sos-00) to obtain the URL of the ECC serving the location of the caller is sip:anyone@emergency.northwest.allegheny.pa.us, then test calls might go to sip:verify@test.northwest.allegheny.pa.us. That may be a different host, but it would share the same router and route that a real emergency call would. It could be that a jurisdiction above the ERC runs a network that handles all emergency calls within its jurisdictions, and test calls could terminate there. For example, the State of Vermont could have all calls within Vermont have a test service at sip:verify@test.vt.us, as long as it also had all the emergency calls going to, for example, sip:anyone@emergency.vt.us. That might be a proxy server that did more fine grained routing based on location to the actual ERC that served the caller. For example, it might rewrite the Request-URI to sip:anyone@burlington.emergency.vt.us and route the call over its network to the ERC in the city of Burlington. Brian -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Thursday, February 19, 2004 9:03 AM To: jgunn6@csc.com; hgs@cs.columbia.edu Cc: sipping@ietf.org Subject: Re: [Sipping] Re: sos - dead or alive In a message dated 2/19/2004 1:58:18 AM Eastern Standard Time, jgunn6@csc.com writes: So any kind of regular, scheduled test should be designed so it does NOT tie up the operators. I believe the test must be devised so that it does not involve the emergency center or any of the equipment directly supporting the emergency center at all. Mike _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 19 10:27:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23201 for ; Thu, 19 Feb 2004 10:27:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atq54-00057N-AS for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 10:27:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JFREeh019669 for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 10:27:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atq53-00057A-Qg for sipping-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 10:27:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23180 for ; Thu, 19 Feb 2004 10:27:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atq51-0002Wq-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 10:27:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atq47-0002V3-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 10:26:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atq3y-0002T7-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 10:26:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atq3t-0004t2-Kn; Thu, 19 Feb 2004 10:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atq38-0004rP-P7 for sipping@optimus.ietf.org; Thu, 19 Feb 2004 10:25:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23154 for ; Thu, 19 Feb 2004 10:25:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atq36-0002Rt-00 for sipping@ietf.org; Thu, 19 Feb 2004 10:25:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atq2A-0002Pv-00 for sipping@ietf.org; Thu, 19 Feb 2004 10:24:14 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1Atq1G-0002LG-00 for sipping@ietf.org; Thu, 19 Feb 2004 10:23:18 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i1JFMmfX013259 for ; Thu, 19 Feb 2004 09:22:48 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Feb 2004 09:18:20 -0600 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FGYLS4SX; Thu, 19 Feb 2004 09:22:46 -0600 Message-ID: <4034D4C6.20906@ericsson.com> Date: Thu, 19 Feb 2004 17:22:46 +0200 X-Sybari-Trust: b1f9ba55 c77f3eb6 1886a979 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping CC: Rohan Mahy , Dean Willis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Feb 2004 15:18:20.0843 (UTC) FILETIME=[9BD927B0:01C3F6FB] Content-Transfer-Encoding: 7bit Subject: [Sipping] Send your agenda requests Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, we will be elaborating the agenda for SIPPING shortly (the deadline for WG agendas is approaching). So, send me your agenda requests *now*. So far, this is what we have: http://www.softarmor.com/sipping/meets/ietf59/requests.html Regards, Gonzalo SIPPING co-chair This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 19 13:05:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00889 for ; Thu, 19 Feb 2004 13:05:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtsXN-0008Bi-8J for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 13:04:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JI4b5v031468 for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 13:04:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtsXN-0008BT-4Y for sipping-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 13:04:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00886 for ; Thu, 19 Feb 2004 13:04:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtsXL-0005SB-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 13:04:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtsWj-0005NO-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 13:03:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtsVv-0005FX-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 13:03:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtsVr-0007sR-2G; Thu, 19 Feb 2004 13:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtsVk-0007qU-PI for sipping@optimus.ietf.org; Thu, 19 Feb 2004 13:02:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00687 for ; Thu, 19 Feb 2004 13:02:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtsVi-0005DU-00 for sipping@ietf.org; Thu, 19 Feb 2004 13:02:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtsUc-00050X-00 for sipping@ietf.org; Thu, 19 Feb 2004 13:01:47 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtsSf-0004UG-00 for sipping@ietf.org; Thu, 19 Feb 2004 12:59:45 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1JHxCuA012447; Thu, 19 Feb 2004 09:59:13 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQK94307; Thu, 19 Feb 2004 09:59:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <64DA04B7-6305-11D8-9B6B-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: rohan@cisco.com From: Rohan Mahy Date: Thu, 19 Feb 2004 09:59:42 -0800 To: sipping X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Subject: [Sipping] updated dialog package Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Everyone, I've updated the dialog packages with the changes we agreed to in Minneapolis (removing CSeq and the Route-Set). I've also provided a detailed example of using the dialog package for a "shared-line" application. I apologize for my tardiness here. I was supposed to post something shortly after the meeting. I any case, I believe this demonstrates that the current syntax is at least sufficient for the use cases we've discussed. I would like to hear from all of you if this does the trick. many thanks, -rohan _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 19 13:59:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25854 for ; Thu, 19 Feb 2004 13:59:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AttNf-0007d6-Hy for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 13:58:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JIwdeB029327 for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 13:58:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AttNf-0007cv-Cz for sipping-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 13:58:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25381 for ; Thu, 19 Feb 2004 13:58:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AttNc-0000jm-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 13:58:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AttMk-0000f6-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 13:57:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AttMA-0000Zh-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 13:57:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AttM5-0007HE-5B; Thu, 19 Feb 2004 13:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AttLS-0007Ez-LL for sipping@optimus.ietf.org; Thu, 19 Feb 2004 13:56:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22991 for ; Thu, 19 Feb 2004 13:56:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AttLQ-0000Uj-00 for sipping@ietf.org; Thu, 19 Feb 2004 13:56:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AttKO-0000MT-00 for sipping@ietf.org; Thu, 19 Feb 2004 13:55:17 -0500 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 1AttJX-0000Hc-00; Thu, 19 Feb 2004 13:54:23 -0500 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i1JIsNk26508; Thu, 19 Feb 2004 10:54:23 -0800 (PST) Message-Id: <200402191854.i1JIsNk26508@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sipping@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 19 Feb 2004 10:54:23 -0800 Subject: [Sipping] RFC 3702 on Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3702 Title: Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP) Author(s): J. Loughney, G. Camarillo Status: Informational Date: February 2004 Mailbox: John.Loughney@nokia.com, Gonzalo.Camarillo@ericsson.com Pages: 15 Characters: 31243 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipping-aaa-req-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3702.txt As Session Initiation Protocol (SIP) services are deployed on the Internet, there is a need for authentication, authorization, and accounting of SIP sessions. This document sets out the basic requirements for this work. This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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.echo 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: <040219105247.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3702 --OtherAccess Content-Type: Message/External-body; name="rfc3702.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040219105247.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 19 13:59:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25892 for ; Thu, 19 Feb 2004 13:59:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AttNg-0007dc-6n for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 13:58:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JIwexh029354 for sipping-archive@odin.ietf.org; Thu, 19 Feb 2004 13:58:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AttNg-0007dL-2m for sipping-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 13:58:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25393 for ; Thu, 19 Feb 2004 13:58:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AttNd-0000js-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 13:58:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AttMl-0000fG-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 13:57:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AttMA-0000Zj-00 for sipping-web-archive@ietf.org; Thu, 19 Feb 2004 13:57:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AttM6-0007HO-0a; Thu, 19 Feb 2004 13:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AttLV-0007FC-7X for sipping@optimus.ietf.org; Thu, 19 Feb 2004 13:56:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23040 for ; Thu, 19 Feb 2004 13:56:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AttLS-0000V3-00 for sipping@ietf.org; Thu, 19 Feb 2004 13:56:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AttKS-0000N6-00 for sipping@ietf.org; Thu, 19 Feb 2004 13:55:21 -0500 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 1AttJa-0000Fh-00 for sipping@ietf.org; Thu, 19 Feb 2004 13:54:26 -0500 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1JIrUR12473; Thu, 19 Feb 2004 13:53:31 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1FN138KZ; Thu, 19 Feb 2004 13:53:31 -0500 Received: from nortelnetworks.com (acart1df.ca.nortel.com [47.129.129.91]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DBDZJJAH; Thu, 19 Feb 2004 13:53:31 -0500 Message-ID: <40350629.5020703@nortelnetworks.com> Date: Thu, 19 Feb 2004 13:53:29 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: =?UTF-8?B?7Zmp7KeE6rK9?= , Cullen Jennings , sipping Subject: Re: [Sipping] draft-hwang-sipping-infomidcall-00.txt References: <004701c3f443$c74d6470$71090693@ROMEO> <4030F410.1050801@dynamicsoft.com> In-Reply-To: <4030F410.1050801@dynamicsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04e.nortelnetworks.com id i1JIrUR12473 Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Mr. Wang is saying that they make money doing the services their way, whi= ch is=20 also possible using SIP. Your "SIP services model" is one business model= , but=20 others are possible and more in line with existing businesses. Jonathan Rosenberg wrote: > I agree that these services are needed. However, mechanisms are in plac= e=20 > today for performing these services. Call transfer is done with REFER,=20 > call waiting is a local feature on the device, and three way calling ca= n=20 > be done locally or through invocation of a centralized conferencing ser= ver. >=20 > In the SIp services model, all of these features do not live in a=20 > centralized server in the network. Rather, they are distributed, and=20 > implemented in the place most appropriate for that service. In an IP=20 > network, the endpoints have greater intelligence than in the PSTN.=20 > Having smarter endpoints means that you can have a better overall=20 > service experience and support a broader range of devices. >=20 > MGCP takes the position you are advocating, that the services all live=20 > in a centralized place. Cullen's point, I believe, is that, if the aim=20 > is to develop protocols to support a model of centralized service=20 > control, we already have that - mgcp. >=20 > Thanks, > Jonathan R. >=20 > =ED=99=A9=EC=A7=84=EA=B2=BD wrote: >=20 >> Thank you for the question. >> >> Your question is why network-based midcall is needed with SIP. >> >> My answer is that >> Since service components in the next gen IP network are based on SIP, >> the delivery of midcall information should be through SIP method. >> >> Simple INFO (from the SIP phone or from the MGC(by translation)) works= =20 >> very well, >> as we implemented trial services with this INFO midcall function both=20 >> in SIP phone and Softswitch. >> >> My proposal is that in standard SIP phone (UA) have midcall button=20 >> simply initiating INFO when the button is pressed. >> >> ------------------------------------------- >> Title: INFO Usage Examples for Network-based Mid-Call Service Author:=20 >> Jinkyung Hwang (KT) >> >> Abstract: >> >> This document describes the INFO usage examples for network based =20 >> mid-call service. Mid-call based services are for example, Call =20 >> Transfer, Call Waiting, and Three-Way Calling. Other possible mid- >> call services are useful and important, even more in IP multimedia = =20 >> network. The cases described in SIP service examples (draft-ietf- >> sipping-service-examples-05) are Terminal-basis. Since the service = =20 >> procedures are fixed in the Terminal, the features are not extensible.= =20 >> This document proposes network-based mid-call control mechanism with= =20 >> INFO and shows examples that simple mid-call request (INFO) from the= =20 >> Terminal, then the network application server provide various=20 >> mid-call services by prompting user through the Media Server,=20 >> according to the subscription information of the user. >> A URL for this draft is >> http://www.ietf.org/internet-drafts/draft-hwang-sipping-infomidcall-0= 0.txt=20 >> >> >> >> BR >> >> Jinkyung Hwang >> KT >> >> ----- Original Message ----- From: "Cullen Jennings" >> To: "sipping" >> Sent: Saturday, February 14, 2004 1:26 AM >> Subject: [Sipping] draft-hwang-sipping-infomidcall-00.txt >> >> >> >>> Why not just use MGCP instead of SIP if you want to do this. It=20 >>> will work >>> much better. >>> >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >>> J*ix&j)b bm?=0C0'~ffX)=DF=A3"8bX+=1FDY=D7=AFzZ)ayi'=1A*'=3DK=1E*b^= ?=1C%fin~-w.=C8=A9R=C7=AC++=1Dz(}+y"=0F >=20 >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 20 00:21:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17685 for ; Fri, 20 Feb 2004 00:21:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au35d-0002I8-Sl for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 00:20:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K5KfuS008802 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 00:20:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au35d-0002Ht-I5 for sipping-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 00:20:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17678 for ; Fri, 20 Feb 2004 00:20:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au35b-0002P8-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 00:20:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au34f-0002MI-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 00:19:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au349-0002JN-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 00:19:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au341-00026g-Ky; Fri, 20 Feb 2004 00:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au33e-000267-NC for sipping@optimus.ietf.org; Fri, 20 Feb 2004 00:18:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17625 for ; Fri, 20 Feb 2004 00:18:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au33c-0002IX-00 for sipping@ietf.org; Fri, 20 Feb 2004 00:18:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au32f-0002GY-00 for sipping@ietf.org; Fri, 20 Feb 2004 00:17:38 -0500 Received: from [209.116.120.7] (helo=tnint11.telogy.design.ti.com) by ietf-mx with esmtp (Exim 4.12) id 1Au31v-0002Cq-00 for sipping@ietf.org; Fri, 20 Feb 2004 00:16:51 -0500 Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19) id <1YH1PR1S>; Fri, 20 Feb 2004 00:15:03 -0500 Message-ID: <37A3C2F21006D611995100B0D0F9B73C04C3E408@tnint11.telogy.design.ti.com> From: "Scoggins, Sophia" To: "'sipping@ietf.org'" Date: Fri, 20 Feb 2004 00:15:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F770.7EA0C890" Subject: [Sipping] SIP Proxy servers -- security encryption protocol Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE autolearn=no version=2.60 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. ------_=_NextPart_001_01C3F770.7EA0C890 Content-Type: text/plain My group is looking for some security encryption protocol for both SIP and RTP streams for CPE. We were wondering what encryption protocol that most SIP proxy servers currently support or intend to support? Would you please just send your reply to me? Thanks. Regards, Sophia2@ti.com ------_=_NextPart_001_01C3F770.7EA0C890 Content-Type: text/html

 

My group is looking for some security encryption protocol for both SIP and RTP streams for CPE. We were wondering what encryption protocol that most SIP proxy servers currently support or intend to support? Would you please just send your reply to me?

 

Thanks.

 

Regards,

Sophia2@ti.com

------_=_NextPart_001_01C3F770.7EA0C890-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 20 00:31:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18495 for ; Fri, 20 Feb 2004 00:31:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3FQ-0003vv-K6 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 00:30:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K5UmZl015113 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 00:30:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3FQ-0003vg-FW for sipping-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 00:30:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18458 for ; Fri, 20 Feb 2004 00:30:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au3FN-0003PK-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 00:30:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au3EY-0003Lm-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 00:29:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au3Di-0003HU-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 00:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3Di-0003kQ-S3; Fri, 20 Feb 2004 00:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3DV-0003k2-5G for sipping@optimus.ietf.org; Fri, 20 Feb 2004 00:28:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18348 for ; Fri, 20 Feb 2004 00:28:45 -0500 (EST) From: ranjit.avasarala@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au3DS-0003GU-00 for sipping@ietf.org; Fri, 20 Feb 2004 00:28:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au3Cq-0003Cq-00 for sipping@ietf.org; Fri, 20 Feb 2004 00:28:09 -0500 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1Au3CE-00032G-00 for sipping@ietf.org; Fri, 20 Feb 2004 00:27:31 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i1K5QvKA002279 for ; Fri, 20 Feb 2004 10:56:57 +0530 (IST) Received: from blr-ec-bh3.wipro.com ([10.200.50.93]) by ec-vwall-wd with InterScan Messaging Security Suite; Fri, 20 Feb 2004 10:58:49 +0530 Received: from blr-ec-msg03.wipro.com ([10.200.52.99]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 Feb 2004 10:56:55 +0530 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F772.278FEFF8" Subject: RE: [Sipping] SIP Proxy servers -- security encryption protocol Date: Fri, 20 Feb 2004 10:56:55 +0530 Message-ID: Thread-Topic: [Sipping] SIP Proxy servers -- security encryption protocol Thread-Index: AcP3cUZhr/EU6Uv0StSv9DIAehczYAAAYafw To: , X-OriginalArrivalTime: 20 Feb 2004 05:26:55.0983 (UTC) FILETIME=[27A2F7F0:01C3F772] Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F772.278FEFF8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi For secured transactions you could use TLS i.e using sips: instead of normal sip: url. Alternatively IPSec also could be used at IP Layer and for RTP security you could use SRTP (draft-ietf-avt-srtp-09.txt) protocol. =20 Regards Ranjit -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Scoggins, Sophia Sent: Friday, February 20, 2004 10:45 AM To: 'sipping@ietf.org' Subject: [Sipping] SIP Proxy servers -- security encryption protocol =20 My group is looking for some security encryption protocol for both SIP and RTP streams for CPE. We were wondering what encryption protocol that most SIP proxy servers currently support or intend to support? Would you please just send your reply to me? =20 Thanks. =20 Regards, Sophia2@ti.com ------_=_NextPart_001_01C3F772.278FEFF8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi
    For secured transactions you could use TLS = i.e using=20 sips: instead of normal sip: url.
Alternatively IPSec also could be used at IP = Layer
and=20 for RTP security you could use SRTP (draft-ietf-avt-srtp-09.txt)=20 protocol.
 
Regards
Ranjit
-----Original Message-----
From:=20 sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of = Scoggins, Sophia
Sent: Friday, February 20, 2004 10:45=20 AM
To: 'sipping@ietf.org'
Subject: [Sipping] SIP = Proxy=20 servers -- security encryption protocol

 

My group is looking for = some=20 security encryption protocol for both SIP and RTP streams for CPE. We = were=20 wondering what encryption protocol that most SIP proxy servers = currently=20 support or intend to support? Would you please just send your reply to = me?

 

Thanks.

 

Regards,

Sophia2@ti.com

------_=_NextPart_001_01C3F772.278FEFF8-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 20 00:46:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19100 for ; Fri, 20 Feb 2004 00:46:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3Ts-0005CB-1J for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 00:46:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K5jhFY019955 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 00:45:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3Tr-0005Bj-Rt for sipping-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 00:45:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19073 for ; Fri, 20 Feb 2004 00:45:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au3Tp-0004Pc-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 00:45:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au3Sv-0004MD-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 00:44:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au3SE-0004Iy-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 00:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3SD-0004zk-Tr; Fri, 20 Feb 2004 00:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3Rs-0004zA-VT for sipping@optimus.ietf.org; Fri, 20 Feb 2004 00:43:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19039 for ; Fri, 20 Feb 2004 00:43:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au3Rq-0004ID-00 for sipping@ietf.org; Fri, 20 Feb 2004 00:43:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au3Qs-0004GH-00 for sipping@ietf.org; Fri, 20 Feb 2004 00:42:39 -0500 Received: from [209.116.120.7] (helo=tnint11.telogy.design.ti.com) by ietf-mx with esmtp (Exim 4.12) id 1Au3Qi-0004EL-00 for sipping@ietf.org; Fri, 20 Feb 2004 00:42:28 -0500 Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19) id <1YH1PRH5>; Fri, 20 Feb 2004 00:40:40 -0500 Message-ID: <37A3C2F21006D611995100B0D0F9B73C04C3E40A@tnint11.telogy.design.ti.com> From: "Scoggins, Sophia" To: "'sipping@ietf.org'" Date: Fri, 20 Feb 2004 00:40:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F774.1290C390" Subject: [Sipping] VoIP (SIP) Outsourcing opportunities Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE autolearn=no version=2.60 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. ------_=_NextPart_001_01C3F774.1290C390 Content-Type: text/plain If this is not a proper place to post this email, I apologize. I am with the Broadband Communications group at Texas Instruments. My group is developing VoIP products (IP phones and small media gateways) using SIP. We have a VoIP project that we are looking for outsourcing to a VoIP experienced company in the U.S. (U.S. only, please). If you are interested, please contact me. Thanks. Regards, Sophia2@ti.com ------_=_NextPart_001_01C3F774.1290C390 Content-Type: text/html

If this is not a proper place to post this email, I apologize.

 

I am with the Broadband Communications group at Texas Instruments. My group is developing VoIP products (IP phones and small media gateways) using SIP. We have a VoIP project that we are looking for outsourcing to a VoIP experienced company in the U.S. (U.S. only, please). If you are interested, please contact me. Thanks.

 

 

Regards,

Sophia2@ti.com

 

------_=_NextPart_001_01C3F774.1290C390-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 20 05:10:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13427 for ; Fri, 20 Feb 2004 05:10:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au7bT-0001Ah-4Y for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 05:09:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KA9p3j004502 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 05:09:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au7bS-0001AX-I4 for sipping-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 05:09:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13390 for ; Fri, 20 Feb 2004 05:09:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au7bP-0000WS-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 05:09:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au7aT-0000SM-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 05:08:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au7Zj-0000PY-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 05:08:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au7Zh-0000nW-Le; Fri, 20 Feb 2004 05:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au7ZU-0000kO-Rc for sipping@optimus.ietf.org; Fri, 20 Feb 2004 05:07:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13333 for ; Fri, 20 Feb 2004 05:07:45 -0500 (EST) From: Miguel.An.Garcia@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au7ZR-0000OO-00 for sipping@ietf.org; Fri, 20 Feb 2004 05:07:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au7YV-0000Lu-00 for sipping@ietf.org; Fri, 20 Feb 2004 05:06:47 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Au7Xm-0000Jk-00 for sipping@ietf.org; Fri, 20 Feb 2004 05:06:02 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1KA60K09235; Fri, 20 Feb 2004 12:06:00 +0200 (EET) X-Scanned: Fri, 20 Feb 2004 12:05:54 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i1KA5sjs003022; Fri, 20 Feb 2004 12:05:54 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00OHxlAH; Fri, 20 Feb 2004 12:05:52 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1KA5k710913; Fri, 20 Feb 2004 12:05:46 +0200 (EET) Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 20 Feb 2004 12:05:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Feb 2004 12:05:39 +0200 Message-ID: <357AEC66DB509A4EA46CB85D7968B6AF467535@esebe006.ntc.nokia.com> Thread-Topic: event in draft-olson-sipping-refer-extensions-01 Thread-Index: AcP3mRgBklapsVzHSFW06XTj2FVPvg== To: , Cc: X-OriginalArrivalTime: 20 Feb 2004 10:05:40.0949 (UTC) FILETIME=[187E4050:01C3F799] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] event in draft-olson-sipping-refer-extensions-01 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi: One of the more cofusing things I found this draft is related to how the = subscribed event is selected in the REFER request. I believe that we want to explicitly indicate to the REFER-Recipient = which event the REFER-Issuer wants to subscribe to. We may want to = indicate also which events and formats are supported. If we mimic the SUBSCRIBE behaviour, the event of the subscription is = indicated in an Event header. The supported events are indicated in the = Allow-events header. As for the format, you have the Accept header, as = you point out in the draft. So my question is: Have you consider to import the Event and = Allow-events header in the extended REFER? /Miguel --- Miguel A. Garcia tel:+358-50-4804586 =20 Nokia Research Center Helsinki, Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 20 09:47:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24262 for ; Fri, 20 Feb 2004 09:47:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuBvg-0007C7-S9 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 09:47:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KEl0vn027651 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 09:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuBvg-0007Bu-Mz for sipping-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 09:47:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24253 for ; Fri, 20 Feb 2004 09:46:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuBve-0005Ao-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 09:46:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuBuf-00057j-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 09:45:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuBtu-00055G-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 09:45:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuBtm-0006vB-Mj; Fri, 20 Feb 2004 09:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuBsn-0006th-4Y for sipping@optimus.ietf.org; Fri, 20 Feb 2004 09:44:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24174 for ; Fri, 20 Feb 2004 09:43:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuBsl-00051N-00 for sipping@ietf.org; Fri, 20 Feb 2004 09:43:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuBrl-0004z8-00 for sipping@ietf.org; Fri, 20 Feb 2004 09:42:57 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1AuBr6-0004ub-00 for sipping@ietf.org; Fri, 20 Feb 2004 09:42:16 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 20 Feb 2004 06:43:39 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1KEfh0K014861; Fri, 20 Feb 2004 09:41:44 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-118.cisco.com [64.100.229.118]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AXD08942; Fri, 20 Feb 2004 06:41:43 -0800 (PST) Message-Id: <4.3.2.7.2.20040220093002.00b283f0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Feb 2004 09:41:42 -0500 To: Mpierce1@aol.com From: Michael Hammer Subject: Re: [Sipping] Re: sos - dead or alive Cc: jgunn6@csc.com, hgs@cs.columbia.edu, sipping@ietf.org In-Reply-To: <3d.3ae4ae03.2d661c31@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 09:03 AM 2/19/2004 -0500, Mpierce1@aol.com wrote: >In a message dated 2/19/2004 1:58:18 AM Eastern Standard Time, >jgunn6@csc.com writes: > > >>So any kind of regular, scheduled test should be designed so it does NOT >>tie up the operators. > >I believe the test must be devised so that it does not involve the >emergency center or any of the equipment directly supporting the emergency >center at all. > >Mike Then there is not much point in doing any test. As Brian points out, the question is how do you stage these reachability tests so that they scale, ie. you don't have millions of users pinging the ECC directly. But, instead of the proxies pinging the ECC, which might reduce the load, but might not make the burstiness more deterministic, perhaps a presence subscription would be more appropriate. The proxies could subscribe to the presence of the ECC, and the ECC could periodically Notify those proxies that it is still there and able to receive calls. The ECC could then control the scheduling and load distribution for sending the Notifies. Failing to receive the notifications beyond some interval could provide an indication that something is wrong and trigger an inquiry. You might even be able to extend this to the users, where emergency help is a "buddy" you subscribe to on the local proxy. I haven't thought this through, but thought I'd throw that out. Mike H. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 20 10:05:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25256 for ; Fri, 20 Feb 2004 10:05:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuCD9-00032F-8Y for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 10:05:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KF53oV011661 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 10:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuCD8-000320-WA for sipping-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 10:05:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25174 for ; Fri, 20 Feb 2004 10:04:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuCD6-0006J1-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 10:05:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuCC7-0006EF-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 10:03:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuCBF-0006B4-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 10:03:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuCBC-0001kK-VN; Fri, 20 Feb 2004 10:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuCB6-0001gz-HW for sipping@optimus.ietf.org; Fri, 20 Feb 2004 10:02:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25000 for ; Fri, 20 Feb 2004 10:02:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuCB4-00069v-00 for sipping@ietf.org; Fri, 20 Feb 2004 10:02:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuCA7-00065w-00 for sipping@ietf.org; Fri, 20 Feb 2004 10:01:55 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AuC9B-00060z-00 for sipping@ietf.org; Fri, 20 Feb 2004 10:00:57 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1KF0OmR008298; Fri, 20 Feb 2004 10:00:24 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1KF0Mc19281; Fri, 20 Feb 2004 10:00:22 -0500 Message-ID: <4036210A.4050900@cs.columbia.edu> Date: Fri, 20 Feb 2004 10:00:26 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: Mpierce1@aol.com, jgunn6@csc.com, sipping@ietf.org Subject: Re: [Sipping] Re: sos - dead or alive References: <4.3.2.7.2.20040220093002.00b283f0@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20040220093002.00b283f0@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think there are five goals, somewhat contradictory: (1) make it as realistic as possible, to make sure you are really testing the emergency calling system, not the testing system; after all, the fire safety officer doesn't go around ringing a cowbell instead of the real fire alarms. (2) do not impose any additional operator involvement; this is solved by the OPTIONS mechanism proposed; (3) allow for reasonable scaling; (4) avoid interfering with real emergency calls (5) allow user on-demand testing. With the proxy-based testing I proposed, we get very close to all goals. In the worst case, i.e., every device does this once a day, we get roughly 100 million calls a day in the US, or 1157/second. That's about 10 proxy servers worth of equipment, i.e., about $20k. This hardly seems worth spending inordinate engineering resources on avoiding, particularly since the likely load is going to be lower by probably a factor of 1000 or more (I'm assuming that most residential users will use a cable or DSL provider for this, for example). With even a few hundred systems, you'll get almost perfect smoothing and very little burstiness. I know protocol design is fun, but I'm very worried about adding complexity to solve largely a non-problem. Michael Hammer wrote: > At 09:03 AM 2/19/2004 -0500, Mpierce1@aol.com wrote: > >> In a message dated 2/19/2004 1:58:18 AM Eastern Standard Time, >> jgunn6@csc.com writes: >> >> >>> So any kind of regular, scheduled test should be designed so it does >>> NOT >>> tie up the operators. >> >> >> I believe the test must be devised so that it does not involve the >> emergency center or any of the equipment directly supporting the >> emergency center at all. >> >> Mike > > > Then there is not much point in doing any test. As Brian points out, > the question is how do you stage these reachability tests so that they > scale, ie. you don't have millions of users pinging the ECC directly. > But, instead of the proxies pinging the ECC, which might reduce the > load, but might not make the burstiness more deterministic, perhaps a > presence subscription would be more appropriate. The proxies could > subscribe to the presence of the ECC, and the ECC could periodically > Notify those proxies that it is still there and able to receive calls. > The ECC could then control the scheduling and load distribution for > sending the Notifies. Failing to receive the notifications beyond some > interval could provide an indication that something is wrong and trigger > an inquiry. You might even be able to extend this to the users, where > emergency help is a "buddy" you subscribe to on the local proxy. I > haven't thought this through, but thought I'd throw that out. > > Mike H. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 20 10:05:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25268 for ; Fri, 20 Feb 2004 10:05:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuCD9-00032X-Pp for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 10:05:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KF53Mr011679 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 10:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuCD9-00032I-MV for sipping-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 10:05:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25178 for ; Fri, 20 Feb 2004 10:04:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuCD7-0006J6-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 10:05:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuCC7-0006EO-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 10:04:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuCBF-0006B5-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 10:03:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuCBE-0001l8-16; Fri, 20 Feb 2004 10:03:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuCB7-0001hS-S6 for sipping@optimus.ietf.org; Fri, 20 Feb 2004 10:02:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25007 for ; Fri, 20 Feb 2004 10:02:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuCB5-0006A6-00 for sipping@ietf.org; Fri, 20 Feb 2004 10:02:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuCAC-00066b-00 for sipping@ietf.org; Fri, 20 Feb 2004 10:02:01 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AuC9L-0005yl-00 for sipping@ietf.org; Fri, 20 Feb 2004 10:01:07 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCQW4T>; Fri, 20 Feb 2004 10:00:37 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6433@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Michael Hammer'" , Mpierce1@aol.com Cc: jgunn6@csc.com, hgs@cs.columbia.edu, sipping@ietf.org Subject: RE: [Sipping] Re: sos - dead or alive Date: Fri, 20 Feb 2004 10:00:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I think Hennings idea is the gem of the answer. Assume that there are a couple of proxies between you and the ERC. If the proxy closest to the ERC assures itself that it can reach the ERC, then it can assure any proxy that routes through it to the ERC that it can reach the ERC without the second level proxy having to actually touch the ERC itself. Repeat as necessary. That scales better than having each UA doing something that results in messages hitting the ERC itself. There is no explicit mechanism in SIP to do this. It could be a Notify against some kind of event package we define It could be a kind of presence subscription It could be a kind of INVITE that returns a new error code It could be a new method that returns a new response code When considering what the best mechanism is, remember that you have a URI of the ERC, but you don't have a URI to an intermediate proxy. We could figure out how to get you one. The question you are asking is "If I sent a (real) INVITE to this URI, would it get there?" If you are subscribing to something, how do you know what to subscribe to? Brian > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Friday, February 20, 2004 9:42 AM > To: Mpierce1@aol.com > Cc: jgunn6@csc.com; hgs@cs.columbia.edu; sipping@ietf.org > Subject: Re: [Sipping] Re: sos - dead or alive > > > At 09:03 AM 2/19/2004 -0500, Mpierce1@aol.com wrote: > >In a message dated 2/19/2004 1:58:18 AM Eastern Standard Time, > >jgunn6@csc.com writes: > > > > > >>So any kind of regular, scheduled test should be designed > so it does NOT > >>tie up the operators. > > > >I believe the test must be devised so that it does not involve the > >emergency center or any of the equipment directly supporting > the emergency > >center at all. > > > >Mike > > Then there is not much point in doing any test. As Brian > points out, the > question is how do you stage these reachability tests so that > they scale, > ie. you don't have millions of users pinging the ECC directly. But, > instead of the proxies pinging the ECC, which might reduce > the load, but > might not make the burstiness more deterministic, perhaps a presence > subscription would be more appropriate. The proxies could > subscribe to the > presence of the ECC, and the ECC could periodically Notify > those proxies > that it is still there and able to receive calls. The ECC could then > control the scheduling and load distribution for sending the > Notifies. Failing to receive the notifications beyond some > interval could > provide an indication that something is wrong and trigger an > inquiry. You > might even be able to extend this to the users, where > emergency help is a > "buddy" you subscribe to on the local proxy. I haven't thought this > through, but thought I'd throw that out. > > Mike H. > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 20 10:47:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29224 for ; Fri, 20 Feb 2004 10:47:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuCrs-0003KH-Fl for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 10:47:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KFl8Be012779 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 10:47:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuCrs-0003K2-AW for sipping-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 10:47:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29202 for ; Fri, 20 Feb 2004 10:47:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuCrp-00035F-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 10:47:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuCqr-00030m-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 10:46:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuCpy-0002x6-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 10:45:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuCpr-00035J-O2; Fri, 20 Feb 2004 10:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuCp3-00031w-CJ for sipping@optimus.ietf.org; Fri, 20 Feb 2004 10:44:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29125 for ; Fri, 20 Feb 2004 10:44:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuCp0-0002sU-00 for sipping@ietf.org; Fri, 20 Feb 2004 10:44:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuCo6-0002ns-00 for sipping@ietf.org; Fri, 20 Feb 2004 10:43:15 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1AuCnI-0002ex-00 for sipping@ietf.org; Fri, 20 Feb 2004 10:42:24 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 20 Feb 2004 07:40:53 -0800 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 i1KFfmT4016976; Fri, 20 Feb 2004 10:41:49 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-118.cisco.com [64.100.229.118]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AXD14106; Fri, 20 Feb 2004 07:41:47 -0800 (PST) Message-Id: <4.3.2.7.2.20040220103319.02fbf370@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Feb 2004 10:41:45 -0500 To: Henning Schulzrinne From: Michael Hammer Subject: Re: [Sipping] Re: sos - dead or alive Cc: Mpierce1@aol.com, jgunn6@csc.com, sipping@ietf.org In-Reply-To: <4036210A.4050900@cs.columbia.edu> References: <4.3.2.7.2.20040220093002.00b283f0@cia.cisco.com> <4.3.2.7.2.20040220093002.00b283f0@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Henning, The reality of deployment would be that every ECC would have it's own proxy, so that would be more like 1000 x $2k = $2 million. But, the corresponding distribution of load across those servers means it is even more of a non-problem at any given site. One question: A real successful test to a wrong ECC doesn't buy you much. I hope that mobility is addressed in the solution as well. Many of those 100 million phones are mobile, which might become SIP-based some time in the future. so I would add a 6) "works with mobile terminals" to your list below. Mike At 10:00 AM 2/20/2004 -0500, Henning Schulzrinne wrote: >I think there are five goals, somewhat contradictory: > >(1) make it as realistic as possible, to make sure you are really testing >the emergency calling system, not the testing system; after all, the fire >safety officer doesn't go around ringing a cowbell instead of the real >fire alarms. > >(2) do not impose any additional operator involvement; this is solved by >the OPTIONS mechanism proposed; > >(3) allow for reasonable scaling; > >(4) avoid interfering with real emergency calls > >(5) allow user on-demand testing. > >With the proxy-based testing I proposed, we get very close to all goals. >In the worst case, i.e., every device does this once a day, we get roughly >100 million calls a day in the US, or 1157/second. That's about 10 proxy >servers worth of equipment, i.e., about $20k. This hardly seems worth >spending inordinate engineering resources on avoiding, particularly since >the likely load is going to be lower by probably a factor of 1000 or more >(I'm assuming that most residential users will use a cable or DSL provider >for this, for example). > >With even a few hundred systems, you'll get almost perfect smoothing and >very little burstiness. > >I know protocol design is fun, but I'm very worried about adding >complexity to solve largely a non-problem. > >Michael Hammer wrote: > >>At 09:03 AM 2/19/2004 -0500, Mpierce1@aol.com wrote: >> >>>In a message dated 2/19/2004 1:58:18 AM Eastern Standard Time, >>>jgunn6@csc.com writes: >>> >>> >>>>So any kind of regular, scheduled test should be designed so it does >>>>NOT >>>>tie up the operators. >>> >>> >>>I believe the test must be devised so that it does not involve the >>>emergency center or any of the equipment directly supporting the >>>emergency center at all. >>> >>>Mike >> >>Then there is not much point in doing any test. As Brian points out, the >>question is how do you stage these reachability tests so that they scale, >>ie. you don't have millions of users pinging the ECC directly. >>But, instead of the proxies pinging the ECC, which might reduce the load, >>but might not make the burstiness more deterministic, perhaps a presence >>subscription would be more appropriate. The proxies could subscribe to >>the presence of the ECC, and the ECC could periodically Notify those >>proxies that it is still there and able to receive calls. >>The ECC could then control the scheduling and load distribution for >>sending the Notifies. Failing to receive the notifications beyond some >>interval could provide an indication that something is wrong and trigger >>an inquiry. You might even be able to extend this to the users, where >>emergency help is a "buddy" you subscribe to on the local proxy. I >>haven't thought this through, but thought I'd throw that out. >>Mike H. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 20 12:05:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02058 for ; Fri, 20 Feb 2004 12:05:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuE5Z-0002Nh-4i for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 12:05:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KH5Lcm009152 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 12:05:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuE5Y-0002NX-Tv for sipping-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 12:05:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02004 for ; Fri, 20 Feb 2004 12:05:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuE5X-0000Ct-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 12:05:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuE4f-00005b-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 12:04:25 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AuE3P-0007iz-01 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 12:03:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AuDrw-0001dJ-QP for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 11:51:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDrj-0000m5-Ro; Fri, 20 Feb 2004 11:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDqm-0000ee-6w for sipping@optimus.ietf.org; Fri, 20 Feb 2004 11:50:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01464 for ; Fri, 20 Feb 2004 11:50:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuDql-00078O-00 for sipping@ietf.org; Fri, 20 Feb 2004 11:50:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuDpo-00075J-00 for sipping@ietf.org; Fri, 20 Feb 2004 11:49:05 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AuDpO-00072K-00 for sipping@ietf.org; Fri, 20 Feb 2004 11:48:38 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Feb 2004 08:47:49 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 20 Feb 2004 08:48:01 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Feb 2004 08:48:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Feb 2004 08:48:20 -0800 Message-ID: Thread-Topic: event in draft-olson-sipping-refer-extensions-01 Thread-Index: AcP3mRgBklapsVzHSFW06XTj2FVPvgANou6Q From: "Orit Levin" To: , "Sean Olson" Cc: X-OriginalArrivalTime: 20 Feb 2004 16:48:12.0860 (UTC) FILETIME=[542767C0:01C3F7D1] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: event in draft-olson-sipping-refer-extensions-01 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The draft is more a requirements draft (i.e. SIPPING) rather than the mechanism. I totally agree that the event specification needs much better definition and re-using SUBSCRIBE syntax makes a lot of sense to me. I would also like to hear comments what of the extensions proposed in the draft we really need and want to promote towards SIP. In my opinion, out of all the extensions, the implicit "extended" subscription is the most questionable. Thanks, Orit. -----Original Message----- From: Miguel.An.Garcia@nokia.com [mailto:Miguel.An.Garcia@nokia.com]=20 Sent: Friday, February 20, 2004 2:06 AM To: Sean Olson; Orit Levin Cc: sipping@ietf.org Subject: event in draft-olson-sipping-refer-extensions-01 Hi: One of the more cofusing things I found this draft is related to how the subscribed event is selected in the REFER request. I believe that we want to explicitly indicate to the REFER-Recipient which event the REFER-Issuer wants to subscribe to. We may want to indicate also which events and formats are supported. If we mimic the SUBSCRIBE behaviour, the event of the subscription is indicated in an Event header. The supported events are indicated in the Allow-events header. As for the format, you have the Accept header, as you point out in the draft. So my question is: Have you consider to import the Event and Allow-events header in the extended REFER? /Miguel --- Miguel A. Garcia tel:+358-50-4804586 =20 Nokia Research Center Helsinki, Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 20 13:37:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05694 for ; Fri, 20 Feb 2004 13:37:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFWL-00020V-KN for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 13:37:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KIb5Io007697 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 13:37:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFWK-0001zu-QQ for sipping-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 13:37:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05673 for ; Fri, 20 Feb 2004 13:37:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuFWI-0006Mm-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 13:37:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuFVN-0006Is-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 13:36:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuFUQ-0006Fa-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 13:35:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFUL-0001jo-J2; Fri, 20 Feb 2004 13:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFTS-0001hW-E3 for sipping@optimus.ietf.org; Fri, 20 Feb 2004 13:34:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05557 for ; Fri, 20 Feb 2004 13:34:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuFTQ-0006BS-00 for sipping@ietf.org; Fri, 20 Feb 2004 13:34:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuFSU-000685-00 for sipping@ietf.org; Fri, 20 Feb 2004 13:33:06 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AuFRj-00062f-00 for sipping@ietf.org; Fri, 20 Feb 2004 13:32:19 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCQ85Y>; Fri, 20 Feb 2004 13:31:49 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6442@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henry Sinnreich'" Cc: "'sipping@ietf.org'" Date: Fri, 20 Feb 2004 13:31:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] Language Preference in draft-sinnreich-sipdev-req-03.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 International-1, language support: SIP devices SHOULD indicate the preferred language using SIP Caller Preferences. The setting for this header MUST be provisioned. Might this be expanded a bit? The MUST be provisioned implies you can't have a UI choice. Maybe a default must be provisioned. Please could we also have a note that this choice may be used to guide how the call is answered as well as affect text on a UI. Imagine a call center with some bilingual call takers. Language preference might guide which call taker got the call. Clearly it would also guide how softkeys were labeled, what announcements were played, etc. I'd actually like to see the first SHOULD be a MUST. Emergency calls, in particular, need to be routed to someone who can actually communicate with the caller. Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 20 14:09:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07080 for ; Fri, 20 Feb 2004 14:09:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuG1U-0005bM-K6 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 14:09:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KJ9Ga2021526 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 14:09:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuG1U-0005b7-G5 for sipping-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 14:09:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07067 for ; Fri, 20 Feb 2004 14:09:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuG1S-0000nT-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 14:09:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuG0S-0000jq-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 14:08:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuFzs-0000ge-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 14:07:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFzJ-00057K-DC; Fri, 20 Feb 2004 14:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFyP-000556-Di for sipping@optimus.ietf.org; Fri, 20 Feb 2004 14:06:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06964 for ; Fri, 20 Feb 2004 14:06:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuFyN-0000cP-00 for sipping@ietf.org; Fri, 20 Feb 2004 14:06:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuFxZ-0000ZW-00 for sipping@ietf.org; Fri, 20 Feb 2004 14:05:13 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1AuFwp-0000S5-00 for sipping@ietf.org; Fri, 20 Feb 2004 14:04:27 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 20 Feb 2004 11:02:53 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1KJ3s0K005274; Fri, 20 Feb 2004 14:03:55 -0500 (EST) Received: from cisco.com ([161.44.79.87]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGF01539; Fri, 20 Feb 2004 14:03:54 -0500 (EST) Message-ID: <40365A1A.5030102@cisco.com> Date: Fri, 20 Feb 2004 14:03:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: Henning Schulzrinne , Mpierce1@aol.com, jgunn6@csc.com, sipping@ietf.org Subject: Re: [Sipping] Re: sos - dead or alive References: <4.3.2.7.2.20040220093002.00b283f0@cia.cisco.com> <4.3.2.7.2.20040220093002.00b283f0@cia.cisco.com> <4.3.2.7.2.20040220103319.02fbf370@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The mobile issue is interesting. I would think that a mobile phone might want to test connectivity every time it moved into a different geographical area, or every time it roamed to a cell under different administration. That could up the load considerably. Paul Michael Hammer wrote: > Henning, > > The reality of deployment would be that every ECC would have it's own > proxy, so that would be more like 1000 x $2k = $2 million. But, the > corresponding distribution of load across those servers means it is even > more of a non-problem at any given site. > > One question: A real successful test to a wrong ECC doesn't buy you > much. I hope that mobility is addressed in the solution as well. Many > of those 100 million phones are mobile, which might become SIP-based > some time in the future. so I would add a 6) "works with mobile > terminals" to your list below. > > Mike > > At 10:00 AM 2/20/2004 -0500, Henning Schulzrinne wrote: > >> I think there are five goals, somewhat contradictory: >> >> (1) make it as realistic as possible, to make sure you are really >> testing the emergency calling system, not the testing system; after >> all, the fire safety officer doesn't go around ringing a cowbell >> instead of the real fire alarms. >> >> (2) do not impose any additional operator involvement; this is solved >> by the OPTIONS mechanism proposed; >> >> (3) allow for reasonable scaling; >> >> (4) avoid interfering with real emergency calls >> >> (5) allow user on-demand testing. >> >> With the proxy-based testing I proposed, we get very close to all >> goals. In the worst case, i.e., every device does this once a day, we >> get roughly 100 million calls a day in the US, or 1157/second. That's >> about 10 proxy servers worth of equipment, i.e., about $20k. This >> hardly seems worth spending inordinate engineering resources on >> avoiding, particularly since the likely load is going to be lower by >> probably a factor of 1000 or more (I'm assuming that most residential >> users will use a cable or DSL provider for this, for example). >> >> With even a few hundred systems, you'll get almost perfect smoothing >> and very little burstiness. >> >> I know protocol design is fun, but I'm very worried about adding >> complexity to solve largely a non-problem. >> >> Michael Hammer wrote: >> >>> At 09:03 AM 2/19/2004 -0500, Mpierce1@aol.com wrote: >>> >>>> In a message dated 2/19/2004 1:58:18 AM Eastern Standard Time, >>>> jgunn6@csc.com writes: >>>> >>>> >>>>> So any kind of regular, scheduled test should be designed so it does >>>>> NOT >>>>> tie up the operators. >>>> >>>> >>>> >>>> I believe the test must be devised so that it does not involve the >>>> emergency center or any of the equipment directly supporting the >>>> emergency center at all. >>>> >>>> Mike >>> >>> >>> Then there is not much point in doing any test. As Brian points out, >>> the question is how do you stage these reachability tests so that >>> they scale, ie. you don't have millions of users pinging the ECC >>> directly. >>> But, instead of the proxies pinging the ECC, which might reduce the >>> load, but might not make the burstiness more deterministic, perhaps a >>> presence subscription would be more appropriate. The proxies could >>> subscribe to the presence of the ECC, and the ECC could periodically >>> Notify those proxies that it is still there and able to receive calls. >>> The ECC could then control the scheduling and load distribution for >>> sending the Notifies. Failing to receive the notifications beyond >>> some interval could provide an indication that something is wrong and >>> trigger an inquiry. You might even be able to extend this to the >>> users, where emergency help is a "buddy" you subscribe to on the >>> local proxy. I haven't thought this through, but thought I'd throw >>> that out. >>> Mike H. >> > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 20 14:16:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07520 for ; Fri, 20 Feb 2004 14:16:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuG87-0006IN-M6 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 14:16:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KJG7Fi024193 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 14:16:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuG87-0006I8-Ie for sipping-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 14:16:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07482 for ; Fri, 20 Feb 2004 14:16:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuG84-0001GJ-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 14:16:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuG76-0001CG-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 14:15:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuG6B-00018R-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 14:14:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuG66-0005xs-25; Fri, 20 Feb 2004 14:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuG5Q-0005uR-TB for sipping@optimus.ietf.org; Fri, 20 Feb 2004 14:13:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07326 for ; Fri, 20 Feb 2004 14:13:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuG5O-00015F-00 for sipping@ietf.org; Fri, 20 Feb 2004 14:13:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuG4Y-00011B-00 for sipping@ietf.org; Fri, 20 Feb 2004 14:12:27 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AuG48-0000wL-00 for sipping@ietf.org; Fri, 20 Feb 2004 14:12:00 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCQ0KL>; Fri, 20 Feb 2004 14:11:30 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6443@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" , Michael Hammer Cc: Henning Schulzrinne , Mpierce1@aol.com, jgunn6@csc.com, sipping@ietf.org Subject: RE: [Sipping] Re: sos - dead or alive Date: Fri, 20 Feb 2004 14:11:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Depending on how we end up implementing routing to the correct ERC, the service boundary information will be available to either the UA or a proxy. When the mobile device roams beyond the boundary, it could trigger a new test. Agree that it would up the load. Not clear that it will make a tremendous increase, especially if Henning's idea prevails. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, February 20, 2004 2:04 PM > To: Michael Hammer > Cc: Henning Schulzrinne; Mpierce1@aol.com; jgunn6@csc.com; > sipping@ietf.org > Subject: Re: [Sipping] Re: sos - dead or alive > > > The mobile issue is interesting. I would think that a mobile > phone might > want to test connectivity every time it moved into a different > geographical area, or every time it roamed to a cell under different > administration. That could up the load considerably. > > Paul > > Michael Hammer wrote: > > Henning, > > > > The reality of deployment would be that every ECC would > have it's own > > proxy, so that would be more like 1000 x $2k = $2 million. > But, the > > corresponding distribution of load across those servers > means it is even > > more of a non-problem at any given site. > > > > One question: A real successful test to a wrong ECC > doesn't buy you > > much. I hope that mobility is addressed in the solution as > well. Many > > of those 100 million phones are mobile, which might become > SIP-based > > some time in the future. so I would add a 6) "works with mobile > > terminals" to your list below. > > > > Mike > > > > At 10:00 AM 2/20/2004 -0500, Henning Schulzrinne wrote: > > > >> I think there are five goals, somewhat contradictory: > >> > >> (1) make it as realistic as possible, to make sure you are really > >> testing the emergency calling system, not the testing > system; after > >> all, the fire safety officer doesn't go around ringing a cowbell > >> instead of the real fire alarms. > >> > >> (2) do not impose any additional operator involvement; > this is solved > >> by the OPTIONS mechanism proposed; > >> > >> (3) allow for reasonable scaling; > >> > >> (4) avoid interfering with real emergency calls > >> > >> (5) allow user on-demand testing. > >> > >> With the proxy-based testing I proposed, we get very close to all > >> goals. In the worst case, i.e., every device does this > once a day, we > >> get roughly 100 million calls a day in the US, or > 1157/second. That's > >> about 10 proxy servers worth of equipment, i.e., about $20k. This > >> hardly seems worth spending inordinate engineering resources on > >> avoiding, particularly since the likely load is going to > be lower by > >> probably a factor of 1000 or more (I'm assuming that most > residential > >> users will use a cable or DSL provider for this, for example). > >> > >> With even a few hundred systems, you'll get almost perfect > smoothing > >> and very little burstiness. > >> > >> I know protocol design is fun, but I'm very worried about adding > >> complexity to solve largely a non-problem. > >> > >> Michael Hammer wrote: > >> > >>> At 09:03 AM 2/19/2004 -0500, Mpierce1@aol.com wrote: > >>> > >>>> In a message dated 2/19/2004 1:58:18 AM Eastern Standard Time, > >>>> jgunn6@csc.com writes: > >>>> > >>>> > >>>>> So any kind of regular, scheduled test should be > designed so it does > >>>>> NOT > >>>>> tie up the operators. > >>>> > >>>> > >>>> > >>>> I believe the test must be devised so that it does not > involve the > >>>> emergency center or any of the equipment directly supporting the > >>>> emergency center at all. > >>>> > >>>> Mike > >>> > >>> > >>> Then there is not much point in doing any test. As Brian > points out, > >>> the question is how do you stage these reachability tests so that > >>> they scale, ie. you don't have millions of users pinging the ECC > >>> directly. > >>> But, instead of the proxies pinging the ECC, which might > reduce the > >>> load, but might not make the burstiness more > deterministic, perhaps a > >>> presence subscription would be more appropriate. The > proxies could > >>> subscribe to the presence of the ECC, and the ECC could > periodically > >>> Notify those proxies that it is still there and able to > receive calls. > >>> The ECC could then control the scheduling and load > distribution for > >>> sending the Notifies. Failing to receive the > notifications beyond > >>> some interval could provide an indication that something > is wrong and > >>> trigger an inquiry. You might even be able to extend this to the > >>> users, where emergency help is a "buddy" you subscribe to on the > >>> local proxy. I haven't thought this through, but thought > I'd throw > >>> that out. > >>> Mike H. > >> > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 20 16:16:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14135 for ; Fri, 20 Feb 2004 16:16:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHzr-0002Ho-7M for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 16:15:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KLFhPO008782 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 16:15:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHzr-0002HY-3I for sipping-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 16:15:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14085 for ; Fri, 20 Feb 2004 16:15:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuHzp-0002Sn-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 16:15:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuHyD-00027u-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 16:14:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuHxH-0001w6-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 16:13:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHxF-0001yT-6C; Fri, 20 Feb 2004 16:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHwS-0001uz-TY for sipping@optimus.ietf.org; Fri, 20 Feb 2004 16:12:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13861 for ; Fri, 20 Feb 2004 16:12:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuHwR-0001rZ-00 for sipping@ietf.org; Fri, 20 Feb 2004 16:12:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuHvW-0001mF-00 for sipping@ietf.org; Fri, 20 Feb 2004 16:11:15 -0500 Received: from smtp.sylantro.com ([65.200.90.207]) by ietf-mx with esmtp (Exim 4.12) id 1AuHuX-0001e6-00 for sipping@ietf.org; Fri, 20 Feb 2004 16:10:13 -0500 Received: from 10.10.5.1 by smtp.sylantro.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v5.6.0)); Fri, 20 Feb 2004 13:07:41 -0800 X-Server-Uuid: A2273672-8896-48F6-829D-BBF711663783 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] updated dialog package Date: Fri, 20 Feb 2004 13:07:41 -0800 Message-ID: <22ACFCD87A5780449EEBDD6D78BB8DB50C37E9@sylmail1> Thread-Topic: [Sipping] updated dialog package Thread-Index: AcP3EqxQ6nGQBa+0SDqmhH7wkiHqvQA3Y4ww From: "Venkatesh Venkataramanan" To: "Rohan Mahy" , sipping cc: "Anil Kumar" X-WSS-ID: 6C28A8971XC69007-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi: From a shared line application perspective: * Altering the dialog state draft to support sending NOTIFY before phone = actually goes off-hook was required ! * There are a piece missing from a implementation perspective for shared = line appearances.=20 - Ability to signal Hold. I know there have been a few discussions in = the SIPPING mailing list around this and it there was no conclusion = about what "hold" actually is ! However, one of the important aspects of = shared lines is the ability to communicate a held call to the other = parties in the group. Currently the anil-sipping-bla draft uses the SDP = information to help other UA's decide a dialog is transitioning to hold = and off hold. It would be definitely useful to have the dialog state = express this state to the far end rather than having to send out SDP = information. For the purpose of SLA, instead of going down defining what = is Hold, I was wondering if we can create a state/or an attribute in = the dialog state package say "pickable" dialog to indicate the same. = I've heard comments saying a UA can block relevant fields of a dialog = whenever it wants others to be able to pick or not to pick a dialog, = however the same is not clean and it breaks when say the same UA that = put the dialog on Hold, retrieves the dialog. Nothing in the dialog = identifiers have changed. The anil-sipping-bla-draft covers other various aspects of SLA from an = application implementation perspective with call flow examples. regards, Venkatesh -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Rohan Mahy Sent: Thursday, February 19, 2004 10:00 AM To: sipping Cc: rohan@cisco.com Subject: [Sipping] updated dialog package Hi Everyone, I've updated the dialog packages with the changes we agreed to in=20 Minneapolis (removing CSeq and the Route-Set). I've also provided a detailed example of using the dialog package for a=20 "shared-line" application. I apologize for my tardiness here. I was=20 supposed to post something shortly after the meeting. I any case, I=20 believe this demonstrates that the current syntax is at least=20 sufficient for the use cases we've discussed. I would like to hear=20 from all of you if this does the trick. many thanks, -rohan _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 20 20:46:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27504 for ; Fri, 20 Feb 2004 20:46:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMDl-0007yA-Uo for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 20:46:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L1kLOD030630 for sipping-archive@odin.ietf.org; Fri, 20 Feb 2004 20:46:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMDl-0007xx-R8 for sipping-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 20:46:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27499 for ; Fri, 20 Feb 2004 20:46:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuMDj-0007au-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 20:46:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuMCq-0007Xz-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 20:45:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuMCZ-0007Un-00 for sipping-web-archive@ietf.org; Fri, 20 Feb 2004 20:45:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMCV-0007om-U5; Fri, 20 Feb 2004 20:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMBk-0007ko-Sh for sipping@optimus.ietf.org; Fri, 20 Feb 2004 20:44:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27440 for ; Fri, 20 Feb 2004 20:44:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuMBi-0007SW-00 for sipping@ietf.org; Fri, 20 Feb 2004 20:44:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuMAk-0007P9-00 for sipping@ietf.org; Fri, 20 Feb 2004 20:43:15 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AuM9n-0007MX-00 for sipping@ietf.org; Fri, 20 Feb 2004 20:42:15 -0500 Received: from bear.cs.columbia.edu (IDENT:QiwB8Wus41Sm3VPLfFChT05lYqGnq+Xz@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1L1fcmS013966 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 20 Feb 2004 20:41:38 -0500 (EST) Received: from cs.columbia.edu (pool-138-89-87-133.mad.east.verizon.net [138.89.87.133]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1L1fbmi022960 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 20 Feb 2004 20:41:37 -0500 Message-ID: <4036B750.1040304@cs.columbia.edu> Date: Fri, 20 Feb 2004 20:41:36 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Paul Kyzivat CC: Michael Hammer , Mpierce1@aol.com, jgunn6@csc.com, sipping@ietf.org Subject: Re: [Sipping] Re: sos - dead or alive References: <4.3.2.7.2.20040220093002.00b283f0@cia.cisco.com> <4.3.2.7.2.20040220093002.00b283f0@cia.cisco.com> <4.3.2.7.2.20040220103319.02fbf370@cia.cisco.com> <40365A1A.5030102@cisco.com> In-Reply-To: <40365A1A.5030102@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Clearly, this has to work with mobile terminals. However, the mobility indication leads me to re-think the testing approach a bit and consider a more modular solution: (1) Make sure that a device has recent location information; (2) Make sure that it can look up a DNS record for that information or, ask its outbound proxy to do that (MaxForwards=1). There is no particular reason for everybody who resolves psap.ny.ny.gov to go and send it a SIP request - the result is likely the same. (3) Have a testing application (e.g., run by some government agency or large providers) that walks the sos.arpa DNS tree and does sanity checks. For example, we might want to include in the OPTIONS response the area that a PSAP covers. If the DNS entry and the OPTIONS response differ on that, there's a problem that needs to be fixed - but that's probably best dealt with not by grandma or Vonage, but by an agency that knows whom to contact to fix such issues. (Such systematic tests could presumably also be used to gather availability statistics and discover routing problems.) Having an end-to-end test doesn't really add much value beyond the component tests except for testing network reachability. However, network reachability changes fairly quickly, so the fact that I can or can't reach an IP address now doesn't say much as to whether I can reach it a few hours from now. Doing a true end-to-end check is helpful for NATted devices, but then we'd also have to do an RTP echo test. Doing a NAT test isn't really necessary on a daily basis, as the configuration doesn't tend to change that often. Thus, I think we should either use component testing or think of a more comprehensive test. I think a manual 'test' function is useful in any event, probably with an RTP echo. (This could be done via INVITE with caller preferences indication of sos.test; the remote site would then 'pick up' and say 'Your test call to the Hickstown emergency call center has been successful. If this is a real emergency, please hang up and dial 911 - and please remember to change your smoke detector batteries.') Henning Paul Kyzivat wrote: > The mobile issue is interesting. I would think that a mobile phone might > want to test connectivity every time it moved into a different > geographical area, or every time it roamed to a cell under different > administration. That could up the load considerably. > > Paul > > Michael Hammer wrote: > >> Henning, >> >> The reality of deployment would be that every ECC would have it's own >> proxy, so that would be more like 1000 x $2k = $2 million. But, the >> corresponding distribution of load across those servers means it is >> even more of a non-problem at any given site. >> >> One question: A real successful test to a wrong ECC doesn't buy you >> much. I hope that mobility is addressed in the solution as well. >> Many of those 100 million phones are mobile, which might become >> SIP-based some time in the future. so I would add a 6) "works with >> mobile terminals" to your list below. >> >> Mike >> >> At 10:00 AM 2/20/2004 -0500, Henning Schulzrinne wrote: >> >>> I think there are five goals, somewhat contradictory: >>> >>> (1) make it as realistic as possible, to make sure you are really >>> testing the emergency calling system, not the testing system; after >>> all, the fire safety officer doesn't go around ringing a cowbell >>> instead of the real fire alarms. >>> >>> (2) do not impose any additional operator involvement; this is solved >>> by the OPTIONS mechanism proposed; >>> >>> (3) allow for reasonable scaling; >>> >>> (4) avoid interfering with real emergency calls >>> >>> (5) allow user on-demand testing. >>> >>> With the proxy-based testing I proposed, we get very close to all >>> goals. In the worst case, i.e., every device does this once a day, we >>> get roughly 100 million calls a day in the US, or 1157/second. That's >>> about 10 proxy servers worth of equipment, i.e., about $20k. This >>> hardly seems worth spending inordinate engineering resources on >>> avoiding, particularly since the likely load is going to be lower by >>> probably a factor of 1000 or more (I'm assuming that most residential >>> users will use a cable or DSL provider for this, for example). >>> >>> With even a few hundred systems, you'll get almost perfect smoothing >>> and very little burstiness. >>> >>> I know protocol design is fun, but I'm very worried about adding >>> complexity to solve largely a non-problem. >>> >>> Michael Hammer wrote: >>> >>>> At 09:03 AM 2/19/2004 -0500, Mpierce1@aol.com wrote: >>>> >>>>> In a message dated 2/19/2004 1:58:18 AM Eastern Standard Time, >>>>> jgunn6@csc.com writes: >>>>> >>>>> >>>>>> So any kind of regular, scheduled test should be designed so it does >>>>>> NOT >>>>>> tie up the operators. >>>>> >>>>> >>>>> >>>>> >>>>> I believe the test must be devised so that it does not involve the >>>>> emergency center or any of the equipment directly supporting the >>>>> emergency center at all. >>>>> >>>>> Mike >>>> >>>> >>>> >>>> Then there is not much point in doing any test. As Brian points >>>> out, the question is how do you stage these reachability tests so >>>> that they scale, ie. you don't have millions of users pinging the >>>> ECC directly. >>>> But, instead of the proxies pinging the ECC, which might reduce the >>>> load, but might not make the burstiness more deterministic, perhaps >>>> a presence subscription would be more appropriate. The proxies >>>> could subscribe to the presence of the ECC, and the ECC could >>>> periodically Notify those proxies that it is still there and able to >>>> receive calls. >>>> The ECC could then control the scheduling and load distribution for >>>> sending the Notifies. Failing to receive the notifications beyond >>>> some interval could provide an indication that something is wrong >>>> and trigger an inquiry. You might even be able to extend this to >>>> the users, where emergency help is a "buddy" you subscribe to on the >>>> local proxy. I haven't thought this through, but thought I'd throw >>>> that out. >>>> Mike H. >>> >>> >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 22 13:22:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03147 for ; Sun, 22 Feb 2004 13:22:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuyEX-0005it-IY for sipping-archive@odin.ietf.org; Sun, 22 Feb 2004 13:21:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1MILfqT021993 for sipping-archive@odin.ietf.org; Sun, 22 Feb 2004 13:21:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuyEX-0005ie-4l for sipping-web-archive@optimus.ietf.org; Sun, 22 Feb 2004 13:21:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03141 for ; Sun, 22 Feb 2004 13:21:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuyEV-0000MR-00 for sipping-web-archive@ietf.org; Sun, 22 Feb 2004 13:21:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuyDc-0000JU-00 for sipping-web-archive@ietf.org; Sun, 22 Feb 2004 13:20:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuyD7-0000GA-00 for sipping-web-archive@ietf.org; Sun, 22 Feb 2004 13:20:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuyCy-0005UZ-Ow; Sun, 22 Feb 2004 13:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuyCW-0005TZ-Jb for sipping@optimus.ietf.org; Sun, 22 Feb 2004 13:19:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03075 for ; Sun, 22 Feb 2004 13:19:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuyCU-0000Eb-00 for sipping@ietf.org; Sun, 22 Feb 2004 13:19:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuyBd-0000CF-00 for sipping@ietf.org; Sun, 22 Feb 2004 13:18:44 -0500 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 1AuyAl-00006K-00 for sipping@ietf.org; Sun, 22 Feb 2004 13:17:47 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HTI00B0102KEM@siemenscomms.co.uk> for sipping@ietf.org; Sun, 22 Feb 2004 18:15:56 +0000 (GMT) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HTI0066B02K6Q@siemenscomms.co.uk>; Sun, 22 Feb 2004 18:15:56 +0000 (GMT) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Sun, 22 Feb 2004 18:22:35 +0000 Content-return: allowed Date: Sun, 22 Feb 2004 18:17:10 +0000 From: "Elwell, John" To: Cullen Jennings , sipping@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667D4ABDD@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/mixed; boundary="Boundary_(ID_KjWIVHTBo5sNlbvaG2Fi5Q)" Subject: [Sipping] RE: comments on :draft-ietf-sipping-qsig2sip-04.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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. --Boundary_(ID_KjWIVHTBo5sNlbvaG2Fi5Q) Content-type: text/plain Content-Transfer-Encoding: 7BIT Cullen, See in-line. John > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 17 February 2004 16:00 > To: sipping@ietf.org; Elwell, John > Subject: comments on :draft-ietf-sipping-qsig2sip-04.txt > > > > One major concern, Section 9.1.3 and 9.2.3 - PAI won't work > for this as > described in draft-jennings-sipping-connected-00. I highly > recommend we talk > about this on a phone call or in Korea and get it sorted out. > Suggesting a > solution here will just make solving this problem more > complex. Even if you > think that it does work, it is definitely a new semantic > meaning of PAI that > is not covered in any the current documents. This would > require the qsig2sip > document to be dealt with in the sip WG instead of sipping it > it is going to > extend the meaning of PAI. [JRE] See attached email thread, in which I received only support for the use of PAI in a response. For the reasons given in the first email in the thread, and also for the additional reason stated in the response from Keith Drage, I don't believe the qsig2sip document is extending the meaning of PAI. > It is recognized that SIP is > lacking in this > area, there have been multiple drafts proposing solutions > (including the > work in draft-elwell-sip-state-update). I think it would be > better to get > one of theses solutions moving and just use it here. > > Few minor things: > > If the GW signs a sipfrag, what should be in the SubjectAltName of the > certificate? [JRE] It would have to be something that identifies the gateway. > > Section 9.1 (and other places) The terminology "the gw trusts > the next hop" > is wrong and should be something more like "the GW is in the > same trust > domain (as defined in RFC 3325) as the next hop" [JRE] OK > > Section 9.2.2 If the From is Anonymous, and there is no > privacy value, then > it should be treated as if there was a privacy value of id. [JRE] OK > > NIT: > > I find reference style of "as described in [10]" much harder > to read than " > as described in RFC 3261 [10]" [JRE] I don't mind. Is there a documented preference? RFCs such as 3325 and 3261 are certainly not consistent in this respect. > > Cullen > > > On 1/20/04 7:05 AM, "Internet-Drafts@ietf.org" > > wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Session Initiation > Proposal Investigation > > Working Group of the IETF. > > > > Title : Interworking between SIP and QSIG > > Author(s) : J. Elwell > > Filename : draft-ietf-sipping-qsig2sip-04.txt > > Pages : 61 > > Date : 2004-1-19 > > > > This document specifies interworking between the Session Initiation > > Protocol (SIP) and QSIG within corporate telecommunication networks > > (also known as enterprise networks). SIP is an Internet > application- > > layer control (signalling) protocol for creating, modifying, and > > terminating sessions with one or more participants. These sessions > > include, in particular, telephone calls. QSIG is a signalling > > protocol for creating, modifying and terminating circuit-switched > > calls, in particular telephone calls, within Private Integrated > > Services Networks (PISNs). QSIG is specified in a number of ECMA > > Standards and published also as ISO/IEC standards. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-04.txt > > > > To remove yourself from the IETF Announcement list, send a > message to > > ietf-announce-request with the word unsubscribe in the body > of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-sipping-qsig2sip-04.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-sipping-qsig2sip-04.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > Content-Type: text/plain > > Content-ID: <2004-1-20102746.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-ietf-sipping-qsig2sip-04.txt > > > --Boundary_(ID_KjWIVHTBo5sNlbvaG2Fi5Q) Content-type: message/rfc822 Content-description: RE: [Sip] Use of P-Asserted-Identity in a response Date: Mon, 19 Jan 2004 12:59:31 +0000 From: Mark Watson Subject: RE: [Sip] Use of P-Asserted-Identity in a response To: "'Elwell, John'" , "'SIP@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-Transfer-Encoding: 7BIT John, It was certainly the intention when 3324/3325 were written that PAI could appear in responses. The term message was used deliberately. I am not sure where opinions to the contrary have come from - has someone claimed that a 'response' is not a 'message' ? ...Mark -----Original Message----- From: Elwell, John [ mailto:john.elwell@siemens.com ] Sent: 02 January 2004 16:11 To: SIP@ietf.org Subject: [Sip] Use of P-Asserted-Identity in a response There seem to be some differences of opinion concerning the use of P-Asserted-Identity (PAI) in a response. In particular, this is delaying the progress of draft-ietf-sipping-qsig2sip, which makes use of PAI in a 200 OK to convey the connected party identity received from the QSIG network. The same situation is likely to be encountered when interworking with other legacy signalling systems. It is my opinion that PAI can be used in a 200 OK to assert the identity of the connect party. Moreover, it can be inserted by a gateway UAS and, unless subject to privacy, can be passed on even to untrusted entities including the UAC. My evidence for assuming this is as follows: 1. RFC 3325: In section 5, 2nd paragraph it states: "If the proxy receives a message (request or response) from a node that it trusts, it can use the information in the P-Asserted-Identity header field, if any, as if it had authenticated the user itself." There is nowhere that forbids the use of P-Asserted-ID in a response, although there are places in the RFC that mention procedures for a request without mentioning a response. In many places it talks about "message", which, according to the text above, means request or response. 2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the calling user, PAI in a 180 response the ringing user and PAI in 200 OK the user who answered the call. RFC 3325 is supposed to meet the requirement of RFC3324. I have seen a number of arguments against the use of PAI in a response: a) It has been suggested that a PAI in a response represents the identity of the entity that issued the request. This does not hold water. It clearly would be in contradiction to clause 5 of RFC3324 and there is nowhere in RFC3324 or RFC3325 that suggests echoing in a response the PAI in the request. b)It has been suggested that there would need to be corresponding privacy requirements for identity information in a response. However, RFC 3323 does indeed address privacy in responses. See last paragraph of section 3: "It may be desirable to restrict identity information on both requests and responses. Initially, it might seem unusual to suggest that a response has privacy concerns - presumably, the originator of the request knows who they were attempting to contact, so the identity of the respondent can hardly be confidential. However, some personal information in responses (such as the contact address at which the respondent is currently registered) is subject to privacy concerns and can be addressed by these mechanisms." Also see section 4.2, which states: "...this document defines a new SIP header, Privacy, that can be used to specify privacy handling for requests and responses." c)It has been argued that using PAI in a response may cause an existing implementation to do the wrong thing with respect to privacy, e.g., if privacy is required by the caller, a proxy may apply this to the connected user's identity in the response as well. I don't think this is a likely scenario in view of RFC 3323's coverage of privacy in requests and responses. d)Also it has been suggested that an existing UAS may not take care to request privacy in a response, not realising that a proxy might add a PAI. Again, since RFC 3323 covers privacy in both requests and responses, any UA implementation that supports privacy in requests should also support privacy in responses. e) It has been pointed out that a proxy cannot reject a response if the PAI is wrong. I don't believe this matters - it should be sufficient for the proxy just to strip out a PAI that is wrong. In conclusion, I see evidence that PAI can be used in a response to assert the ID of the connected party and no solid evidence to the contrary. John Elwell (john.elwell@siemens.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 --Boundary_(ID_KjWIVHTBo5sNlbvaG2Fi5Q) Content-type: message/rfc822 Content-description: RE: [Sip] Use of P-Asserted-Identity in a response Date: Sun, 04 Jan 2004 00:57:31 +0000 From: "Drage, Keith (Keith)" Subject: RE: [Sip] Use of P-Asserted-Identity in a response To: "Elwell, John" , SIP@ietf.org Message-id: <475FF955A05DD411980D00508B6D5FB00AA7817B@en0033exch001u.uk.lucent.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-Transfer-Encoding: 7BIT RFC 3325 section 9.1 and section 9.2 both extend table 2 of RFC 3261 with the new header. Both entires leave the "where" column empty. The key to RFC 3261 table 2 states: An empty entry in the "where" column indicates that the header field may be present in all requests and responses. I would therefore conclude from the existing specification that both headers may appear in any response to BYE, INV, OPT, SUB, NOT, REF, i.e. those methods that either create a dialog, or are used outside a dialog. As MESSAGE appeared after RFC 3325 I would also assume that it is allowed in the MESSAGE method, in both requests and all responses. Note that these tables do not restrict it to 18x and 2xx responses, although for ISDN mapping purposes those responses are the useful ones. It is perfectly valid in 3xx, 4xx and 5xx responses. Any assertion of identity in responses (and its value) is of course dependent on the specification of privacy by the UAS and on the requirements of the first proxy in the trust domain. This usage corresponds to what has been specified in 3GPP TS 24.229 and I believe in ITU-T Q.1912.5. regards Keith > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 02 January 2004 16:11 > To: SIP@ietf.org > Subject: [Sip] Use of P-Asserted-Identity in a response > > > There seem to be some differences of opinion concerning the use of > P-Asserted-Identity (PAI) in a response. In particular, this > is delaying the > progress of draft-ietf-sipping-qsig2sip, which makes use of > PAI in a 200 OK > to convey the connected party identity received from the QSIG > network. The > same situation is likely to be encountered when interworking > with other > legacy signalling systems. > > It is my opinion that PAI can be used in a 200 OK to assert > the identity of > the connect party. Moreover, it can be inserted by a gateway > UAS and, unless > subject to privacy, can be passed on even to untrusted > entities including > the UAC. > > My evidence for assuming this is as follows: > > 1. RFC 3325: In section 5, 2nd paragraph it states: > "If the proxy receives a message (request or response) from a > node that it > trusts, it can use the information in the P-Asserted-Identity > header field, > if any, as if it had authenticated the user itself." > There is nowhere that forbids the use of P-Asserted-ID in a response, > although there are places in the RFC that mention procedures > for a request > without mentioning a response. In many places it talks about > "message", > which, according to the text above, means request or response. > > 2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the > calling user, PAI in a 180 response the ringing user and PAI > in 200 OK the > user who answered the call. RFC 3325 is supposed to meet the > requirement of > RFC3324. > > I have seen a number of arguments against the use of PAI in a > response: > > a) It has been suggested that a PAI in a response represents > the identity of > the entity that issued the request. This does not hold water. > It clearly > would be in contradiction to clause 5 of RFC3324 and there is > nowhere in > RFC3324 or RFC3325 that suggests echoing in a response the PAI in the > request. > > b)It has been suggested that there would need to be > corresponding privacy > requirements for identity information in a response. However, > RFC 3323 does > indeed address privacy in responses. See last paragraph of section 3: > "It may be desirable to restrict identity information on both > requests and > responses. Initially, it might seem unusual to suggest that > a response has > privacy concerns - presumably, the originator of the request > knows who they > were attempting to contact, so the identity of the respondent > can hardly be > confidential. However, some personal information in > responses (such as the > contact address at which the respondent is currently > registered) is subject > to privacy concerns and can be addressed by these mechanisms." > Also see section 4.2, which states: > "...this document defines a new SIP header, Privacy, that can > be used to > specify privacy handling for requests and responses." > > c)It has been argued that using PAI in a response may cause > an existing > implementation to do the wrong thing with respect to privacy, e.g., if > privacy is required by the caller, a proxy may apply this to > the connected > user's identity in the response as well. I don't think this > is a likely > scenario in view of RFC 3323's coverage of privacy in requests and > responses. > > d)Also it has been suggested that an existing UAS may not take care to > request privacy in a response, not realising that a proxy > might add a PAI. > Again, since RFC 3323 covers privacy in both requests and > responses, any UA > implementation that supports privacy in requests should also > support privacy > in responses. > > e) It has been pointed out that a proxy cannot reject a > response if the PAI > is wrong. I don't believe this matters - it should be > sufficient for the > proxy just to strip out a PAI that is wrong. > > In conclusion, I see evidence that PAI can be used in a > response to assert > the ID of the connected party and no solid evidence to the contrary. > > John Elwell (john.elwell@siemens.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 > --Boundary_(ID_KjWIVHTBo5sNlbvaG2Fi5Q) Content-type: message/rfc822 Content-description: Re: [Sip] Use of P-Asserted-Identity in a response Date: Sun, 04 Jan 2004 00:27:28 +0000 From: Tom Taylor Subject: Re: [Sip] Use of P-Asserted-Identity in a response To: David Oran Cc: "Elwell, John" , SIP@ietf.org Message-id: <3FF75DF0.7080402@nortelnetworks.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-Transfer-Encoding: 7BIT I would also support this usage. David Oran wrote: > These arguments are good ones. > Even if they weren't good I'd still be in favor of what John proposes, > because it's eminently reasonable and provides desperately needed > functionality for which we currently have no alternative machinery. > > Dave. > > --On Friday, January 2, 2004 4:10 PM +0000 "Elwell, John" > wrote: > >> There seem to be some differences of opinion concerning the use of >> P-Asserted-Identity (PAI) in a response. In particular, this is delaying >> the progress of draft-ietf-sipping-qsig2sip, which makes use of PAI in a >> 200 OK to convey the connected party identity received from the QSIG >> network. The same situation is likely to be encountered when interworking >> with other legacy signalling systems. >> >> It is my opinion that PAI can be used in a 200 OK to assert the identity >> of the connect party. Moreover, it can be inserted by a gateway UAS and, >> unless subject to privacy, can be passed on even to untrusted entities >> including the UAC. >> >> My evidence for assuming this is as follows: >> >> 1. RFC 3325: In section 5, 2nd paragraph it states: >> "If the proxy receives a message (request or response) from a node >> that it >> trusts, it can use the information in the P-Asserted-Identity header >> field, if any, as if it had authenticated the user itself." >> There is nowhere that forbids the use of P-Asserted-ID in a response, >> although there are places in the RFC that mention procedures for a >> request >> without mentioning a response. In many places it talks about "message", >> which, according to the text above, means request or response. >> >> 2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the >> calling user, PAI in a 180 response the ringing user and PAI in 200 OK >> the >> user who answered the call. RFC 3325 is supposed to meet the requirement >> of RFC3324. >> >> I have seen a number of arguments against the use of PAI in a response: >> >> a) It has been suggested that a PAI in a response represents the identity >> of the entity that issued the request. This does not hold water. It >> clearly would be in contradiction to clause 5 of RFC3324 and there is >> nowhere in RFC3324 or RFC3325 that suggests echoing in a response the PAI >> in the request. >> >> b)It has been suggested that there would need to be corresponding privacy >> requirements for identity information in a response. However, RFC 3323 >> does indeed address privacy in responses. See last paragraph of >> section 3: >> "It may be desirable to restrict identity information on both requests >> and >> responses. Initially, it might seem unusual to suggest that a response >> has privacy concerns - presumably, the originator of the request knows >> who they were attempting to contact, so the identity of the respondent >> can hardly be confidential. However, some personal information in >> responses (such as the contact address at which the respondent is >> currently registered) is subject to privacy concerns and can be addressed >> by these mechanisms." >> Also see section 4.2, which states: >> "...this document defines a new SIP header, Privacy, that can be used to >> specify privacy handling for requests and responses." >> >> c)It has been argued that using PAI in a response may cause an existing >> implementation to do the wrong thing with respect to privacy, e.g., if >> privacy is required by the caller, a proxy may apply this to the >> connected >> user's identity in the response as well. I don't think this is a likely >> scenario in view of RFC 3323's coverage of privacy in requests and >> responses. >> >> d)Also it has been suggested that an existing UAS may not take care to >> request privacy in a response, not realising that a proxy might add a >> PAI. >> Again, since RFC 3323 covers privacy in both requests and responses, any >> UA implementation that supports privacy in requests should also support >> privacy in responses. >> >> e) It has been pointed out that a proxy cannot reject a response if the >> PAI is wrong. I don't believe this matters - it should be sufficient for >> the proxy just to strip out a PAI that is wrong. >> >> In conclusion, I see evidence that PAI can be used in a response to >> assert >> the ID of the connected party and no solid evidence to the contrary. >> >> John Elwell (john.elwell@siemens.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 > > > > > > > _______________________________________________ > 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 > --Boundary_(ID_KjWIVHTBo5sNlbvaG2Fi5Q) Content-type: message/rfc822 Content-description: Re: [Sip] Use of P-Asserted-Identity in a response Date: Sat, 03 Jan 2004 19:13:24 +0000 From: David Oran Subject: Re: [Sip] Use of P-Asserted-Identity in a response To: "Elwell, John" , SIP@ietf.org Message-id: <2147483647.1073139204@[10.32.245.157]> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-Transfer-Encoding: 7BIT These arguments are good ones. Even if they weren't good I'd still be in favor of what John proposes, because it's eminently reasonable and provides desperately needed functionality for which we currently have no alternative machinery. Dave. --On Friday, January 2, 2004 4:10 PM +0000 "Elwell, John" wrote: > There seem to be some differences of opinion concerning the use of > P-Asserted-Identity (PAI) in a response. In particular, this is delaying > the progress of draft-ietf-sipping-qsig2sip, which makes use of PAI in a > 200 OK to convey the connected party identity received from the QSIG > network. The same situation is likely to be encountered when interworking > with other legacy signalling systems. > > It is my opinion that PAI can be used in a 200 OK to assert the identity > of the connect party. Moreover, it can be inserted by a gateway UAS and, > unless subject to privacy, can be passed on even to untrusted entities > including the UAC. > > My evidence for assuming this is as follows: > > 1. RFC 3325: In section 5, 2nd paragraph it states: > "If the proxy receives a message (request or response) from a node that it > trusts, it can use the information in the P-Asserted-Identity header > field, if any, as if it had authenticated the user itself." > There is nowhere that forbids the use of P-Asserted-ID in a response, > although there are places in the RFC that mention procedures for a request > without mentioning a response. In many places it talks about "message", > which, according to the text above, means request or response. > > 2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the > calling user, PAI in a 180 response the ringing user and PAI in 200 OK the > user who answered the call. RFC 3325 is supposed to meet the requirement > of RFC3324. > > I have seen a number of arguments against the use of PAI in a response: > > a) It has been suggested that a PAI in a response represents the identity > of the entity that issued the request. This does not hold water. It > clearly would be in contradiction to clause 5 of RFC3324 and there is > nowhere in RFC3324 or RFC3325 that suggests echoing in a response the PAI > in the request. > > b)It has been suggested that there would need to be corresponding privacy > requirements for identity information in a response. However, RFC 3323 > does indeed address privacy in responses. See last paragraph of section 3: > "It may be desirable to restrict identity information on both requests and > responses. Initially, it might seem unusual to suggest that a response > has privacy concerns - presumably, the originator of the request knows > who they were attempting to contact, so the identity of the respondent > can hardly be confidential. However, some personal information in > responses (such as the contact address at which the respondent is > currently registered) is subject to privacy concerns and can be addressed > by these mechanisms." > Also see section 4.2, which states: > "...this document defines a new SIP header, Privacy, that can be used to > specify privacy handling for requests and responses." > > c)It has been argued that using PAI in a response may cause an existing > implementation to do the wrong thing with respect to privacy, e.g., if > privacy is required by the caller, a proxy may apply this to the connected > user's identity in the response as well. I don't think this is a likely > scenario in view of RFC 3323's coverage of privacy in requests and > responses. > > d)Also it has been suggested that an existing UAS may not take care to > request privacy in a response, not realising that a proxy might add a PAI. > Again, since RFC 3323 covers privacy in both requests and responses, any > UA implementation that supports privacy in requests should also support > privacy in responses. > > e) It has been pointed out that a proxy cannot reject a response if the > PAI is wrong. I don't believe this matters - it should be sufficient for > the proxy just to strip out a PAI that is wrong. > > In conclusion, I see evidence that PAI can be used in a response to assert > the ID of the connected party and no solid evidence to the contrary. > > John Elwell (john.elwell@siemens.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 --Boundary_(ID_KjWIVHTBo5sNlbvaG2Fi5Q) Content-type: message/rfc822 Content-description: Use of P-Asserted-Identity in a response Date: Fri, 02 Jan 2004 16:11:21 +0000 From: "Elwell, John" Subject: Use of P-Asserted-Identity in a response To: "'SIP@ietf.org'" Message-id: <6B2AC5A8F90C654980890BEFA88DCD53E70CEF@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-Transfer-Encoding: 7BIT There seem to be some differences of opinion concerning the use of P-Asserted-Identity (PAI) in a response. In particular, this is delaying the progress of draft-ietf-sipping-qsig2sip, which makes use of PAI in a 200 OK to convey the connected party identity received from the QSIG network. The same situation is likely to be encountered when interworking with other legacy signalling systems. It is my opinion that PAI can be used in a 200 OK to assert the identity of the connect party. Moreover, it can be inserted by a gateway UAS and, unless subject to privacy, can be passed on even to untrusted entities including the UAC. My evidence for assuming this is as follows: 1. RFC 3325: In section 5, 2nd paragraph it states: "If the proxy receives a message (request or response) from a node that it trusts, it can use the information in the P-Asserted-Identity header field, if any, as if it had authenticated the user itself." There is nowhere that forbids the use of P-Asserted-ID in a response, although there are places in the RFC that mention procedures for a request without mentioning a response. In many places it talks about "message", which, according to the text above, means request or response. 2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the calling user, PAI in a 180 response the ringing user and PAI in 200 OK the user who answered the call. RFC 3325 is supposed to meet the requirement of RFC3324. I have seen a number of arguments against the use of PAI in a response: a) It has been suggested that a PAI in a response represents the identity of the entity that issued the request. This does not hold water. It clearly would be in contradiction to clause 5 of RFC3324 and there is nowhere in RFC3324 or RFC3325 that suggests echoing in a response the PAI in the request. b)It has been suggested that there would need to be corresponding privacy requirements for identity information in a response. However, RFC 3323 does indeed address privacy in responses. See last paragraph of section 3: "It may be desirable to restrict identity information on both requests and responses. Initially, it might seem unusual to suggest that a response has privacy concerns - presumably, the originator of the request knows who they were attempting to contact, so the identity of the respondent can hardly be confidential. However, some personal information in responses (such as the contact address at which the respondent is currently registered) is subject to privacy concerns and can be addressed by these mechanisms." Also see section 4.2, which states: "...this document defines a new SIP header, Privacy, that can be used to specify privacy handling for requests and responses." c)It has been argued that using PAI in a response may cause an existing implementation to do the wrong thing with respect to privacy, e.g., if privacy is required by the caller, a proxy may apply this to the connected user's identity in the response as well. I don't think this is a likely scenario in view of RFC 3323's coverage of privacy in requests and responses. d)Also it has been suggested that an existing UAS may not take care to request privacy in a response, not realising that a proxy might add a PAI. Again, since RFC 3323 covers privacy in both requests and responses, any UA implementation that supports privacy in requests should also support privacy in responses. e) It has been pointed out that a proxy cannot reject a response if the PAI is wrong. I don't believe this matters - it should be sufficient for the proxy just to strip out a PAI that is wrong. In conclusion, I see evidence that PAI can be used in a response to assert the ID of the connected party and no solid evidence to the contrary. John Elwell (john.elwell@siemens.com) --Boundary_(ID_KjWIVHTBo5sNlbvaG2Fi5Q)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 00:49:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25603 for ; Mon, 23 Feb 2004 00:49:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av8xl-0007gd-C9 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 00:49:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N5n54w029544 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 00:49:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av8xl-0007gR-7x for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 00:49:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25594 for ; Mon, 23 Feb 2004 00:49:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av8xi-00032z-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 00:49:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av8wj-0002yV-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 00:48:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Av8vq-0002uS-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 00:47:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av8vl-0007VP-AH; Mon, 23 Feb 2004 00:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av8uo-0007On-TE for sipping@optimus.ietf.org; Mon, 23 Feb 2004 00:46:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25453 for ; Mon, 23 Feb 2004 00:45:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av8um-0002ot-00 for sipping@ietf.org; Mon, 23 Feb 2004 00:46:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av8tt-0002lb-00 for sipping@ietf.org; Mon, 23 Feb 2004 00:45:06 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Av8tC-0002e4-00 for sipping@ietf.org; Mon, 23 Feb 2004 00:44:22 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 22 Feb 2004 21:54:25 +0000 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 i1N5houC000355; Sun, 22 Feb 2004 21:43:51 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn4-923.cisco.com [10.21.83.154]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMO38836; Sun, 22 Feb 2004 21:43:49 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 22 Feb 2004 12:39:57 -0800 Subject: Re: [Sipping] SIP Proxy servers -- security encryption protocol From: Cullen Jennings To: , , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3160331029_775979" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 > 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_3160331029_775979 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable And the crypto that is typically being recommended and folks are implementing is RSA for asymmetric key, SHA1 for hash, and 3DES or AES for encryption. Some of the early stuff said 3DES because the RFC would have blocked on AES work. It=B9s a long debate with no clear answer between AES an= d 3DES (and let=B9s not repeat it on this list) but most SIP implementers seem to be doing AES or both AES and 3DES. On 2/19/04 9:26 PM, "ranjit.avasarala@wipro.com" wrote: > Hi > For secured transactions you could use TLS i.e using sips: instead of > normal sip: url. > Alternatively IPSec also could be used at IP Layer > and for RTP security you could use SRTP (draft-ietf-avt-srtp-09.txt) prot= ocol. > =20 > Regards > Ranjit >> =20 >> =20 >> -----Original Message----- >> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf = Of >> Scoggins, Sophia >> Sent: Friday, February 20, 2004 10:45 AM >> To: 'sipping@ietf.org' >> Subject: [Sipping] SIP Proxy servers -- security encryption protocol >>=20 >> =20 >> =20 >>=20 >> =20 >> =20 >> My group is looking for some security encryption protocol for both SIP = and >> RTP streams for CPE. We were wondering what encryption protocol that mo= st >> SIP proxy servers currently support or intend to support? Would you ple= ase >> just send your reply to me? >> =20 >> =20 >> =20 >> Thanks. >> =20 >> =20 >> =20 >> Regards, >> =20 >> Sophia2@ti.com >=20 --B_3160331029_775979 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sipping] SIP Proxy servers -- security encryption protocol</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:14.0px'><BR> And the crypto that is typically being recommended and folks are implementi= ng is RSA for asymmetric key, SHA1 for hash, and 3DES or AES for encryption.= Some of the early stuff said 3DES because the RFC would have blocked on AES= work. It’s a long debate with no clear answer between AES and 3DES (a= nd let’s not repeat it on this list) but most SIP implementers seem to= be doing AES or both AES and 3DES.  <BR> <BR> On 2/19/04 9:26 PM, "ranjit.avasarala@wipro.com" <ranjit.avasa= rala@wipro.com> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><SPAN STYLE=3D'font-size:14.0px'><FONT COLOR=3D"#0000= FF"><FONT FACE=3D"Arial">Hi<BR>     For secured transactions you could use TLS i.e usin= g sips: instead of normal sip: url.<BR> Alternatively IPSec also could be used at IP Layer<BR> and for RTP security you could use SRTP (draft-ietf-avt-srtp-09.txt) protoc= ol.<BR> </FONT></FONT><FONT FACE=3D"Verdana"> <BR> </FONT><FONT COLOR=3D"#0000FF"><FONT FACE=3D"Arial">Regards<BR> Ranjit<BR> </FONT></FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:14.0px'><FONT FACE=3D= "Verdana"> <BR>  <BR> </FONT><FONT FACE=3D"Tahoma">-----Original Message-----<BR> <B>From:</B>  sipping-admin@ietf.org [<a href=3D"mailto:sipping-admin@ie= tf.org]">mailto:sipping-admin@ietf.org]</a> <B>On Behalf Of  </B>Scoggi= ns, Sophia<BR> <B>Sent:</B> Friday, February 20, 2004 10:45  AM<BR> <B>To:</B> 'sipping@ietf.org'<BR> <B>Subject:</B> [Sipping] SIP Proxy  servers -- security encryption pr= otocol<BR> <BR> </FONT><FONT FACE=3D"Verdana"> <BR>  <BR> <BR>  <BR>  <BR> My group is looking for some  security encryption protocol for both SI= P and RTP streams for CPE. We were  wondering what encryption protocol = that most SIP proxy servers currently  support or intend to support? Wo= uld you please just send your reply to  me?<BR>  <BR>  <BR>  <BR> Thanks.<BR>  <BR>  <BR>  <BR> Regards,<BR>  <BR> Sophia2@ti.com<BR> </FONT></SPAN></BLOCKQUOTE><SPAN STYLE=3D'font-size:14.0px'><FONT FACE=3D"Verda= na"><BR> </FONT></SPAN></BLOCKQUOTE><SPAN STYLE=3D'font-size:14.0px'><FONT FACE=3D"Verda= na"><BR> </FONT></SPAN> </BODY> </HTML> --B_3160331029_775979-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 01:29:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26438 for <sipping-archive@odin.ietf.org>; Mon, 23 Feb 2004 01:29:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9aZ-0001pM-Ml for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 01:29:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N6TBJc007018 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 01:29:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9aZ-0001p7-Gm for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 01:29:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26402 for <sipping-web-archive@ietf.org>; Mon, 23 Feb 2004 01:29:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av9aW-00054c-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 01:29:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av9ZS-00050M-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 01:28:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Av9YU-0004wb-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 01:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9YT-0001eN-Ft; Mon, 23 Feb 2004 01:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9YP-0001e0-DH for sipping@optimus.ietf.org; Mon, 23 Feb 2004 01:26:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26329 for <sipping@ietf.org>; Mon, 23 Feb 2004 01:26:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av9YM-0004vN-00 for sipping@ietf.org; Mon, 23 Feb 2004 01:26:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av9XO-0004sO-00 for sipping@ietf.org; Mon, 23 Feb 2004 01:25:55 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Av9WT-0004ni-00 for sipping@ietf.org; Mon, 23 Feb 2004 01:24:57 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 22 Feb 2004 22:34:19 +0000 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 i1N6OQ4U024539; Sun, 22 Feb 2004 22:24:26 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn3-603.cisco.com [10.21.66.91]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMO40120; Sun, 22 Feb 2004 22:24:26 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 22 Feb 2004 22:24:21 -0800 Subject: Re: [Sipping] RE: comments on :draft-ietf-sipping-qsig2sip-04.txt From: Cullen Jennings <fluffy@cisco.com> To: "Elwell, John" <john.elwell@siemens.com>, <sipping@ietf.org> Message-ID: <BC5EDC95.32A27%fluffy@cisco.com> In-Reply-To: <50B1CBA96870A34799A506B2313F2667D4ABDD@ntht201e> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe> List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org> List-Post: <mailto:sipping@ietf.org> List-Help: <mailto:sipping-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think the attached email thread more or less makes exactly my point. I am not at all arguing that 3325 forbids PAI in response. That was never the intention - but 3325 certainly does not say what it means in a response or how to make it work to something useful or what the useful thing you can do is. It does not say if PAI in a response is the identity of the UAS or the UAC. It does not deal with the issue of how you authenticate a response. There is a bunch of other things it does not deal with. The pure amount of language lawyer conjecture in the email thread makes it clear that 3325 does not define what it means. If you want to clearly define what PAI in a response means in some document (qsig or another one), I've got no problem with that - I want to solve this problem - but 3325 does not define what it means or how to make it work to accomplish some useful goal. Cullen On 2/22/04 10:17 AM, "Elwell, John" <john.elwell@siemens.com> wrote: >> One major concern, Section 9.1.3 and 9.2.3 - PAI won't work >> for this as >> described in draft-jennings-sipping-connected-00. I highly >> recommend we talk >> about this on a phone call or in Korea and get it sorted out. >> Suggesting a >> solution here will just make solving this problem more >> complex. Even if you >> think that it does work, it is definitely a new semantic >> meaning of PAI that >> is not covered in any the current documents. This would >> require the qsig2sip >> document to be dealt with in the sip WG instead of sipping it >> it is going to >> extend the meaning of PAI. > [JRE] See attached email thread, in which I received only support for the > use of PAI in a response. For the reasons given in the first email in the > thread, and also for the additional reason stated in the response from Keith > Drage, I don't believe the qsig2sip document is extending the meaning of > PAI. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 05:46:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18653 for <sipping-archive@odin.ietf.org>; Mon, 23 Feb 2004 05:46:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDbJ-00042n-88 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 05:46:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NAkDl4015537 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 05:46:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDbJ-00042W-13 for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 05:46:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18648 for <sipping-web-archive@ietf.org>; Mon, 23 Feb 2004 05:46:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvDbF-0006pS-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 05:46:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvDaO-0006mM-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 05:45:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvDa2-0006iX-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 05:44:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDZC-0003iR-4W; Mon, 23 Feb 2004 05:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDYK-0003gK-AT for sipping@optimus.ietf.org; Mon, 23 Feb 2004 05:43:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18539 for <sipping@ietf.org>; Mon, 23 Feb 2004 05:43:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvDYG-0006dC-00 for sipping@ietf.org; Mon, 23 Feb 2004 05:43:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvDXJ-0006aA-00 for sipping@ietf.org; Mon, 23 Feb 2004 05:42:07 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly07b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AvDWR-0006Us-00; Mon, 23 Feb 2004 05:41:11 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly07b.srv.mailcontrol.com (MailControl) with SMTP id i1NAeVsY012644; Mon, 23 Feb 2004 10:40:32 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Mon, 23 Feb 2004 10:40:30 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3F9F9.63E954A7" Date: Mon, 23 Feb 2004 10:40:01 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF1F2@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: yes Thread-Topic: [Simple] Advanced IM requirements Thread-Index: AcP5C/kBvwKHvMXJS6urOHqe9sfskgA3pGvQ From: "Chris Boulton" <cboulton@ubiquity.net> To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>, "Simple WG" <simple@ietf.org> Cc: <sipping@ietf.org> X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Subject: [Sipping] RE: [Simple] Advanced IM requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe> List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org> List-Post: <mailto:sipping@ietf.org> List-Help: <mailto:sipping-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------_=_NextPart_001_01C3F9F9.63E954A7 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jonathan et al, I have an extremely early version (so be gentle) of a draft aimed at supplying IM delivery reports. It hasn't been formally submitted yet but I have attached a copy - so would be grateful if the list could take a look and see if it's worth progressing. I will submit to the archives in the next few days. I will also put this on the internet somewhere in case this attachment doesn't survive its journey (Will send link later). Best Regards, Chris. =20 >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: 22 February 2004 06:17 >To: Simple WG >Subject: [Simple] Advanced IM requirements > >Folks, > >As I noted earlier, I resubmitted the advanced IM requirements draft. It >specifies a bunch of advanced IM functions we havent yet tackled here. >They are: > >* delivery reports for IM >* is-typing indicator (Henning had an I-D on this that has expired) >* capabilities indications of maximum desired message sizes for IM >* page mode groups (under discussion in the context of exploders in >sipping) >* invitations to non-real time sessions > > >The last of these is particularly interesting. One use case is "call >alerts" in PTT. There, I send you a request to have a PTT chat. The >request is not answered in real time. Rather, its stored by the >recipient as if it were an IM, and can be answered at any time later. >"Answering it" merely involves setting up a PTT call back to the caller. >Its also possible to cancel the call alert at any time. > >There are some interesting ways to accomplish this function. The one >I've been thinking about is taking a SIP INVITE message, and sending it >in the body of a MESSAGE request as a message/sip content. I'm sure >there are other ways. > >Are these topics for which there is still group interest in working on? >I think all of them remain quite important. > >Thanks, >Jonathan R. >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com ------_=_NextPart_001_01C3F9F9.63E954A7 Content-Type: text/plain; name="draft-boulton-sipping-message-receipt-00.txt" Content-Description: draft-boulton-sipping-message-receipt-00.txt Content-Disposition: attachment; filename="draft-boulton-sipping-message-receipt-00.txt" Content-Transfer-Encoding: base64 DQoNClNJUFBJTkcgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgQy4gQm91bHRvbg0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFViaXF1aXR5IFNvZnR3 YXJlIENvcnBvcmF0aW9uDQpFeHBpcmVzOiBBdWd1c3QgMjMsIDIwMDQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQS4gTmllbWkN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBOb2tpYQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1 YXJ5IDIzLCAyMDA0DQoNCg0KICAgICAgTWVzc2FnZSBEaXNwb3NpdGlvbiBO b3RpZmljYXRpb25zIGZvciB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFByb3RvY29sKFNJUCkNCiAgICAg ICAgICAgICAgICBkcmFmdC1ib3VsdG9uLXNpcHBpbmctbWVzc2FnZS1yZWNl aXB0LTAwDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBkb2N1 bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25m b3JtYW5jZSB3aXRoDQogICBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEw IG9mIFJGQzIwMjYuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2lu ZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBU YXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcg Z3JvdXBzLiBOb3RlIHRoYXQgb3RoZXINCiAgIGdyb3VwcyBtYXkgYWxzbyBk aXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0 cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMg dmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5 IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIg ZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gSXQgaXMgaW5hcHByb3ByaWF0 ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0 ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4g cHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQgaHR0cDovLw0KICAgd3d3Lmll dGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRoZSBsaXN0 IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUg YWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0 bWwuDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g QXVndXN0IDIzLCAyMDA0Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENv cHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDQpLiBBbGwg UmlnaHRzIFJlc2VydmVkLg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBhbiBleHRlbnNpb24gdG8gdGhlIFNlc3Npb24gSW5p dGlhdGlvbg0KICAgUHJvdG9jb2woU0lQKVs0XSB0byBhbGxvdyB0aGUgc3Rh dHVzIG9mIGEgJ3BhZ2VyIG1vZGUnIG1lc3NhZ2UgdG8gYmUNCiAgIGNvbnZl eWVkIHRvIHRoZSBvcmlnaW5hdG9yIG9uY2UgdGhlIFNJUCB0cmFuc2FjdGlv biBoYXMgYmVlbg0KICAgY29tcGxldGVkLiAgQSBwYWdlciBNb2RlIG1lc3Nh Z2UgZGVzY3JpYmVzIGEgc2Vzc2lvbi1sZXNzLCBvbmUgb2ZmLA0KICAgbWVz c2FnZSBleGNoYW5nZSB1c2luZyB0aGUgU0lQIE1FU1NBR0VbMl0gbWV0aG9k LiAgVGhpcyBleHRlbnNpb24gaXMNCiAgIHN0cm9uZ2x5IGxpbmtlZCB0byBz aW1pbGFyIGZ1bmN0aW9uYWxpdHkgcHJvdmlkZWQgZm9yIEUtTWFpbCBhbmQg U01TDQogICBzeXN0ZW1zLg0KDQoNCg0KDQoNCg0KQm91bHRvbiAmIE5pZW1p ICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjMsIDIwMDQgICAgICAgICAgICAg ICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg TUVTU0FHRSBSZWNlaXB0ICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMDQN Cg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICAxLiAgICBJbnRyb2R1Y3Rp b24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDMNCiAgIDIuICAgIFRlcm1pbm9sb2d5ICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgMy4g ICAgT3ZlcnZpZXcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAzLjEgICBNZXNzYWdlIFJlY2Vp cHQgRGlzcG9zaXRpb24gRm9ybWF0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDUNCiAgIDMuMiAgIGFwcGxpY2F0aW9uL3JlY2VpcHQtaW5mbyt4bWwg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgNC4gICAg VXNlciBBZ2VudCBDbGllbnQgQmVoYXZpb3IgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA1DQogICA1LiAgICBVc2VyIEFnZW50IFNlcnZl ciBCZWhhdmlvciAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDYNCiAgIDUuMSAgIFN5bnRheCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KICAgNS4xLjEgUmVj ZWlwdC1UbyBIZWFkZXIgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA2DQogICA1LjEuMiByZWNlaXB0LWluZm8gZm9ybWF0 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYN CiAgIDUuMiAgIFhNTCBTY2hlbWEgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgNi4gICAgVXNhZ2Ug RXhhbXBsZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA5DQogICA3LiAgICBSZWdpc3RyYXRpb24gb2YgeHh4eCBo ZWFkZXIgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAg IDguICAgIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgOS4gICAgSUFOQSBDb25z aWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA5DQogICAxMC4gICBBY2tub3dsZWRnZW1lbnRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgICAg ICAgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgICAgICAgSW5mb3JtYXRpdmUg UmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDEwDQogICAgICAgICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANCiAgICAgICAg IEludGVsbGVjdHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVu dHMgLiAuIC4gLiAuIC4gLiAxMQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkJvdWx0b24gJiBO aWVtaSAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIzLCAyMDA0ICAgICAgICAg ICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIE1FU1NBR0UgUmVjZWlwdCAgICAgICAgICAgICAgICBGZWJydWFyeSAy MDA0DQoNCg0KMS4gSW50cm9kdWN0aW9uDQoNCiAgIFRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBhbiBleHRlbnNpb24gdG8gdGhlIFNlc3Npb24gSW5pdGlhdGlv bg0KICAgUHJvdG9jb2woU0lQKSBmb3IgdGhlIHB1cnBvc2Ugb2YgcmVwb3J0 aW5nIHRoZSBzdGF0dXMgb2YgJ3BhZ2VyIG1vZGUnDQogICBtZXNzYWdlcyBv bmNlIHRoZSBTSVAgdHJhbnNhY3Rpb24gaGFzIGNvbXBsZXRlZC4gICdQYWdl ciBNb2RlJw0KICAgbWVzc2FnZXMgbWFrZSB1c2Ugb2YgdGhlIFNJUCBNRVNT QUdFIG1ldGhvZFsyXSB0byBwcm92aWRlICdvbmUtb2ZmJywNCiAgIHRleHQg c3R5bGUgbWVzc2FnaW5nLCBzaW1pbGFyIHRvIFNNUyBtZXNzYWdlcyBzZW50 IHRvZGF5LiAgVGhlIFNJUA0KICAgTUVTU0FHRSBtZXRob2Qgd2lsbCBiZSB1 c2VkIHRvIGNhcnJ5IHRoZSByZWNlaXB0IG5vdGlmaWNhdGlvbiByZXBvcnRz DQogICB0byB0aGUgcmVxdWVzdGluZyBjbGllbnQuICBUaGlzIG1lbW8gZGVm aW5lcyBhIG5ldyAncmVwb3J0IHR5cGUnIHRoYXQNCiAgIGlzIHRvIGJlIHVz ZWQgd2l0aGluIHRoZSAnbXVsdGlwYXJ0L3JlcG9ydCcgTUlNRSB0eXBlIGRl ZmluZWQgaW4gUkZDDQogICAxODkyWzVdIGZvciBjb252ZXlpbmcgdmFyeWlu ZyBNYWlsIHJlcG9ydHMuICBJbiB0aGUgY29udGV4dCBvZiB0aGlzDQogICBl eHRlbnNpb24sIHRoZSByZXBvcnQgdHlwZSBpcyB1c2VkIHRvIGNvbnZleSB0 aGUgZGlzcG9zaXRpb24gb2YNCiAgICdwYWdlci1tb2RlJyBtZXNzYWdlcyB3 aXRoaW4gdGhlIG5ldHdvcmsgdXNpbmcgU0lQLg0KDQogICBUaGlzIGRyYWZ0 IGlkZW50aWZpZXMgYSBmZXcgc2NlbmFyaW9zIHdoZXJlIHRoaXMgZnVuY3Rp b25hbGl0eSBtaWdodA0KICAgYmUgdXNlZnVsOi0NCg0KICAgTWVzc2FnZSBk ZWxpdmVyeSAtIFRoZSByZWNlaXB0IG9mIGEgcG9zaXRpdmUgcmVzcG9uc2Ug dG8gYSAncGFnZXINCiAgIG1vZGUnIG1lc3NhZ2UgZG9lcyBub3QgZ3VhcmFu dGVlIHRoYXQgaXQgaGFzIGJlZW4gZGVsaXZlcmVkIHRvIHRoZQ0KICAgcmVx dWlyZWQgZW5kIHBvaW50LiAgSWYgYW4gZW5kcG9pbnQgaXMgdHVybmVkIG9m ZiBpdCB3aWxsIGJlIHN0b3JlZA0KICAgaW4gYSAnbWVzc2FnZS1mb3J3YXJk JyBkZXZpY2UgdGhhdCBkZWxpdmVycyBvbmNlIHRoZSBlbmRwb2ludCBpcw0K ICAgdHVybmVkIG9uLg0KDQogICBNZXNzYWdlIHJlYWQgLSBPbmNlIGEgJ3Bh Z2VyIG1vZGUnIG1lc3NhZ2UgaGFzIGJlZW4gZGVsaXZlcmVkIHRvIHRoZQ0K ICAgcmVjaXBpZW50LCB0aGUgaW5pdGlhdG9yIGNhbiByZXF1ZXN0IGluZm9y bWF0aW9uIGluZm9ybWluZyB0aGF0IGl0DQogICBoYXMgYmVlbiBvcGVuZWQg YW5kIHJlYWQuDQoNCiAgIE1lc3NhZ2UgZmFpbGVkIC0gVGhlIFNJUCB0cmFu c2FjdGlvbiBtaWdodCBoYXZlIGNvbXBsZXRlZCBidXQgdGhlDQogICAncGFn ZXIgbW9kZScgbWVzc2FnZSBtYXkgZmFpbCB0byBiZSBkZWxpdmVyZWQvcmVh ZCBieSB0aGUgaW50ZW5kZWQNCiAgIHJlY2lwaWVudC4NCg0KICAgQW4gaW1w b3J0YW50IGNvbmNlcHQgb2YgdGhpcyBleHRlbnNpb24gaW52b2x2ZXMgdGhl IHN1cHBvcnQgb2YgdGhlDQogICBHbG9iYWxseSBSb3V0YWJsZSBVQSBVUkko R1JVVSlbNl0gbWVjaGFuaXNtIGF0IHRoZSBvcmlnaW5hdGluZw0KICAgZW5k cG9pbnQuICBBIFVzZXIgQWdlbnQgU2VydmVyIChVQUMpIGNvbnZleWluZyBz dXBwb3J0IGZvciB0aGlzDQogICBwYWNrYWdlIFNIT1VMRCBzdXBwb3J0IHRo ZSBHUlVVIG1lY2hhbmlzbSBmb3IgcHVibGlzaGluZyBhIGdsb2JhbGx5DQog ICByb3V0YWJsZSBVUkkncy4gIFRoaXMgbWVtbyBkZWZpbmVzIGEgbmV3IFNJ UCBoZWFkZXIgJ1JlY2VpcHQtVG8nDQogICB3aGljaCBTSE9VTEQgY29udGFp biBhIEdSVVUuICBUaGUgVXNlciBBZ2VudCBDbGllbnQgKFVBQykgcmVxdWVz dGluZw0KICAgbWVzc2FnZSByZWNlaXB0IG5vdGlmaWNhdGlvbiBuZWVkcyB0 byBndWFyYW50ZWUgdGhhdCB0aGUgbm90aWZpY2F0aW9uDQogICB3aWxsIHJl YWNoIHRoZSBjb3JyZWN0IGluc3RhbmNlIG9mIGEgVUFDLiAgVGhpcyBpcyBh IEdSVVUuICBUaGUgVUFTDQogICB3aWxsIHVzZSB0aGUgR1JVVSBhZGRyZXNz IHN1cHBsaWVkIGFzIHRoZSBtYWluIHJlc291cmNlIGZvciB0aGUNCiAgIHJl Y2VpcHQgbm90aWZpY2F0aW9uLiAgQ29uc2VxdWVudGx5LCBhIFVBQyBpc3N1 aW5nIGEgR1JVVSBNQVkgaW5jbHVkZQ0KICAgdGhlICdncmlkJyBwYXJhbWV0 ZXIgYXMgZGVmaW5lZCBpbiB0aGUgR1JVVSBtZWNoYW5pc21bNl0uICBUaGlz DQogICBlbmFibGVzIGEgVUFDIHRvIGFzc29jaWF0ZSBpbmNvbWluZyBub3Rp ZmljYXRpb24gcmVjZWlwdHMgd2l0aCB0aGUNCiAgIG9yaWdpbmFsICdwYWdl ciBtb2RlJyBtZXNzYWdlcy4NCg0KMi4gVGVybWlub2xvZ3kNCg0KICAgSW4g dGhpcyBkb2N1bWVudCwgdGhlIGtleSB3b3JkcyAnTVVTVCcsICdNVVNUIE5P VCcsICdSRVFVSVJFRCcsDQoNCg0KDQpCb3VsdG9uICYgTmllbWkgICAgICAg ICBFeHBpcmVzIEF1Z3VzdCAyMywgMjAwNCAgICAgICAgICAgICAgICAgW1Bh Z2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBNRVNTQUdF IFJlY2VpcHQgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAwNA0KDQoNCiAg ICdTSEFMTCcsICdTSEFMTE5PVCcsICdTSE9VTEQnLCAnU0hPVUxETk9UJywg J1JFQ09NTUVOREVEJywgJ01BWScsIGFuZA0KICAgJ09QVElPTkFMJyBhcmUg dG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5WzFd IGFuZA0KICAgaW5kaWNhdGUgcmVxdWlyZW1lbnQgbGV2ZWxzIGZvciBjb21w bGlhbnQgU0lQIGltcGxlbWVudGF0aW9ucy4NCg0KICAgQWRkaXRpb25hbGx5 LCB3ZSBkZWZpbmUgdGhlIGZvbGxvd2luZyB0ZXJtczoNCg0KICAgVUFDOg0K DQogICBVQVM6DQoNCiAgIEdSVVU6DQoNCiAgIFBhZ2VyIE1vZGU6DQoNCjMu IE92ZXJ2aWV3DQoNCiAgIFRoZSBleHRlbnNpb24gZGVzY3JpYmVkIGluIHRo aXMgZG9jdW1lbnQgYWxsb3dzIGEgY2xpZW50IGlzc3VpbmcgYQ0KICAgJ3Bh Z2VyIG1vZGUnIG1lc3NhZ2UgdG8gb2J0YWluIHN1YnNlcXVlbnQgaW5mb3Jt YXRpb24gaW5kaWNhdGluZw0KICAgc3RhdHVzIHdpdGhpbiB0aGUgbmV0d29y ay4gIEEgVUFDIHdpbGwgY29uc3RydWN0IGEgc3RhbmRhcmQgU0lQDQogICBN RVNTQUdFIGFzIG91dGxpbmVkIGluIFJGQzM0MjhbMl0uICBJdCBpbmNsdWRl cyBhIFNJUCBTdXBwb3J0ZWQNCiAgIGhlYWRlciBjb250YWluaW5nIHRoZSBv cHRpb24gdGFnICdtZXNzYWdlLXJlY2VpcHQnLCBpbmRpY2F0aW5nDQogICBz dXBwb3J0IGZvciB0aGlzIGV4dGVuc2lvbi4gIFRoZSBVQUMgd2lsbCBhbHNv IGluY2x1ZGUgYSBSZWNlaXB0LVRvDQogICBoZWFkZXIgZmllbGQgaWYgaXQg Y29udmV5cyBzdXBwb3J0IGZvciB0aGlzIGV4dGVuc2lvbi4gIFRoaXMgY29u dGFpbnMNCiAgIGEgU0lQIFVSSSBpbmRpY2F0aW5nIHRoZSBkZXN0aW5hdGlv biB0byB3aGljaCByZWNlaXB0IG1lc3NhZ2VzIHNob3VsZA0KICAgYmUgc2Vu dC4gIE9uY2UgY29uc3RydWN0ZWQgdGhlIE1FU1NBR0UgaXMgc2VudCBhcyBw ZXIgbm9ybWFsIFNJUA0KICAgcmVxdWVzdCBydWxlcyBvdXRsaW5lZCBpbiBS RkMzMjYxWzRdLiAgT24gcmVjZWl2aW5nIGEgJ3BhZ2VyIG1vZGUnDQogICBt ZXNzYWdlIHRoZSByZWNlaXZpbmcgZW5kcG9pbnQoVUFTKSB3aWxsIHJlc3Bv bmQgd2l0aCBhIDIwMCBjbGFzcw0KICAgcmVzcG9uc2UgaWYgc3VjY2Vzc2Z1 bC4gIElmIHRoaXMgZXh0ZW5zaW9uIGlzIHN1cHBvcnRlZCwgdGhlIHJlc3Bv bnNlDQogICB3aWxsIGNvbnRhaW4gYSBTSVAgUmVxdWlyZSBoZWFkZXIgY29u dGFpbmluZyB0aGUgdmFsdWUNCiAgICdtZXNzYWdlLXJlY2VpcHQnLiAgVGhp cyBjb252ZXlzIHN1cHBvcnQgdG8gdGhlIFVBQyB3aG8gY29uc3RydWN0ZWQN CiAgIHRoZSAncGFnZXIgbW9kZScgbWVzc2FnZS4gIEl0IGlzIG5vdyB0aGUg cm9sZSBvZiB0aGUgVUFTIHRvIHJlcG9ydA0KICAgdGhlIHN0YXR1cyBvZiB0 aGUgJ3BhZ2VyIG1vZGUnIG1lc3NhZ2UgYnkgaXNzdWluZyBzdWJzZXF1ZW50 ICdwYWdlcg0KICAgbW9kZScgbWVzc2FnZXMgdXNpbmcgdGhlIFNJUCBNRVNT QUdFIG1ldGhvZCBjb250YWluaW5nIHRoZSBwYXlsb2FkDQogICBkZXNjcmli ZWQgaW4gc2VjdGlvbiA3IG9mIHRoaXMgZXh0ZW5zaW9uLiAgVGhlIHRhcmdl dCBvZiB0aGlzIHJlY2VpcHQNCiAgIGlzIG9idGFpbmVkIGZyb20gdGhlIFJl Y2VpcHQtVG8gaGVhZGVyIGFsc28gb3V0bGluZWQgaW4gc2VjdGlvbiA3Lg0K ICAgVGhlIHBheWxvYWQgYWxsb3dzIGVub3VnaCBpbmZvcm1hdGlvbiBmb3Ig dGhlIFVBQyB0byByZW5kZXIgdGhlDQogICBpbmZvcm1hdGlvbiB0byB0aGUg dXNlciB3aXRob3V0IGhhdmluZyB0byBob2xkIGFueSBhc3NvY2lhdGVkIHN0 YXRlDQogICBmb3Igb3JpZ2luYWwgJ3BhZ2VyIG1vZGUnIG1lc3NhZ2UuICBU aGlzIGlzIGV4dHJlbWVseSBhZHZhbnRhZ2VvdXMgaW4NCiAgIGxvdyBtZW1v cnkgY2FwYWNpdHkgY2xpZW50cy4gIElmIHRoZSBVQUMgd2lzaGVzIHRvIGV4 cGxpY2l0bHkNCiAgIGFzc29jaWF0ZSBhbiBpbmNvbWluZyByZWNlaXB0IHRv IGFuIG9yaWdpbmFsICdwYWdlciBtb2RlJyBtZXNzYWdlIGl0DQogICBjYW4g dXNlIHRoZSBleGlzdGFuY2Ugb2YgYSAnZ3JpZCcgcGFyYW1ldGVyIGluIHRo ZSBHUlVVIFVSSSBhcyB0aGUNCiAgIHVuaXF1ZSBtZXNzYWdlIGlkZW50aWZp ZXIuICBUaGUgdXNlIG9mIHRoZSAnZ3JpZCcgcGFyYW1ldGVyIGlzDQogICBv dXRsaW5lZCBpbiBkZXRhaWwgaW4gdGhlIEdSVVUgc3BlY2lmaWNhdGlvbls2 XS4gIE9uIHJlY2VpdmluZyB0aGUNCiAgIHJlY2VpcHQsIHRoZSBjbGllbnQg aXMgZnJlZSB0byByZW5kZXIgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp bg0KICAgdGhlIHBheWxvYWQuICBEdWUgdG8gdGhlIHN0YXRlbGVzcyBuYXR1 cmUgb2YgdGhlIHJlY2VpcHQgbWVjaGFuaXNtLA0KICAgdGhlcmUgaXMgbm8g bmVlZCB0byBzcGVjaWZ5IGEgZGVmYXVsdCBwZXJpb2QgZm9yIHdoaWNoIGEg cmVjZWlwdCBpcw0KICAgdmFsaWQuICBPbmx5IHdoZW4gYXBwbGljYXRpb25z IGFyZSBzdG9yaW5nIHN0YXRlIHNob3VsZCB0aGlzIG9jY3VyDQogICBhbmQg aXQgd291bGQgYmUgYW4gaW1wbGVtZW50YXRpb24gc3BlY2lmaWMgZGVjaXNp b24uDQoNCg0KDQpCb3VsdG9uICYgTmllbWkgICAgICAgICBFeHBpcmVzIEF1 Z3VzdCAyMywgMjAwNCAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBNRVNTQUdFIFJlY2VpcHQgICAg ICAgICAgICAgICAgRmVicnVhcnkgMjAwNA0KDQoNCjMuMSBNZXNzYWdlIFJl Y2VpcHQgRGlzcG9zaXRpb24gRm9ybWF0DQoNCiAgIEEgbWVzc2FnZSByZWNl aXB0IGlzIE1JTUUgdHlwZSB3aXRoIGEgdG9wIGxldmVsIGNvbnRlbnQtdHlw ZSBvZg0KICAgbXVsdGlwYXJ0L3JlcG9ydCBhcyBkZWZpbmVkIGluIFJGQyAx ODkyWzVdLiAgV2hlbiB1c2luZyB0aGUNCiAgIG11bHRpcGFydC9yZXBvcnQg Y29udGVudC10eXBlIHRoZSBmb2xsb3dpbmcgTVVTVCBiZSBvYmV5ZWQ6LQ0K DQogICBhKSBUaGUgcmVwb3J0LXR5cGUgcGFyYW1ldGVyIGZvciB0aGUgbXVs dGlwYXJ0L3JlcG9ydCBjb250ZW50IGlzDQogICBhcHBsaWNhdGlvbi9yZWNl aXB0LWluZm8reG1sLg0KDQogICBiKSAgVGhlIGZpcnN0IGNvbXBvbmVudCBv ZiB0aGUgbXVsdGlwYXJ0L3JlcG9ydCBjb250YWlucyBhDQogICBodW1hbi1y ZWFkYWJsZSBleHBsYW5hdGlvbiBvZiB0aGUgbWVzc2FnZS1yZWNlaXB0LCBh cyBkZXRhaWxlZCBpbiBSRkMNCiAgIDE4OTJbNV0uDQoNCiAgIGMpICBUaGUg c2Vjb25kIGNvbXBvbmVudCBvZiB0aGUgbXVsdGlwYXJ0L3JlcG9ydCBjb250 YWlucw0KICAgbWVzc2FnZS1yZWNlaXB0IGluZm9ybWF0aW9uIGluIHRoZSBm b3JtYXQgYXBwbGljYXRpb24vDQogICByZWNlaXB0LWluZm8reG1sLCBkZXNj cmliZWQgaW4gc2VjdGlvbiAzLjIgb2YgdGhpcyBleHRlbnNpb24uDQoNCiAg IGQpICBUaGUgdGhpcmQgY29tcG9uZW50IG9mIHRoZSBtdWx0aXBhcnQvcmVw b3J0IGNvbnRhaW5zIGEgY29weShvcg0KICAgcG9ydGlvbikgb2YgdGhlIG9y aWdpbmFsIG1lc3NhZ2UuICBUaGlzIGNvbXBvbmVudCBpcyBvcHRpb25hbC4N Cg0KMy4yIGFwcGxpY2F0aW9uL3JlY2VpcHQtaW5mbyt4bWwNCg0KICAgSW4g dGhpcyBleHRlbnNpb24sIHRoZSBib2R5IG9mIHRoZSBtZXNzYWdlIHJlY2Vp cHQgY29udGFpbnMgYSBtZXNzYWdlDQogICByZWNpZXB0IGRvY3VtZW50LiBU aGlzIGRvY3VtZW50IHByb3ZpZGVzIGluZm9ybWF0aW9uIHJlZ2FyZGluZyB0 aGUNCiAgIHN0YXRlIG9mIGEgc2VsZWN0ZWQgJ3BhZ2VyIG1vZGUnIG1lc3Nh Z2UgaW4gdGhlIG5ldHdvcmsuIFVzZXMgb2YgdGhpcw0KICAgZXh0ZW5zaW9u IE1VU1Qgc3VwcG9ydCB0aGUgImFwcGxpY2F0aW9uL3JlY2VpcHQtaW5mbyt4 bWwiIGRhdGEgZm9ybWF0DQogICBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjUu Mi4gVGhlIFNJUCByZXF1ZXN0IE1BWSBjb250YWluIGFuIEFjY2VwdA0KICAg aGVhZGVyIGZpZWxkLiBJZiBubyBzdWNoIGhlYWRlciBmaWVsZCBpcyBwcmVz ZW50LCBhIGRlZmF1bHQgdmFsdWUgb2YNCiAgICJhcHBsaWNhdGlvbi9yZWNl aXB0LWluZm8reG1sIiBpcyBhc3N1bWVkLiBJZiB0aGUgaGVhZGVyIGZpZWxk IGlzDQogICBwcmVzZW50LCBpdCBNVVNUIGluY2x1ZGUgImFwcGxpY2F0aW9u L3JlY2VpcHQtaW5mbyt4bWwiLCBhbmQgTUFZDQogICBpbmNsdWRlIGFueSBv dGhlciB0eXBlcyBjYXBhYmxlIG9mIHJlcHJlc2VudGluZyBtZXNzYWdlIHN0 YXRlLg0KDQo0LiBVc2VyIEFnZW50IENsaWVudCBCZWhhdmlvcg0KDQogICBB IFVzZXIgQWdlbnQgQ2xpZW50KFVBQykgdGhhdCBzdXBwb3J0cyB0aGlzIGV4 dGVuc2lvbiBNVVNUIGluY2x1ZGUgYQ0KICAgU3VwcG9ydGVkIGhlYWRlciBp biBlYWNoIE1FU1NBR0UgcmVxdWVzdCBpZiBhIG1lc3NhZ2UtcmVjZWlwdCBp cw0KICAgcmVxdWlyZWQuIFRoZSBvcHRpb24gdGFnIGZvciB0aGlzIGV4dGVu c2lvbiBpcyAnbWVzc2FnZS1yZWNlaXB0Jy4NCiAgIFRoZSBVQUMgTUFZIGlu Y2x1ZGUgYSBSZXF1aXJlIGhlYWRlciBmaWVsZCBpbiB0aGUgcmVxdWVzdCB3 aXRoIHRoZQ0KICAgdmFsdWUgJ21lc3NhZ2UtcmVjZWlwdCcgdG8gaW5kaWNh dGUgdGhhdCB0aGUgVUFTIG11c3Qgc3VwcG9ydCB0aGlzDQogICBleHRlbnNp b24gdG8gcHJvY2VzcyB0aGUgcmVxdWVzdC4gIEEgVUFDIHN1cHBvcnRpbmcg dGhpcyBleHRlbnNpb24NCiAgIE1VU1QgYWxzbyBpbmNsdWRlIGEgJ1JlY2Vp cHQtVG8nIGhlYWRlciBkZXNjcmliZWQgaW4gc2VjdGlvbiA1LjEuMSwNCiAg IHByb3ZpZGluZyB0aGUgYWRkcmVzcyBmb3IgZGVsaXZlcnkgb2YgbWVzc2Fn ZSByZWNlaXB0cy4gSWYNCiAgIG5lZ290aWF0aW9uIGlzIHN1Y2Nlc3NmdWwg dGhlIFVBQyBNVVNUIGJlIHByZXBhcmVkIHRvIHJlY2VpdmUgbWVzc2FnZQ0K ICAgcmVjZWlwdHMgYXMgaW5kaWNhdGVkIGluIHRoZSBhZGRyZXNzIHN1cHBs aWVkIGluIHRoZSAnUmVjZWlwdC1UbycNCiAgIGhlYWRlci4NCg0KDQoNCg0K DQoNCkJvdWx0b24gJiBOaWVtaSAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIz LCAyMDA0ICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgIE1FU1NBR0UgUmVjZWlwdCAgICAgICAgICAg ICAgICBGZWJydWFyeSAyMDA0DQoNCg0KNS4gVXNlciBBZ2VudCBTZXJ2ZXIg QmVoYXZpb3INCg0KICAgSWYgYW4gaW5jb21pbmcgcmVxdWVzdCBjb250YWlu cyBhIFN1cHBvcnRlZCBoZWFkZXIgZmllbGQgd2l0aCBhIHZhbHVlDQogICAn bWVzc2FnZS1yZWNlaXB0JyBhbmQgYSBSZWNlaXB0LVRvIGhlYWRlciwgdGhl IFVBUyBNQVkgY29uZmlybQ0KICAgc3VwcG9ydCBmb3IgdGhpcyBleHRlbnNp b24gaW4gdGhlIDJ4eCByZXNwb25zZSBieSBpbmNsdWRpbmcgYSBSZXF1aXJl DQogICBoZWFkZXIgaW5kaWNhdGluZyB0aGUgb3B0aW9ucyB0YWcgZm9yIHRo aXMgZXh0ZW5zaW9uLiAgVGhlIFVBUyBNQVkNCiAgIGFsc28gcmVzcG9uZCB3 aXRoIGEgMnh4IHRvIHRoZSByZXF1ZXN0IHdpdGhvdXQgc2hvd2luZyBzdXBw b3J0IGZvcg0KICAgdGhpcyBleHRlbnNpb24uIFVubGVzcyBsb2NhbCBwb2xp Y3kgZGV0ZXJtaW5lcyB0aGUgb3Bwb3NpdGUsIHRoZQ0KICAgc3VwcG9ydCBm b3IgdGhpcyBleHRlbnNpb24gU0hPVUxEIE5PVCBpbXBhY3QgdGhlIHN1Y2Nl c3Mgb3IgZmFpbHVyZQ0KICAgb2YgdGhlIG9yaWdpbmFsIFNJUCB0cmFuc2Fj dGlvbi4NCg0KNS4xIFN5bnRheA0KDQo1LjEuMSBSZWNlaXB0LVRvIEhlYWRl cg0KDQogICBSZWNlaXB0LVRvIGlzIGEgcmVxdWVzdCBoZWFkZXIgZmllbGQg KHJlcXVlc3QtaGVhZGVyKSBhcyBkZWZpbmVkDQogICBieVs0XS4gIEl0IG9u bHkgYXBwZWFycyBpbiBhIE1FU1NBR0UgcmVxdWVzdCBhbmQgc3VwcGxpZXMg YSBVUkwgdG8NCiAgIHRoZSBzb3VyY2UgZm9yIHN1YnNlcXVlbnQgbWVzc2Fn ZSByZWNlaXB0cy4gIEl0IFNIT1VMRCBOT1QgYXBwZWFyIGluDQogICBhIE1F U1NBR0UgcmVxdWVzdCB0aGF0IGlzIGdlbmVyYXRlZCwgYXMgcGVyIHRoaXMg c3BlY2lmaWNhdGlvbiwgZm9yDQogICB0aGUgcHVycG9zZSBvZiBjb252ZXlp bmcgbWVzc2FnZSByZWNlaXB0IGluZm9ybWF0aW9uLg0KDQogICBSZWNlaXB0 LVRvID0gIlJlY2VpcHQtVG8iIEhDT0xPTiAoIG5hbWUtYWRkciAvIGFkZHIt c3BlYyApICogKFNFTUkNCiAgIGdlbmVyaWMtcGFyYW0pDQoNCiAgIFRoZSBm b2xsb3dpbmcgc2hvdWxkIGJlIGludGVycHJldGVkIGFzIGlmIGl0IGFwcGVh cmVkIGluIFRhYmxlIDMgb2YNCiAgIFJGQyAzMjYxLg0KDQogICBIZWFkZXIg ZmllbGQgICAgICAgICAgICAgIHdoZXJlICAgICAgIHByb3h5IEFDSyBCWUUg Q0FOIElOViBPUFQgUkVHDQogICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog ICBSZWNlaXB0LVRvICAgICAgICAgICAgICAgICAgUiAgICAgICAgICAgICAg ICAtICAgLSAgIC0gICAtICAgLSAgIC0NCg0KICAgVGhlIFJlY2VpcHQtVG8g aGVhZGVyIHdoZW4gdXNlZCBpbiB0aGUgY29udGV4dCBvZiB0aGlzIHNwZWNp ZmljYXRpb24NCiAgIE1VU1QgdXNlIGVpdGhlciB0aGUgU0lQIG9yIFNJUFMg VVJJIHNjaGVtZXMuDQoNCiAgIEV4YW1wbGUNCg0KICAgUmVjZWlwdC1Ubzog c2lwOmFsaWNlQGF0bGFudGEuZXhhbXBsZS5jb20NCg0KNS4xLjIgcmVjZWlw dC1pbmZvIGZvcm1hdA0KDQogICBNZXNzYWdlIHJlY2VpcHQgaW5mb3JtYXRp b24gaXMgYW4gWE1MIGRvY3VtZW50IFtpbmMuIHJlZl0gdGhhdCBNVVNUDQog ICBiZSB3ZWxsLWZvcm1lZCBhbmQgU0hPVUxEIGJlIHZhbGlkLg0KDQo1LjEu Mi4xIDxkaXNwb3NpdGlvbi1yZXBvcnQ+IGVsZW1lbnQNCg0KICAgVGhlIHJv dXRlIGVsZW1lbnQgb2YgYW4gImFwcGxpY2F0aW9uL3JlY2VpcHQtaW5mbyt4 bWwiIGRvY3VtZW50LiBUaGlzDQogICBlbGVtZW50IGNvbnNpc3RzIG9mIHR3 byBtYW5kYXRvcnkgZWxlbWVudHMgPG1lc3NhZ2UtaW5mb3JtYXRpb24+LA0K ICAgPG1lc3NhZ2UtZGlzcG9zaXRpb24+IGFuZCBvbmUgb3B0aW9uYWwgZWxl bWVudA0KDQoNCg0KQm91bHRvbiAmIE5pZW1pICAgICAgICAgRXhwaXJlcyBB dWd1c3QgMjMsIDIwMDQgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgTUVTU0FHRSBSZWNlaXB0ICAg ICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMDQNCg0KDQogICA8ZGlzcG9zaXRp b24tZXZlbnQtdGltZT4uDQoNCjUuMS4yLjIgPG1lc3NhZ2UtaW5mb3JtYXRp b24+IGVsZW1lbnQNCg0KICAgVGhpcyBlbGVtZW50IHByb3ZpZGVzIGltcG9y dGFudCBzaWduYWxpbmcgaW5mb3JtYXRpb24gdGFrZW4gZnJvbSB0aGUNCiAg IFNJUCBtZXNzYWdlIHJlcXVlc3QgcmVjZWl2ZWQuICBUaGUgZm9sbG93aW5n IHN1Yi1lbGVtZW50cyBhcmUNCiAgIGluY2x1ZGVkIGluIGEgbWVzc2FnZSBy ZWNlaXB0Og0KDQogICA8b3JpZ2luYWwtZGVzdGluYXRpb24+IC0gVGhpcyBk aXNwbGF5cyB0aGUgb3JpZ2luYWwgZGVzdGluYXRpb24gb2YNCiAgIHRoZSBT SVAgcmVxdWVzdCBhbmQgc2hvdWxkIGJlIHBvcHVsYXRlZCBieSB0aGUgY2xp ZW50IGNvbnN0cnVjdGluZw0KICAgdGhlIG1lc3NhZ2UgcmVjZWlwdCB1c2lu ZyB0aGUgU0lQICdUbycgaGVhZGVyIGZyb20gdGhlIHJlY2VpdmVkDQogICBN RVNTQUdFLg0KDQogICA8ZmluYWwtZGVzdGluYXRpb24+IC0gVGhpcyBkaXNw bGF5cyB0aGUgZmluYWwgZGVzdGluYXRpb24gb2YgdGhlIFNJUA0KICAgcmVx dWVzdCBhbmQgc2hvdWxkIGJlIHBvcHVsYXRlZCBieSB0aGUgY2xpZW50IGNv bnN0cnVjdGluZyB0aGUNCiAgIG1lc3NhZ2UgcmVjZWlwdCB1c2luZyB0aGUg U0lQIFJlcXVlc3QgVVJJKFItVVJJKSBmcm9tIHRoZSByZWNlaXZlZA0KICAg TUVTU0FHRS4NCg0KICAgPG1lc3NhZ2UtaWQ+IC0gVGhpcyBkaXNwbGF5cyB0 aGUgbWVzc2FnZSBJRCBvZiB0aGUgU0lQIHJlcXVlc3QgYW5kDQogICBzaG91 bGQgYmUgcG9wdWxhdGVkIGJ5IHRoZSBjbGllbnQgY29uc3RydWN0aW5nIHRo ZSBtZXNzYWdlIHJlY2VpcHQNCiAgIHVzaW5nIHRoZSBTSVAgQ2FsbC1JRCBo ZWFkZXIgZnJvbSB0aGUgcmVjZWl2ZWQgTUVTU0FHRS4NCg0KNS4xLjIuMyA8 bWVzc2FnZS1kaXNwb3NpdGlvbj4gZWxlbWVudA0KDQogICBUaGlzIGVsZW1l bnQgZGVzY3JpYmVzIHRoZSBtZXNzYWdlIGRpc3Bvc2l0aW9uIGV2ZW50IHRo YXQgaGFzIHRha2VuDQogICBwbGFjZS4gIEl0IGFsbG93cyBhIG51bWJlciBv ZiB2YWx1ZXM6LQ0KDQogICA8ZGlzcGxheWVkPiAtIFRoaXMgcGFnZXItbW9k ZSBtZXNzYWdlIGhhcyBiZWVuIHJlYWQgYnkgYSByZWNpcGllbnQNCiAgIHdo byBoYXMgYWNjZXNzIHRvIHRoZSBpbnRlbmRlZCBkZXN0aW5hdGlvbnMgcmVz b3VyY2UuDQoNCiAgIDxkaXNwYXRjaGVkPiAtIFRoZSBwYWdlci1tb2RlIG1l c3NhZ2UgaGFzIGJlZW4gZm9yd2FyZGVkIHdpdGhvdXQNCiAgIG5lY2Vzc2Fy aWx5IGhhdmluZyBiZWVuIHByZXZpb3VzbHkgZGlzcGxheWVkIHRvIHRoZSB1 c2VyLg0KDQogICA8cHJvY2Vzc2VkPiAtIFRoZSBwYWdlci1tb2RlIG1lc3Nh Z2UgaGFzIGJlZW4gcHJvY2Vzc2VkIGluIHNvbWUNCiAgIG1hbm5lci4gIFRo aXMgY291bGQgaW5jbHVkZSBmdW5jdGlvbnMgc3VjaCBhcyAnc3RvcmUtZm9y d2FyZCcgc2VydmVycw0KICAgZXRjLg0KDQogICA8ZGVsZXRlZD4gLSBUaGUg cGFnZXItbW9kZSBtZXNzYWdlIGhhcyBiZWVuIGRlbGV0ZWQuICBUaGUgcmVj aXBpZW50DQogICBtYXkgb3IgbWF5IG5vdCBoYXZlIHNlZW4gdGhlIG1lc3Nh Z2UuDQoNCiAgIDxkZW5pZWQ+IC0gVGhlIHJlY2lwaWVudCBvZiBhIHBhZ2Vy LW1vZGUgbWVzc2FnZSBkb2VzIG5vdCB3aXNoIHRoZQ0KICAgc2VuZGVyIHRv IGJlIGluZm9ybWVkIG9mIHRoZSBtZXNzYWdlJ3MgZGlzcG9zaXRpb24uICBB IFVBIG1heSBhbHNvDQogICBzaWxlbnRseSBpZ25vcmUgbWVzc2FnZSBkaXNw b3NpdGlvbiByZXF1ZXN0cyBpbiB0aGlzIHNpdHVhdGlvbi4NCg0KICAgPGZh aWxlZD4gLSBBIGZhaWx1cmUgb2NjdXJyZWQgdGhhdCBwcmV2ZW50ZWQgdGhl IHByb3BlciBnZW5lcmF0aW9uIG9mDQogICBhIHBhZ2VyLW1vZGUgbWVzc2Fn ZSByZWNlaXB0Lg0KDQoNCg0KDQoNCkJvdWx0b24gJiBOaWVtaSAgICAgICAg IEV4cGlyZXMgQXVndXN0IDIzLCAyMDA0ICAgICAgICAgICAgICAgICBbUGFn ZSA3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIE1FU1NBR0Ug UmVjZWlwdCAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDA0DQoNCg0KNS4x LjIuNCA8ZGlzcG9zaXRpb24tZXZlbnQtdGltZT4gZWxlbWVudA0KDQogICBU aGlzIG9wdGlvbmFsIGVsZW1lbnQgaW5kaWNhdGVzIHRoZSB0aW1lIGF0IHdo aWNoIHRoZSBkaXNwb3NpdGlvbg0KICAgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoZSBtZXNzYWdlIHJlY2VpcHQgb2NjdXJlZC4NCg0KNS4yIFhNTCBT Y2hlbWENCg0KDQogICA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJV VEYtOCI/Pg0KICAgICAgPHhzOnNjaGVtYQ0KICAgICAgICB0YXJnZXROYW1l c3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bWVzc2FnZS1yZWNlaXB0 LWluZm8iDQogICAgICAgIHhtbG5zOnhzPSJodHRwOi8vd3d3LnczLm9yZy8y MDAxL1hNTFNjaGVtYSINCiAgICAgICAgeG1sbnM6dG5zPSJ1cm46aWV0Zjpw YXJhbXM6eG1sOm5zOm1lc3NhZ2UtcmVjZWlwdC1pbmZvIg0KICAgICAgICBl bGVtZW50Rm9ybURlZmF1bHQ9InF1YWxpZmllZCINCiAgICAgICAgYXR0cmli dXRlRm9ybURlZmF1bHQ9InVucXVhbGlmaWVkIj4NCiAgICAgICAgPCEtLSBU aGlzIGltcG9ydCBicmluZ3MgaW4gdGhlIFhNTCBsYW5ndWFnZSBhdHRyaWJ1 dGUgeG1sOmxhbmctLT4NCiAgICAgICAgPHhzOmltcG9ydCBuYW1lc3BhY2U9 Imh0dHA6Ly93d3cudzMub3JnL1hNTC8xOTk4L25hbWVzcGFjZSINCiAgICAg ICAgICAgc2NoZW1hTG9jYXRpb249Imh0dHA6Ly93d3cudzMub3JnLzIwMDEv MDMveG1sLnhzZCIvPg0KDQogICAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0i ZGlzcG9zaXRpb24tcmVwb3J0Ij4NCiAgICAgICAgICAgIDx4czpjb21wbGV4 VHlwZT4NCiAgICAgICAgICAgICAgPHhzOnNlcXVlbmNlPg0KICAgICAgICAg ICAgICAgIDx4czplbGVtZW50IG5hbWU9Im1lc3NhZ2UtaW5mb3JtYXRpb24i IHR5cGU9Im5zOmluZm9ybWF0aW9uLXR5cGUiDQogICAgICAgICAgICAgICAg ICAgIG1pbk9jY3Vycz0iMSIgbWF4T2NjdXJzPSIxIj4NCiAgICAgICAgICAg ICAgICA8eHM6ZWxlbWVudCBuYW1lPSJtZXNzYWdlLWRpc3Bvc2l0aW9uIiB0 eXBlPSJuczpkaXNwb3NpdGlvbi10eXBlIg0KICAgICAgICAgICAgICAgICAg ICBtaW5PY2N1cnM9IjEiIG1heE9jY3Vycz0iMSI+DQogICAgICAgICAgICAg ICAgPHhzOmVsZW1lbnQgbmFtZT0iZGlzcG9zaXRpb24tZXZlbnQtdGltZSIg dHlwZT0ieHM6ZGF0ZVRpbWUiIGRlZmF1bHQ9IjAiDQogICAgICAgICAgICAg ICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIj4NCiAgICAgICAg ICAgICAgICA8eHM6YW55IG5hbWVzcGFjZT0iIyNvdGhlciIgcHJvY2Vzc0Nv bnRlbnRzPSJsYXgiIG1pbk9jY3Vycz0iMCINCiAgICAgICAgICAgICAgIG1h eE9jY3Vycz0idW5ib3VuZGVkIj4NCiAgICAgICAgICAgICAgPC94czpzZXF1 ZW5jZT4NCiAgICAgICAgICAgICA8L3hzOmNvbXBsZXhUeXBlPg0KICAgICAg ICAgICAgIDx4czphbnkgbmFtZXNwYWNlPSIjI290aGVyIiBwcm9jZXNzQ29u dGVudHM9ImxheCIgbWluT2NjdXJzPSIwIg0KICAgICAgICAgICAgICAgICBt YXhPY2N1cnM9InVuYm91bmRlZCI+DQogICAgICAgICAgPC94czplbGVtZW50 Pg0KDQogICAgICAgICA8eHM6c2ltcGxlVHlwZSBuYW1lPSJkaXNwb3NpdGlv bi10eXBlIj4NCiAgICAgICAgICA8eHM6cmVzdHJpY3Rpb24gYmFzZT0idG9r ZW4iPg0KICAgICAgICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJkaXNw bGF5ZWQiLz4NCiAgICAgICAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0i ZGlzcGF0Y2hlZCIvPg0KICAgICAgICAgICAgPHhzOmVudW1lcmF0aW9uIHZh bHVlPSJwcm9jZXNzZWQiLz4NCiAgICAgICAgICAgIDx4czplbnVtZXJhdGlv biB2YWx1ZT0iZGVsZXRlZCIvPg0KICAgICAgICAgICAgPHhzOmVudW1lcmF0 aW9uIHZhbHVlPSJkZW5pZWQiLz4NCiAgICAgICAgICAgIDx4czplbnVtZXJh dGlvbiB2YWx1ZT0iZmFpbGVkIi8+DQogICAgICAgICAgICA8eHM6ZW51bWVy YXRpb24gdmFsdWU9ImV4cGlyZWQiLz4NCiAgICAgICAgICA8L3hzOnJlc3Ry aWN0aW9uPg0KICAgICAgICAgPC94czpzaW1wbGVUeXBlPg0KDQoNCg0KDQpC b3VsdG9uICYgTmllbWkgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMywgMjAw NCAgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBNRVNTQUdFIFJlY2VpcHQgICAgICAgICAgICAgICAg RmVicnVhcnkgMjAwNA0KDQoNCiAgICAgICAgIDx4czpjb21wbGV4VHlwZSBu YW1lPSJpbmZvcm1hdGlvbi10eXBlIj4NCiAgICAgICAgICA8eHM6c2VxdWVu Y2U+DQogICAgICAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJvcmlnaW5hbC1k ZXN0aW5hdGlvbiIgdHlwZT0ieHM6YW55VVJJIg0KICAgICAgICAgICAgICAg ICAgICBtaW5PY2N1cnM9IjEiIG1heE9jY3Vycz0iMSI+DQogICAgICAgICAg ICA8eHM6ZWxlbWVudCBuYW1lPSJmaW5hbC1kZXN0aW5hdGlvbiIgdHlwZT0i eHM6YW55VVJJIg0KICAgICAgICAgICAgICAgICAgICBtaW5PY2N1cnM9IjEi IG1heE9jY3Vycz0iMSI+DQogICAgICAgICAgICA8eHM6ZWxlbWVudCBuYW1l PSJtZXNzYWdlLWlkIiB0eXBlPSJ4czp0b2tlbiINCiAgICAgICAgICAgICAg ICAgICAgbWluT2NjdXJzPSIxIiBtYXhPY2N1cnM9IjEiPg0KICAgICAgICAg IDwveHM6c2VxdWVuY2U+DQogICAgICAgICA8L3hzOmNvbXBsZXhUeXBlPg0K ICAgICAgPC94czpzY2hlbWE+DQoNCg0KDQo2LiBVc2FnZSBFeGFtcGxlDQoN Cg0KNy4gUmVnaXN0cmF0aW9uIG9mIHh4eHggaGVhZGVyDQoNCg0KOC4gU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KOS4gSUFOQSBDb25zaWRlcmF0aW9u cw0KDQoxMC4gQWNrbm93bGVkZ2VtZW50cw0KDQpOb3JtYXRpdmUgUmVmZXJl bmNlcw0KDQogICBbMV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1 c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudA0KICAgICAgICBM ZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQogICBb Ml0gIENhbXBiZWxsLCBCLiwgUm9zZW5iZXJnLCBKLiwgU2NodWx6cmlubmUs IEguLCBIdWl0ZW1hLCBDLiBhbmQgRC4NCiAgICAgICAgR3VybGUsICJTZXNz aW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgRXh0ZW5zaW9uIGZvciBJ bnN0YW50DQogICAgICAgIE1lc3NhZ2luZyIsIFJGQyAzNDI4LCBEZWNlbWJl ciAyMDAyLg0KDQogICBbM10gIEZyZWVkLCBOLiBhbmQgTi4gQm9yZW5zdGVp biwgIk11bHRpcHVycG9zZSBJbnRlcm5ldCBNYWlsDQogICAgICAgIEV4dGVu c2lvbnMgKE1JTUUpIFBhcnQgVHdvOiBNZWRpYSBUeXBlcyIsIFJGQyAyMDQ2 LCBOb3ZlbWJlcg0KICAgICAgICAxOTk2Lg0KDQogICBbNF0gIFJvc2VuYmVy ZywgSi4sIFNjaHVsenJpbm5lLCBILiwgQ2FtYXJpbGxvLCBHLiwgSm9obnN0 b24sIEEuLA0KICAgICAgICBQZXRlcnNvbiwgSi4sIFNwYXJrcywgUi4sIEhh bmRsZXksIE0uIGFuZCBFLiBTY2hvb2xlciwgIlNJUDoNCiAgICAgICAgU2Vz c2lvbiBJbml0aWF0aW9uIFByb3RvY29sIiwgUkZDIDMyNjEsIEp1bmUgMjAw Mi4NCg0KICAgWzVdICBWYXVkcmV1aWwsIEcuLCAiVGhlIE11bHRpcGFydC9S ZXBvcnQgQ29udGVudCBUeXBlIGZvciB0aGUNCiAgICAgICAgUmVwb3J0aW5n IG9mIE1haWwgU3lzdGVtIEFkbWluaXN0cmF0aXZlIE1lc3NhZ2VzIiwgUkZD IDE4OTIsDQogICAgICAgIEphbnVhcnkgMTk5Ni4NCg0KICAgWzZdICBSb3Nl bmJlcmcsIEouLCAiT2J0YWluaW5nIGFuZCBVc2luZyBHbG9iYWxseSBSb3V0 YWJsZSBVc2VyIEFnZW50DQoNCg0KDQpCb3VsdG9uICYgTmllbWkgICAgICAg ICBFeHBpcmVzIEF1Z3VzdCAyMywgMjAwNCAgICAgICAgICAgICAgICAgW1Bh Z2UgOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBNRVNTQUdF IFJlY2VpcHQgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAwNA0KDQoNCiAg ICAgICAgKFVBKSBVUklzIChHUlVVKSBpbiB0aGUgIFNlc3Npb24gSW5pdGlh dGlvbiBQcm90b2NvbCAoU0lQKSIsDQogICAgICAgIGRyYWZ0LXJvc2VuYmVy Zy1zaXAtZ3J1dS0wMSAod29yayBpbiBwcm9ncmVzcyksIERlY2VtYmVyIDIw MDMuDQoNCkluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KDQpBdXRob3JzJyBB ZGRyZXNzZXMNCg0KICAgQ2hyaXMgQm91bHRvbg0KICAgVWJpcXVpdHkgU29m dHdhcmUgQ29ycG9yYXRpb24NCiAgIExhbmdzdG9uZSBQYXJrDQogICBOZXdw b3J0LCBTb3V0aCBXYWxlcyAgTlANCg0KICAgRU1haWw6IGNib3VsdG9uQHVi aXF1aXR5Lm5ldA0KDQoNCiAgIEFraSBOaWVtaQ0KICAgTm9raWENCiAgIFAu Ty4gQm94IDMyMQ0KICAgTk9LSUEgR1JPVVAsIEZJTiAgMDAwNDUgIEZpbmxh bmQNCg0KICAgRU1haWw6IGFraS5uaWVtaUBub2tpYS5jb20NCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpCb3VsdG9uICYgTmllbWkgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAy MywgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAxMF0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBNRVNTQUdFIFJlY2VpcHQgICAgICAgICAg ICAgICAgRmVicnVhcnkgMjAwNA0KDQoNCkludGVsbGVjdHVhbCBQcm9wZXJ0 eSBTdGF0ZW1lbnQNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24g cmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIGlu dGVsbGVjdHVhbCBwcm9wZXJ0eSBvciBvdGhlciByaWdodHMgdGhhdCBtaWdo dCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRh dGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluDQog ICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxp Y2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5v dCBiZSBhdmFpbGFibGU7IG5laXRoZXIgZG9lcyBpdCByZXByZXNlbnQgdGhh dCBpdA0KICAgaGFzIG1hZGUgYW55IGVmZm9ydCB0byBpZGVudGlmeSBhbnkg c3VjaCByaWdodHMuIEluZm9ybWF0aW9uIG9uIHRoZQ0KICAgSUVURidzIHBy b2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBzdGFuZGFyZHMt dHJhY2sgYW5kDQogICBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9u IGNhbiBiZSBmb3VuZCBpbiBCQ1AtMTEuIENvcGllcyBvZg0KICAgY2xhaW1z IG9mIHJpZ2h0cyBtYWRlIGF2YWlsYWJsZSBmb3IgcHVibGljYXRpb24gYW5k IGFueSBhc3N1cmFuY2VzIG9mDQogICBsaWNlbnNlcyB0byBiZSBtYWRlIGF2 YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbiBhdHRlbXB0IG1hZGUgdG8N CiAgIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZv ciB0aGUgdXNlIG9mIHN1Y2gNCiAgIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBp bXBsZW1lbnRvcnMgb3IgdXNlcnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGNh bg0KICAgYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBTZWNyZXRhcmlhdC4N Cg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0 byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0cywg cGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9w cmlldGFyeQ0KICAgcmlnaHRzIHdoaWNoIG1heSBjb3ZlciB0ZWNobm9sb2d5 IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIHByYWN0aWNlDQogICB0aGlzIHN0 YW5kYXJkLiBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhl IElFVEYgRXhlY3V0aXZlDQogICBEaXJlY3Rvci4NCg0KDQpGdWxsIENvcHly aWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJu ZXQgU29jaWV0eSAoMjAwNCkuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuDQoNCiAg IFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUg Y29waWVkIGFuZCBmdXJuaXNoZWQgdG8NCiAgIG90aGVycywgYW5kIGRlcml2 YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVyd2lzZSBleHBs YWluIGl0DQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1h eSBiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQNCiAgIGFuZCBkaXN0 cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0cmlj dGlvbiBvZiBhbnkNCiAgIGtpbmQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3Zl IGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIGFyZQ0KICAg aW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdv cmtzLiBIb3dldmVyLCB0aGlzDQogICBkb2N1bWVudCBpdHNlbGYgbWF5IG5v dCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92aW5n DQogICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2VzIHRvIHRo ZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyDQogICBJbnRlcm5ldCBvcmdh bml6YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBv Zg0KICAgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2gg Y2FzZSB0aGUgcHJvY2VkdXJlcyBmb3INCiAgIGNvcHlyaWdodHMgZGVmaW5l ZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBiZQ0K ICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBp bnRvIGxhbmd1YWdlcyBvdGhlciB0aGFuDQogICBFbmdsaXNoLg0KDQogICBU aGUgbGltaXRlZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJw ZXR1YWwgYW5kIHdpbGwgbm90IGJlDQogICByZXZva2VkIGJ5IHRoZSBJbnRl cm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFzc2lnbmVlcy4N Cg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBoZXJlaW4gaXMgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFz aXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQg RU5HSU5FRVJJTkcNCiAgIFRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJS QU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORw0KICAgQlVU IE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0Yg VEhFIElORk9STUFUSU9ODQoNCg0KDQpCb3VsdG9uICYgTmllbWkgICAgICAg ICBFeHBpcmVzIEF1Z3VzdCAyMywgMjAwNCAgICAgICAgICAgICAgICBbUGFn ZSAxMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBNRVNTQUdF IFJlY2VpcHQgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAwNA0KDQoNCiAg IEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJ TVBMSUVEIFdBUlJBTlRJRVMgT0YNCiAgIE1FUkNIQU5UQUJJTElUWSBPUiBG SVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpBY2tub3ds ZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5j dGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQogICBJbnRlcm5l dCBTb2NpZXR5Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpCb3VsdG9uICYgTmllbWkgICAgICAgICBFeHBpcmVzIEF1Z3Vz dCAyMywgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCg0KDQo= ------_=_NextPart_001_01C3F9F9.63E954A7-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 06:40:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20231 for <sipping-archive@odin.ietf.org>; Mon, 23 Feb 2004 06:40:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvEQy-0007u6-Ft for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 06:39:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NBdaK6030376 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 06:39:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvEQy-0007tr-Aw for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 06:39:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20197 for <sipping-web-archive@ietf.org>; Mon, 23 Feb 2004 06:39:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvEQu-0002Je-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 06:39:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvEPy-0002Eg-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 06:38:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvEPL-00028y-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 06:37:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvEOT-0007KB-Hd; Mon, 23 Feb 2004 06:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvENc-0007C7-2v for sipping@optimus.ietf.org; Mon, 23 Feb 2004 06:36:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20041 for <sipping@ietf.org>; Mon, 23 Feb 2004 06:36:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvENY-00021y-00 for sipping@ietf.org; Mon, 23 Feb 2004 06:36:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvEMe-0001y9-00 for sipping@ietf.org; Mon, 23 Feb 2004 06:35:11 -0500 Received: from natsmtp00.rzone.de ([81.169.145.165] helo=natsmtp00.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 1AvELj-0001v7-00 for sipping@ietf.org; Mon, 23 Feb 2004 06:34:11 -0500 Received: from RocknRoll (pD9E0D8B4.dip.t-dialin.net [217.224.216.180]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i1NBY5Ux025069; Mon, 23 Feb 2004 12:34:05 +0100 (MET) From: "Harry Behrens" <harry.behrens@snom.de> To: <sipping@ietf.org> Cc: <knuettel@fokus.fraunhofer.de> Date: Mon, 23 Feb 2004 12:35:42 +0100 Message-ID: <000501c3fa01$2bb50220$2c00a8c0@RocknRoll> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_01C3FA09.8D796A20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Sipping] Roaming Architecture for SIP Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe> List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org> List-Post: <mailto:sipping@ietf.org> List-Help: <mailto:sipping-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C3FA09.8D796A20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We have submitted a draft to the IETF (draft-behrens-sipping-roaming-architecture-00.txt), in which we describe a mechanism to enable VoIP roaming based on a unique ID - the NAI - which constitutes a handle into the billing relationship for a user. The original draft has some mistakes in the discussion of the call flows as well as not being 100% correctly formatted. We will therefore submit an updated version after the cutoff date, which we attach in this mail. Comments etc. are very welcome. Best regards, Harry Behrens Karsten Knuettel Abstract This draft describes an authentication mechanism which can be used to enable users of VoIP to globally roam between any number of ITSPs (Internet Telephony Service Providers) without needing to have a prior customer or billing relationship with all of them. This enables profiles and one-line-billing. Providers using this authentication mechanism do neither need full-mesh trust relationships or roaming agreements with every other possible provider nor do they need to rely on a centralized brokerage entity to process calls. The Home Network (HN), which handles all AAA for a user attempting to use an ITSP's service is determined through a unique identifier submitted by the user. This Network Access Identifier [RFC2486] contains information about the trust domain or trust realm the user belongs to. Based on a simple discovery mechanism a provider can establish a trust path to this home network. Once this is established, the provider can authenticate the user and check his credit with the home network. Accounting and rate information will be sent to the home network for mediation and processing. ------=_NextPart_000_0006_01C3FA09.8D796A20 Content-Type: text/plain; name="draft-behrens-sipping-roaming-architecture-01.txt" Content-Disposition: attachment; filename="draft-behrens-sipping-roaming-architecture-01.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force H. Behrens=20 Internet Draft snom technology AG=20 K. Knuettel=20 Fraunhofer FOKUS=20 =20 =20 draft-behrens-sipping-roaming-architecture-01.txt=20 February 16, 2003=20 Expires: August, 2004=20 =20 Interdomain Trust-Relationships for SIP-based Roaming=20 =20 =20 STATUS OF THIS MEMO=20 =20 This document is an Internet-Draft and is subject to all provisions of=20 Section 10 of RFC2026.=20 =20 Internet-Drafts are working documents of the Internet Engineering Task=20 Force (IETF), its areas, and its working groups. Note that other groups=20 may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference material=20 or to cite them other than as "work in progress".=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 To view the list Internet-Draft Shadow Directories, see=20 http://www.ietf.org/shadow.html.=20 =20 =20 Abstract=20 =20 This draft describes an authentication mechanism which can be used to=20 enable users of VoIP to globally roam between any number of ITSPs=20 (Internet Telephony Service Providers) without needing to have a prior=20 customer or billing relationship with all of them. This enables=20 profiles and one-line-billing.=20 Providers using this authentication mechanism do neither need full-mesh=20 trust relationships or roaming agreements with every other possible=20 provider nor do they need to rely on a centralized brokerage entity to=20 process calls.=20 The Home Network (HN), which handles all AAA for a user attempting to=20 use an ITSP's service is determined through a unique identifier=20 submitted by the user. This Network Access Identifier [RFC2486]=20 contains information about the trust domain or trust realm the user=20 belongs to. Based on a simple discovery mechanism a provider can=20 establish a trust path to this home network. Once this is established,=20 the provider can authenticate the user and check his credit with the=20 home network. Accounting and rate information will be sent to the home=20 network for mediation and processing.=20 =20 H. Behrens, K. Knuettel [Page 1]=0C =20 1. Introduction..............................................2=20 2. Requirements..............................................2=20 3. Architecture..............................................3=20 4. Terminology...............................................3=20 5. Conventions used in this document.........................3=20 6. Security Architecture.....................................4=20 6.1 Trust Relationships......................................4 Internet Draft SIP February 8, 2003=20 6.2 Trust Relationships between Providers and Settlement.....4=20 7. Actors and Mechanisms.....................................5=20 7.1 Actors...................................................5=20 7.2 Mechanisms...............................................5=20 8. Call Flow.................................................6=20 10. Bibliography............................................10=20 =20 1. Introduction=20 =20 More and more ISPs are beginning to add VoIP to their service=20 portfolio. The last years have seen the merging of IP-based telephony=20 and switched line telephony (both mobile and fixed-line) in the sense=20 that users of VoIP want to be able to call a PSTN or PLMN number as=20 well as being reachable under a home PSTN or PLMN number. Roaming=20 between ISPs has not developed to a large degree.=20 With the advent of voice communication becoming an important service,=20 this will become more relevant. Users will want to use VoIP for their=20 telephony and they will want to do this wherever they are located. The=20 authors believe that one way to address this is to leverage a user's=20 existing customer and billing relationship with his home telephony=20 provider. Users make use of this when signing up for ad-hoc service=20 with a visited ITSP. The ITSP verifies the existing billing=20 relationship and receives authorization of a certain amount of credit=20 the home network is willing to underwrite.=20 Based on the security architecture described here, mutual trust can be=20 established and the user can both place VoIP calls through his visited=20 network as well as being reachable under home number and URI.=20 =20 2. Requirements=20 =20 The term 'Roaming Capability' has been defined in [RFC2486]. =20 One aim of this document is to provide an architecture by which Roaming=20 Capability can be assured by a federation of independent VoIP=20 providers. In the world of IP-related protocols little attention has=20 been given to this issue.=20 Requirements for global roaming for WLAN users have been described by=20 J. Caron in [CARON.1]. He also outlined a simple DNS-based method in=20 [CARON.2].=20 The Roaming Scenario addressed here is as follows:=20 - The principal with the NAI of alice@biloxi.com sends a REGISTER=20 request to the SIP registrar of atlanta.com. atlanta.com in this=20 case is Alice's 'Visited Network' (VN). biloxi.com is her home=20 network.=20 - Alice wants to use her VN to place authenticated and secure=20 VoIP calls.=20 - Alice wants to be reachable both under her home URI as well as=20 under a URI assigned by the VN.=20 - Alice provides her NAI to her VN's SIP registrar.=20 - The VN=20 o asserts that Alice's Home Network signs Alice's identity and=20 authorizes a credit amount greater 0=20 o asserts that Alice's HN is a trusted entity=20 - atlanta.com assigns Alice a temporary Address of Record (AOR) URI=20 as well as a valid contact address from within its own name space.=20 - Alice registers with her HN using the newly assigned Contact=20 address as the Contact.=20 - Alice's SUA can place outgoing call either under the temporary URI=20 assigned by the VN or her home URI at biloxi.com.=20 - Alice is reachable both under her home-AOR as well as the visiting- AOR. Assuming Alice's HN provides PSTN break-in, Alice is also=20 reachable under her telephone number known to her buddies.=20 - All calls placed by Alice for the duration of this registration are=20 accounted to Alice's HN.=20 H. Behrens, K. Knuettel [Page 2]=0C Internet Draft SIP February 8, 2003=20 =20 3. Architecture=20 =20 The architecture is based on a model that is user-centric in that it=20 assumes for each principal or user to have one Home Network with which=20 he has a valid billing relationship. =20 This entity can authenticate the user based on his NAI and is willing=20 to underwrite credit as well as receive CDRs for further settlement.=20 This HN corresponds to the 'Authentication Service' described in=20 [PETERSON.1]. Basing the architecture on a user-centric model based on=20 a NAI, greatly reduces the number of billing relationships in a roaming=20 environment as well allowing incumbent HNs, such PSTN or PLMN providers=20 [RFC2486], to leverage their existing customer relationships. =20 New emerging operators can benefit from this, because they can deliver=20 their services to any user with a valid NAI, knowing that they can bill=20 the user's HN up to the credit amount underwritten. =20 HNs can benefit by charging for this service. This potentially creates=20 a win-win situation between incumbent operators, who hold the trust and=20 billing relationships, and emerging ITSPs who wish to be able to=20 attract as many users as possible, without the financial and=20 bureaucratic overhead involved in setting up a documented and secure=20 billing relation with each of their users.=20 =20 The architecture consists of=20 1. Peers: entities participating in a roamable VoIP infrastructure=20 2. Security Architecture: the Security architecture, which describes=20 the trust relationships as well as security mechanisms used.=20 3. Signalling Protocol: Signalling is based on the Session Initiation=20 Protocol (SIP) [RFC3261]. =20 4. Accounting infrastructure: Both Authentication and Authorization=20 are covered by the Security Architecture and/or the Signalling=20 Protocol. Accounting is based on=20 a. the Authentication and Authorization signed by the HN and=20 accepted by the VN.=20 b. hub-and-spoke trust relationships from the participating=20 operators to a Settlement Entity (SE).=20 This document proposes an architecture, which fulfils these=20 requirements by making use of pre-existing trust relationships.=20 The architecture is strongly influenced by work done by J. Peterson=20 [PETERSON.1] and [RFC3325] on one hand and the work of Aboba et. al=20 [RFC2486],[RFC2194] on the other hand.=20 =20 4. Terminology=20 =20 AAA Authentication, Authorization, Accounting=20 AOR Address of Record=20 CDR Call Detail Record=20 CRM Customer Relationship Management=20 DoT Domain of Trust=20 ETSI European Telecommunication Standard Institute=20 HN Home Network=20 ITSP Internet Telephony Service Provider=20 NAI Network Access Identifier=20 OSP Open Settlement Protocol=20 PKI Public Key Infrastructure=20 PLMN Public Line Mobile Network=20 PSTN Public Switched Telephone Network=20 URI Uniform Resource Identifier=20 VN Visited Network=20 VoIP Voice over IP=20 =20 5. Conventions used in this document=20 =20 H. Behrens, K. Knuettel [Page 3]=0C Internet Draft SIP February 8, 2003=20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20 document are to be interpreted as described in RFC-2119 [RFC2119].=20 =20 6. Security Architecture=20 =20 The proposed architecture is based on the assumption that all entities,=20 participating in the execution of a call, establish a mutual Trust=20 Domain (TD) for at least the duration of that call. The term 'Trust=20 Domain' is used in the sense described in [RFC3324].=20 Such a TD can be of permanent nature or established within the context=20 of one or more transactions.=20 Based on this definition of Trust Domain the architecture described=20 here, can be separated into two distinct layers:=20 1. Verification or Establishment of a common Trust Domain based on=20 existing and derived direct Trust Relationships.=20 2. Use the mechanisms provided by this TD to assert the=20 validity of VoIP calls and their related document trail.=20 Section 6.1 and 6.2 will outline the direct Trust Relationships assumed=20 in the scope of this document. Section 7 outlines how a common Trust=20 Domain is established. Section 8 provides example call flows that=20 combine the mechanisms to demonstrate how the requirements are=20 fulfilled.=20 =20 6.1 Trust Relationships=20 For SIP-based VoIP to become commercially accepted, providers need to=20 be able to=20 - account and bill for their services=20 - be able to cooperate with other VoIP providers in routing and=20 signalling calls.=20 Both of these requirements assume trust relationships between the=20 user(s) being served as well as between the operators cooperating=20 during the call.=20 In order to achieve critical mass, it needs to be easy for providers to=20 cooperate in a flexible ad-hoc fashion in placing and routing their=20 calls. Authentication should be based on a globally unique identifier,=20 so one principal has one AAA and billing relationship. This unique=20 identifier needs to specify his home domain of trust to other entities.=20 Within his DoT, the identifier needs to identify his specific principal=20 identity.=20 Authentication and authorization of a user can be transparent because=20 the user uses only one set of credentials wherever he may be. Within=20 this document we assume credentials based on exchange of PKI=20 certificates.=20 The model operates on direct trust relationships. A user has an a- priori trust relationship with his home network.=20 Visited network and home network establish trust based on exchange and=20 verification of certificates.=20 The user and the visited network establish trust through the mechanisms=20 described in this document.=20 Once the user and the VN have established a trust relationship, which=20 is based on the VN knowing that the HN can be charged for the credit=20 amount authorized, the user is fully authenticated and authorized and=20 can use the VN's services.=20 This is even though a-priori trust or billing relationship exists=20 between the authenticated user and the serving provider.=20 =20 6.2 Trust Relationships between Providers and Settlement=20 Entity=20 =20 Inter-operator accounting is still within the scope of the architecture=20 described here. We assume that billing is based on a settlement and=20 H. Behrens, K. Knuettel [Page 4]=0C Internet Draft SIP February 8, 2003=20 clearing entity. This entity provides CDR-aggregation, settlement,=20 clearing and billing functionalities to the participating providers.=20 Where there is more than one such entity, we assume an existing trust=20 relationship between them. This architecture assumes the existence of=20 such an entity, e.g. based on the Open Settlement Protocol (OSP)=20 defined by the ETSI [TS102.321]. It is also assumed that each provider=20 has its own trust relationship with the Settlement Agency. It should be=20 noted that the model explicitly does not use any of the authentication=20 or routing functionalities proposed in that specification.=20 In the architecture presented here, OSP is strictly used for=20 aggregation of CDRs and settlement among operators.=20 The authors think that the fully integrated position taken by the ETSI=20 does not fulfil the more organic and fluid environment of the upcoming=20 VoIP industry.=20 =20 7. Actors and Mechanisms=20 =20 7.1 Actors=20 =20 The actors (players) are as follows:=20 =20 - The Service User (User): A user wanting to use VoIP telephony=20 both for inbound as well as outbound calls. A user is uniquely=20 identified based on his NAI, which identifies him as a user of=20 his home domain. A mechanism of the location of the AAA server=20 serving that home domain is assumed.=20 - The Visited Network (VN): the VN is the network a user uses when=20 roaming. He wants to use that networks services while being=20 billed by his HN. Roaming should be transparent. This means that=20 the user should not need an a-priori trust relationship with the=20 VN. It also means that he should be reachable under his home AOR=20 and home telephone number no matter who is roaming provider is.=20 - The Home Network (HN): The Home Network has two functions:=20 o act as a home AAA server for the User.=20 o act as the home VoIP network for the User.=20 =20 7.2 Mechanisms=20 =20 Two mechanisms to establish a mutual Trust Domain are proposed. =20 1. One mechanism relies on transparent pass-through of registrations = to=20 achive registrations both with the Visited and with the Home = Network.=20 2. The other mechanism uses two independent registrations. One for=20 the VN one for the HN.=20 Whichever one is chosen, at the end of either one =20 - The User has registered with the VN.=20 - The VN has established that he can bill services delivered to=20 the User to the User's HN.=20 - The User has signed off that VN may bill to the HN=20 =20 7.2.1 Establishing trust using pass-through registrations=20 - A user registers with the VN (atlanta.com in the call flow=20 given). The user submits his NAI in new header field 'P-NAI'.=20 The user submits a bogus URI in both the From and the To header.=20 (F1 in section 8.2.1) - The VN recognizes the registration as a P-NAI registration and=20 sends back a "401 Unauthorized" response, with both the 'From'=20 and the 'To' URI set to the temporary URI that will be assigned=20 to the user upon successful authentication and authorization (F2). = H. Behrens, K. Knuettel [Page 5]=0C Internet Draft SIP February 8, 2003=20 - The User submits the credentials belonging to the NAI specified,=20 e.g. his signed public key in the next register message (F3).=20 - The VN sends a registration to the HN on behalf of the user. The VN sets the 'From' and 'To' headers to "sip:NAI", i.e.=20 "sip:alice@biloxi.com", where the NAI is "alice@biloxi.com" (F5).=20 - The HN sends a "407 Proxy Authentication Required" back to the VN. - The VN forwards the response to the user (F7). - The User submits his credentials for the identity represented by = his NAI in a new registration message (F8). - The VN forwards this to the HN. The HN authenticates the user and = includes a 'P-NAI-Token' encrypted using the user's public key in the = response to=20 the user's registration request.=20 - The VN forwards this response to the user. The user decrypts the = 'P-NAI-Token'=20 with his private key. The user is now registered with the HN and = the HN has=20 the authorized user to use any VN's services based on the encrypted = P-NAI-Token (F11). - The user encrypts the P-NAI-Token with the public key of the VN and = sends a registration message to register his contact with the 'From' and = 'To' URIs received in F2. Both 'P-NAI' and 'P-NAI-Token' are set in this = request (F12).=20 - The VN decrypts the token and sends a "200 OK" (F13). - The user is now registered with the VN as well as the HN and all necessary trust relationships have been established.=20 o The HN has authenticated the user. o The VN now trusts the user based on the VN's trusting =20 the HN.=20 o The user trusts the VN. This is established by the VN=20 possessing the clear text P-NAI-Token.=20 o The token can be used in accounting, billing and settlement to establish the link to this ad-hoc Trust Domain. 7.2.2 Establishing trust using two indpendent registrations=20 =20 The mechanism is as follows:=20 - A user registers with the VN (atlanta.com in the call flow=20 given). The user submits his NAI in new header field 'P-NAI'.=20 The user submits a bogus URI in both the From and the To header (F1 in section 8.2.2).=20 - The VN recognizes the registration as a P-NAI registration and=20 sends back a "401 Unauthorized" response, with both the 'From'=20 and the 'To' URI set to the temporary URI that will be assigned=20 to the user upon successful authentication and authorization (F2). = - The User submits the credentials belonging to the NAI specified,=20 e.g. his signed public key in the next register message (F3).=20 - The VN requests authentication and authorization of the user=20 from the home network. This can either be done through the AAA=20 architecture or future extensions to the SIP protocol (F5).=20 - The HN authenticates the user and authorizes a certain amount of=20 credit. The HN includes a one-time token, which he encrypts=20 using the user's public key in the return message. The HN signs=20 the user's credentials and the encrypted token together with the=20 amount authorized. At this point authentication is established.=20 Authorization is still pending (F6).=20 - The VN sends the user the encrypted token in a new header field=20 'P-NAI-Token' in the response to the user's registration=20 request (F7).=20 - The user decrypts the 'P-NAI-Token' with his private key. He=20 then encrypts it with his VN's public key. =20 - The user is now registered with the VN.=20 - The user registers with the HN with the 'P- NAI-Token' (encrypted=20 with the VN's certificate) inserted in the header (F8).=20 - The VN decrypts the token and encrypts it using the HN's public=20 key. It substitutes the two and forwards this to the HN (F9). - The HN decrypts the received token and compares it with the=20 locally generated token. If they match, the user is now registered = with the HN as well and all necessary trust=20 relationships have been established.=20 o The HN has authenticated the user to the VN.=20 o The VN now trusts the user based on the VN's trusting =20 the HN.=20 o The user trusts the VN. This is established by the VN=20 possessing the clear text P-NAI-Token.=20 o The HN receives proof of this trust and can therefore=20 authorize the VN to bill up to the credit amount given.=20 - The HN sends and VN forwards the OK to the second registration = (F10, F11) =20 =20 H. Behrens, K. Knuettel [Page 6]=0C Internet Draft SIP February 8, 2003=20 8. Call Flows=20 =20 8.2.1 Call Flow for pass-through registration =20 (PAR: Proxy Authentication Required) =20 atlanta.com . . . . biloxi.com=20 ITSP/GME ITSP/GME =20 =20 Alice's . . . . . . . . . . . . . . . . . . . . .=20 softphone =20 | | | =20 | REGISTER F1 | | =20 | with P-NAI header | | |--------------------> | | =20 | 401 Unauthorized F2 | | =20 |<-------------------- | |=20 | REGISTER F3 | | =20 |--------------------> | | =20 | 100 Trying F4 | REGISTER F5 | =20 |<-------------------- |----------------> | =20 | | 407 PAR F6 |=20 | 407 PAR F7 |<------------------- | |<-------------------- | |=20 |--------------------> | |=20 | REGISTER F8 | |=20 | contains credentials | |=20 | for user's NAI | | |--------------------> | | | | REGISTER F9 |=20 | |-------------------> |=20 | | 200 OK F10 |=20 | |<------------------- |=20 | 200 OK F11 | |=20 |<-------------------- | |=20 | REGISTER F12 | |=20 | contains token | |=20 | encrypted for VN | | |--------------------> | | | 200 OK F13 | | |<---------------------| |=20 H. Behrens, K. Knuettel [Page 7]=0C 8.2.2 Call Flow for two independent registrations=20 =20 Client is located in the foreign ITSP-Network and wants to be=20 authenticated by his home network.=20 Within that flow a trust relationship between the ITSPs is established.=20 (PAR: Proxy Authentication Required) atlanta.com . . . . biloxi.com=20 ITSP/GME ITSP/GME =20 =20 Alice's . . . . . . . . . . . . . . . . . . . . .=20 softphone =20 | | | =20 | REGISTER F1 | | =20 | with P-NAI header | | |--------------------> | | =20 | 407 PAR F2 | | =20 |<-------------------- | |=20 | REGISTER F3 | | =20 |--------------------> | | =20 | | |=20 | 100 Trying F4 | Auth-Request(NAI) F5| =20 |<-------------------- |------------------> | =20 | | |=20 | | Auth-OK F6 | | | contains P-NAI-Token| | | encrypted for Alice | | |<------------------- | | | | | 407 Proxy | |=20 | Authentication | |=20 | Required F7 | |=20 |<-------------------- | |=20 | REGISTER F8 | |=20 | contains token | |=20 | encrypted for VN | | |--------------------> | | | | REGISTER F9 |=20 | | contains token |=20 | | encrypted for HN | =20 | |-------------------> |=20 | | 200 OK F10 |=20 | |<------------------- |=20 | 200 OK F11 | |=20 |<-------------------- | |=20 =20 = =20 =20 IANA Considerations=20 =20 SIP headers defined: P-NAI, P-NAI-Token=20 =20 Normative description: This document=20 =20 =20 9. Authors' Addresses=20 =20 Dr. Harry Behrens=20 snom technology AG=20 Pascalstr. 10B=20 10587 Berlin=20 Germany=20 Email: hb@snom.com=20 =20 Karsten Knuettel=20 Fraunhofer FOKUS=20 H. Behrens, K. Knuettel [Page 8]=0C Internet Draft SIP February 8, 2003=20 Kaiserin-Augusta-Allee 31=20 10589 Berlin=20 Email: knuettel@fokus.fraunhofer.de=20 =20 =20 10. Bibliography=20 =20 [CARON.1]Caron, J., =93Public Wireless LAN roaming issues=94,=20 <draft-caron-public-wlan-roaming-issues-00.txt>,=20 WIP,=20 February 2002.=20 [CARON.2]Caron, J., =93DNS-based Roaming=94,=20 <draft-caron-dns-based-roaming-00.txt>, WIP,=20 April 2002.=20 [PETERSON.1] Peterson, J. =93Enhancements for=20 Authenticated Identity=20 Management in the Session Initiation Protocol=20 (SIP)=94,=20 <draft-ietf-sip-identity-01>, WIP, February=20 2003.=20 [RFC2194] Aboba, B. et al., "Review of Roaming=20 Implementations", RFC2194, September 1997=20 [RFC2119] Bradner, S., "Key words for use in RFCs to=20 Indicate Requirement Levels", RFC2119, March=20 1997=20 [RFC2486]Aboba, B. et al., "The Network Access=20 Identifier",=20 January 1999=20 [RFC3261]Rosenberg, J., Schulzrinne H., Camarillo G.,=20 Johnston, A.R., Peterson, J., Sparks, R.,=20 Handley, M. and E. Schooler, "SIP: Session=20 Initiation Protocol", RFC 3261, Internet=20 Engineering Task Force, June 2002.=20 [RFC3325] Jennings, C. et al. "Private Extensions to the=20 Session Initiation Protocol (SIP) for Asserted=20 Identity within Trusted Networks", November=20 2002=20 [TS102.321] ETSI TS, =93Telecommunications and Internet=20 Protocol Harmonization Over Networks (TIPHON);=20 Open Settlement Protocol (OSP) for Interdomain=20 Pricing, authorization and usage exchange=94,=20 Technical Specification 101 321. =20 [RFC3261]=20 J. Rosenberg, H. Schulzrinne, G. Camarillo, A.=20 R. Johnston, J.Peterson, R. Sparks, M. Handley,=20 and E. Schooler, "SIP: Session Initiation=20 Protocol", RFC 3261, Internet Engineering Task=20 Force, June 2002.=20 =20 The IETF takes no position regarding the validity or scope of any=20 intellectual property or other rights that might be claimed to pertain=20 to the implementation or use of the technology described in this=20 document or the extent to which any license under such rights might or=20 might not be available; neither does it represent that it has made any=20 effort to identify any such rights.=20 Information on the IETF's procedures with respect to rights in=20 standards-track and standards-related documentation can be found in=20 BCP-11. Copies of claims of rights made available for publication and=20 any assurances of licenses to be made available, or the result of an=20 attempt made to obtain a general license or permission for the use of=20 such proprietary rights by implementors or users of this specification=20 can be obtained from the IETF Secretariat.=20 =20 H. Behrens, K. Knuettel [Page 9]=0C Internet Draft SIP February 8, 2003=20 The IETF invites any interested party to bring to its attention any=20 copyrights, patents or patent applications, or other proprietary rights=20 which may cover technology that may be required to practice this=20 standard. Please address the information to the IETF Executive=20 Director.=20 =20 Full Copyright Statement=20 =20 Copyright (c) The Internet Society (2003). All Rights Reserved.=20 =20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it or=20 assist in its implementation may be prepared, copied, published and=20 distributed, in whole or in part, without restriction of any kind,=20 provided that the above copyright notice and this paragraph are=20 included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing the=20 copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of developing=20 Internet standards in which case the procedures for copyrights defined=20 in the Internet Standards process must be followed, or as required to=20 translate it into languages other than English.=20 =20 The limited permissions granted above are perpetual and will not be=20 revoked by the Internet Society or its successors or assigns.=20 =20 This document and the information contained herein is provided on an=20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT=20 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL=20 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR=20 FITNESS FOR A PARTICULAR PURPOSE.=20 H. Behrens, K. Knuettel [Page = 10]=0C=C1 ------=_NextPart_000_0006_01C3FA09.8D796A20-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 08:28:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24127 for <sipping-archive@odin.ietf.org>; Mon, 23 Feb 2004 08:28:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvG7e-0007Ql-G7 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 08:27:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NDRkQj028557 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 08:27:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvG7e-0007QW-C9 for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 08:27:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24088 for <sipping-web-archive@ietf.org>; Mon, 23 Feb 2004 08:27:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvG7d-0001wH-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 08:27:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvG6i-0001q8-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 08:26:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvG63-0001id-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 08:26:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvG5z-00075m-4F; Mon, 23 Feb 2004 08:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvG5N-000727-Hh for sipping@optimus.ietf.org; Mon, 23 Feb 2004 08:25:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23886 for <sipping@ietf.org>; Mon, 23 Feb 2004 08:25:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvG5M-0001gB-00 for sipping@ietf.org; Mon, 23 Feb 2004 08:25:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvG4P-0001aH-00 for sipping@ietf.org; Mon, 23 Feb 2004 08:24:26 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AvG3W-0001V8-00 for sipping@ietf.org; Mon, 23 Feb 2004 08:23:30 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1NDNTAh015312 for <sipping@ietf.org>; Mon, 23 Feb 2004 14:23:29 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Feb 2004 14:23:29 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FMFLPS00; Mon, 23 Feb 2004 14:23:01 +0100 Message-ID: <4039FEAD.5070708@ericsson.com> Date: Mon, 23 Feb 2004 15:22:53 +0200 X-Sybari-Trust: 0eee25d0 c77f3eb6 eb01e110 00000138 From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping <sipping@ietf.org> CC: dpetrie@pingtel.com, Volker Hilt <volkerh@bell-labs.com>, Jonathan Rosemberg <jdrosen@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2004 13:23:29.0266 (UTC) FILETIME=[39CCF520:01C3FA10] Content-Transfer-Encoding: 7bit Subject: [Sipping] Config framework Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe> List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org> List-Post: <mailto:sipping@ietf.org> List-Help: <mailto:sipping-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, The following draft defines a framework for session policies in SIP http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-indep-policy-00.txt It defines an event package and a data format to carry session policy information. Now, the following draft defines a framework for sending configuration information and user profiles to SIP user agents. http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-02.txt We need to decide whether session policies should use the package defined by the configuration framework or, on the other hand, continue defining its own package. The XML based data format would remain the same on both cases. I would like to know what type of information folks intend to store as user profile. Would it make sense to consider session policies as a subset of the user profile, or it would be better to define a new profile-name value: "session-policy" (in addition to the already defined "user" and "device"). I tend to think that it would be better to re-use the same package for session policies as for configuration, defining the new "session-policy" value for the profile-name Event header field parameter, but I would like to hear other opinions. Comments? A further question of the config draft. Is the intention to establish two subscriptions, one for device configuration and another for user profiles, or the idea is to use a single subscription and multiplex somehow both data types into it. Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 08:40:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24785 for <sipping-archive@odin.ietf.org>; Mon, 23 Feb 2004 08:40:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGJs-0000Y9-7c for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 08:40:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NDeORU002101 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 08:40:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGJs-0000Xo-2Z for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 08:40:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24761 for <sipping-web-archive@ietf.org>; Mon, 23 Feb 2004 08:40:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvGJq-000322-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 08:40:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvGIw-0002xZ-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 08:39:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvGIY-0002sx-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 08:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGIX-0000Jn-Nc; Mon, 23 Feb 2004 08:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGHn-0000Cv-2R for sipping@optimus.ietf.org; Mon, 23 Feb 2004 08:38:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24616 for <sipping@ietf.org>; Mon, 23 Feb 2004 08:38:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvGHl-0002qf-00 for sipping@ietf.org; Mon, 23 Feb 2004 08:38:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvGGo-0002la-00 for sipping@ietf.org; Mon, 23 Feb 2004 08:37:15 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AvGFq-0002hJ-00 for sipping@ietf.org; Mon, 23 Feb 2004 08:36:14 -0500 Received: from bear.cs.columbia.edu (IDENT:0UXII6SI8/Sxzki/AaBn+0/3UvZROZh9@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1NDa4mS021241 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 23 Feb 2004 08:36:04 -0500 (EST) Received: from cs.columbia.edu (pool-138-89-104-237.mad.east.verizon.net [138.89.104.237]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1NDa1mi008365 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 23 Feb 2004 08:36:02 -0500 Message-ID: <403A01BD.7080905@cs.columbia.edu> Date: Mon, 23 Feb 2004 08:35:57 -0500 From: Henning Schulzrinne <hgs@cs.columbia.edu> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> CC: sipping <sipping@ietf.org>, dpetrie@pingtel.com, Volker Hilt <volkerh@bell-labs.com>, Jonathan Rosemberg <jdrosen@dynamicsoft.com> Subject: Re: [Sipping] Config framework References: <4039FEAD.5070708@ericsson.com> In-Reply-To: <4039FEAD.5070708@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe> List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org> List-Post: <mailto:sipping@ietf.org> List-Help: <mailto:sipping-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My general concern is that the current config framework is far too device-centric, presumably based on the origin and interests of the authors. Generally, configuration seems to consist of at least three sources that can all contain pretty much the same data, ranging from protocol parameters to media policies to user configuration information such as speed dial buttons and address lists (or IM equivalents). The three sources are: (1) The local network that I happen to be in, represented by the outbound proxy or other information conveyed by DHCP, identified by my AOR; (2) My home provider/network, where I am identified by my AOR; (3) My device, identified by some permanent device identifier, typically a MAC-address like thing, but some of the other identifiers discussed here recently may also be possible. So far, only a subset of (3) seems to have been discussed. I had raised this issue earlier, but have gotten no response. It seems fundamental to the whole architecture discussion. The same problem that Gonzalo raises (one or more events) also applies to the question as to how this relates to watcher lists and other IM configuration information. Gonzalo Camarillo wrote: > Hello, > > The following draft defines a framework for session policies in SIP > http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-indep-policy-00.txt > > > It defines an event package and a data format to carry session policy > information. Now, the following draft defines a framework for sending > configuration information and user profiles to SIP user agents. > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-02.txt > > > We need to decide whether session policies should use the package > defined by the configuration framework or, on the other hand, continue > defining its own package. The XML based data format would remain the > same on both cases. > > I would like to know what type of information folks intend to store as > user profile. Would it make sense to consider session policies as a > subset of the user profile, or it would be better to define a new > profile-name value: "session-policy" (in addition to the already defined > "user" and "device"). > > I tend to think that it would be better to re-use the same package for > session policies as for configuration, defining the new "session-policy" > value for the profile-name Event header field parameter, but I would > like to hear other opinions. > > Comments? > > A further question of the config draft. Is the intention to establish > two subscriptions, one for device configuration and another for user > profiles, or the idea is to use a single subscription and multiplex > somehow both data types into it. > > Thanks, > > Gonzalo > > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any > such corruption, interception, amendment, tampering or viruses or any > consequences thereof. > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 08:48:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25243 for <sipping-archive@odin.ietf.org>; Mon, 23 Feb 2004 08:48:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGRP-0001Dr-HQ for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 08:48:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NDmBql004693 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 08:48:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGRP-0001Dc-AE for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 08:48:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25191 for <sipping-web-archive@ietf.org>; Mon, 23 Feb 2004 08:48:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvGRN-0003h2-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 08:48:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvGQP-0003c3-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 08:47:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvGPR-0003XS-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 08:46:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGPK-0000sp-AP; Mon, 23 Feb 2004 08:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGOk-0000rk-79 for sipping@optimus.ietf.org; Mon, 23 Feb 2004 08:45:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25117 for <sipping@ietf.org>; Mon, 23 Feb 2004 08:45:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvGOi-0003Uw-00 for sipping@ietf.org; Mon, 23 Feb 2004 08:45:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvGNo-0003QG-00 for sipping@ietf.org; Mon, 23 Feb 2004 08:44:28 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AvGNI-0003LP-00 for sipping@ietf.org; Mon, 23 Feb 2004 08:43:56 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1NDhtAh019572 for <sipping@ietf.org>; Mon, 23 Feb 2004 14:43:55 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Feb 2004 14:43:55 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FMFLP7XQ; Mon, 23 Feb 2004 14:44:02 +0100 Message-ID: <403A039B.9020708@ericsson.com> Date: Mon, 23 Feb 2004 15:43:55 +0200 X-Sybari-Trust: 8ed9bb86 c77f3eb6 53bd8675 00000138 From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping <sipping@ietf.org> CC: ono.kumiko@lab.ntt.co.jp, tachimoto.shinya@lab.ntt.co.jp, Volker Hilt <volkerh@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2004 13:43:55.0298 (UTC) FILETIME=[14929820:01C3FA13] Content-Transfer-Encoding: 7bit Subject: [Sipping] E2M security Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe> List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org> List-Post: <mailto:sipping@ietf.org> List-Help: <mailto:sipping-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Regarding requirement number 5 of the following draft: http://www.ietf.org/internet-drafts/draft-ietf-sipping-e2m-sec-reqs-01.txt ***** 5. It SHOULD allow a UA to request the recipient UA to disclose the same information that the requesting UA is providing to the proxy server to the same proxy server. The request itself SHOULD be secure. ***** We have had some discussions on this issue when working on the session policies drafts: http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-spec-policy-00.txt Our conclusions so far are that mechanisms were *one* of the UAs inform the proxy about the session are simpler. Of course, one UA can keep its trusted proxies up to date while the other does the same with its own trusted proxies. Unfortunatelly, we did not get around to releasing a new revision of the draft above, but have been doing some brainstorming on the, so called, re-direct model, where UAs establish separate dialogs with the proxies. These dialogs are related to the main dialog between the UAs, but are different dialogs. Having an ad-hoc meeting in Korea to discuss these issues may be useful. As a chair, I would encourage the authors of both drafts to get in touch with each other. Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 08:50:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25311 for <sipping-archive@odin.ietf.org>; Mon, 23 Feb 2004 08:50:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGSk-0001Qa-4m for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 08:49:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NDnYCF005482 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 08:49:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGSk-0001QL-0v for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 08:49:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25306 for <sipping-web-archive@ietf.org>; Mon, 23 Feb 2004 08:49:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvGSi-0003qK-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 08:49:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvGRl-0003kj-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 08:48:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvGRG-0003f5-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 08:48:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGRG-00016V-RY; Mon, 23 Feb 2004 08:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGQU-00013l-Fa for sipping@optimus.ietf.org; Mon, 23 Feb 2004 08:47:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25178 for <sipping@ietf.org>; Mon, 23 Feb 2004 08:47:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvGQT-0003cW-00 for sipping@ietf.org; Mon, 23 Feb 2004 08:47:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvGPc-0003ZV-00 for sipping@ietf.org; Mon, 23 Feb 2004 08:46:20 -0500 Received: from smtp.sylantro.com ([65.200.90.207]) by ietf-mx with esmtp (Exim 4.12) id 1AvGP0-0003T4-00 for sipping@ietf.org; Mon, 23 Feb 2004 08:45:42 -0500 Received: from 10.10.5.1 by smtp.sylantro.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v5.6.0)); Mon, 23 Feb 2004 05:43:53 -0800 X-Server-Uuid: A2273672-8896-48F6-829D-BBF711663783 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] updated dialog package Date: Mon, 23 Feb 2004 05:43:52 -0800 Message-ID: <22ACFCD87A5780449EEBDD6D78BB8DB50C37EF@sylmail1> Thread-Topic: [Sipping] updated dialog package Thread-Index: AcP3EqxQ6nGQBa+0SDqmhH7wkiHqvQDACi5f From: "Venkatesh Venkataramanan" <Venkatesh.Venkataramanan@sylantro.com> To: "Rohan Mahy" <rohan@cisco.com>, sipping <sipping@ietf.org> cc: rohan@cisco.com X-WSS-ID: 6C24DC131XC80648-01-01 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe> List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org> List-Post: <mailto:sipping@ietf.org> List-Help: <mailto:sipping-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 UmVzZW5kaW5nIHRoZSBzYW1lIGFzIG15IGZpcnN0IHBvc3Rpbmcgc29tZWhvdyB3YXMgZW1wdHkg aW4gdGhlIG1haWxpbmcgbGlzdCAhDQoNCkZyb20gYSBzaGFyZWQgbGluZSBhcHBsaWNhdGlvbiBw ZXJzcGVjdGl2ZTogDQoNClRoZXJlIGlzIGEgcGllY2UgbWlzc2luZyBmcm9tIGEgaW1wbGVtZW50 YXRpb24gcGVyc3BlY3RpdmUgZm9yIHNoYXJlZCBsaW5lIGFwcGVhcmFuY2VzLiANCg0KICAgLSBB YmlsaXR5IHRvIHNpZ25hbCBIb2xkLiBJIGtub3cgdGhlcmUgaGF2ZSBiZWVuIGEgZmV3IGRpc2N1 c3Npb25zIGluIHRoZSBTSVBQSU5HIG1haWxpbmcgbGlzdCBhcm91bmQgdGhpcyBhbmQgaXQgdGhl cmUgd2FzIG5vIGNvbmNsdXNpb24gYWJvdXQgd2hhdCAiaG9sZCIgYWN0dWFsbHkgaXMgISBIb3dl dmVyLCBvbmUgb2YgdGhlIGltcG9ydGFudCBhc3BlY3RzIG9mIHNoYXJlZCBsaW5lcyBpcyB0aGUg YWJpbGl0eSB0byBjb21tdW5pY2F0ZSBhIGhlbGQgY2FsbCB0byB0aGUgb3RoZXIgcGFydGllcyBp biB0aGUgZ3JvdXAuIEN1cnJlbnRseSB0aGUgYW5pbC1zaXBwaW5nLWJsYSBkcmFmdCB1c2VzIHRo ZSBTRFAgaW5mb3JtYXRpb24gdG8gaGVscCBvdGhlciBVQSdzIGRlY2lkZSBhIGRpYWxvZyBpcyB0 cmFuc2l0aW9uaW5nIHRvIGhvbGQgYW5kIG9mZiBob2xkLiBJdCB3b3VsZCBiZSBkZWZpbml0ZWx5 IHVzZWZ1bCB0byBoYXZlIHRoZSBkaWFsb2cgc3RhdGUgZXhwcmVzcyB0aGlzIHN0YXRlIHRvIHRo ZSBmYXIgZW5kIHJhdGhlciB0aGFuIGhhdmluZyB0byBzZW5kIG91dCBTRFAgaW5mb3JtYXRpb24u IEZvciB0aGUgcHVycG9zZSBvZiBTTEEsIGluc3RlYWQgb2YgZ29pbmcgZG93biBkZWZpbmluZyB3 aGF0IGlzIEhvbGQsIEkgd2FzIHdvbmRlcmluZyBpZiB3ZSBjYW4gY3JlYXRlICBhIHN0YXRlL29y IGFuIGF0dHJpYnV0ZSBpbiB0aGUgZGlhbG9nIHN0YXRlIHBhY2thZ2Ugc2F5ICJwaWNrYWJsZSIg ZGlhbG9nIHRvIGluZGljYXRlIHRoZSBzYW1lLiBJJ3ZlIGhlYXJkIGNvbW1lbnRzIHNheWluZyBh IFVBIGNhbiBibG9jayByZWxldmFudCBmaWVsZHMgb2YgYSBkaWFsb2cgd2hlbmV2ZXIgaXQgd2Fu dHMgb3RoZXJzIHRvIGJlIGFibGUgdG8gcGljayBvciBub3QgdG8gcGljayBhIGRpYWxvZywgaG93 ZXZlciB0aGUgc2FtZSBpcyBub3QgY2xlYW4gYW5kIGl0IGJyZWFrcyB3aGVuIHNheSB0aGUgc2Ft ZSBVQSB0aGF0IHB1dCB0aGUgZGlhbG9nIG9uIEhvbGQsIHJldHJpZXZlcyB0aGUgZGlhbG9nLiBO b3RoaW5nIGluIHRoZSBkaWFsb2cgaWRlbnRpZmllcnMgaGF2ZSBjaGFuZ2VkLg0KDQpUaGUgYW5p bC1zaXBwaW5nLWJsYS1kcmFmdCBjb3ZlcnMgb3RoZXIgdmFyaW91cyBhc3BlY3RzIG9mIFNMQSBm cm9tIGFuIGFwcGxpY2F0aW9uIGltcGxlbWVudGF0aW9uIHBlcnNwZWN0aXZlIHdpdGggY2FsbCBm bG93IGV4YW1wbGVzLg0KDQpyZWdhcmRzLCANClZlbmthdGVzaCANCg0KCS0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tIA0KCUZyb206IHNpcHBpbmctYWRtaW5AaWV0Zi5vcmcgb24gYmVoYWxmIG9m IFJvaGFuIE1haHkgDQoJU2VudDogVGh1IDIvMTkvMjAwNCA5OjU5IEFNIA0KCVRvOiBzaXBwaW5n IA0KCUNjOiByb2hhbkBjaXNjby5jb20gDQoJU3ViamVjdDogW1NpcHBpbmddIHVwZGF0ZWQgZGlh bG9nIHBhY2thZ2UNCgkNCgkNCg0KCUhpIEV2ZXJ5b25lLCANCg0KCUkndmUgdXBkYXRlZCB0aGUg ZGlhbG9nIHBhY2thZ2VzIHdpdGggdGhlIGNoYW5nZXMgd2UgYWdyZWVkIHRvIGluIA0KCU1pbm5l YXBvbGlzIChyZW1vdmluZyBDU2VxIGFuZCB0aGUgUm91dGUtU2V0KS4gDQoNCglJJ3ZlIGFsc28g cHJvdmlkZWQgYSBkZXRhaWxlZCBleGFtcGxlIG9mIHVzaW5nIHRoZSBkaWFsb2cgcGFja2FnZSBm b3IgYSANCgkic2hhcmVkLWxpbmUiIGFwcGxpY2F0aW9uLiAgSSBhcG9sb2dpemUgZm9yIG15IHRh cmRpbmVzcyBoZXJlLiAgSSB3YXMgDQoJc3VwcG9zZWQgdG8gcG9zdCBzb21ldGhpbmcgc2hvcnRs eSBhZnRlciB0aGUgbWVldGluZy4gIEkgYW55IGNhc2UsIEkgDQoJYmVsaWV2ZSB0aGlzIGRlbW9u c3RyYXRlcyB0aGF0IHRoZSBjdXJyZW50IHN5bnRheCBpcyBhdCBsZWFzdCANCglzdWZmaWNpZW50 IGZvciB0aGUgdXNlIGNhc2VzIHdlJ3ZlIGRpc2N1c3NlZC4gIEkgd291bGQgbGlrZSB0byBoZWFy IA0KCWZyb20gYWxsIG9mIHlvdSBpZiB0aGlzIGRvZXMgdGhlIHRyaWNrLiANCg0KCW1hbnkgdGhh bmtzLCANCgktcm9oYW4gDQoNCg0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fIA0KCVNpcHBpbmcgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dzEuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zaXBwaW5nIA0KCVRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVs b3BtZW50IG9mIHRoZSBhcHBsaWNhdGlvbiBvZiBTSVAgDQoJVXNlIHNpcC1pbXBsZW1lbnRvcnNA Y3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXAgDQoJVXNlIHNpcEBp ZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvZiBjb3JlIFNJUCANCg0K _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 09:00:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25692 for <sipping-archive@odin.ietf.org>; Mon, 23 Feb 2004 09:00:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGdI-0002AI-FM for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 09:00:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NE0ShH008316 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 09:00:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGdI-0002A3-Bj for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 09:00:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25665 for <sipping-web-archive@ietf.org>; Mon, 23 Feb 2004 09:00:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvGdG-0004WD-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 09:00:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvGc7-0004Si-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 08:59:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvGbu-0004Pn-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 08:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGbs-0001xe-UZ; Mon, 23 Feb 2004 08:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGb5-0001wi-Kv for sipping@optimus.ietf.org; Mon, 23 Feb 2004 08:58:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25613 for <sipping@ietf.org>; Mon, 23 Feb 2004 08:58:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvGb4-0004Og-00 for sipping@ietf.org; Mon, 23 Feb 2004 08:58:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvGa5-0004Lg-00 for sipping@ietf.org; Mon, 23 Feb 2004 08:57:10 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AvGZ7-0004Hw-00 for sipping@ietf.org; Mon, 23 Feb 2004 08:56:09 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1NDu9Ah022381 for <sipping@ietf.org>; Mon, 23 Feb 2004 14:56:09 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Feb 2004 14:56:09 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FMHBN39Z; Mon, 23 Feb 2004 14:56:14 +0100 Message-ID: <403A0679.1010609@ericsson.com> Date: Mon, 23 Feb 2004 15:56:09 +0200 X-Sybari-Trust: 51364798 c77f3eb6 53bd8675 00000138 From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping <sipping@ietf.org> CC: volkerh@bell-labs.com, tachimoto.shinya@lab.ntt.co.jp, ono.kumiko@lab.ntt.co.jp Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2004 13:56:09.0236 (UTC) FILETIME=[CA08A540:01C3FA14] Content-Transfer-Encoding: 7bit Subject: [Sipping] E2M security solution Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe> List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org> List-Post: <mailto:sipping@ietf.org> List-Help: <mailto:sipping-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, The e2m security solution, described in the draft below, http://www.ietf.org/internet-drafts/draft-ono-sipping-end2middle-security-01.txt attempts to resolve some of the problems that the session-specific policies draft addresses: http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-spec-policy-00.txt The need of a UA to obtain the policies that a particular proxy has is dealt with in both drafts. In addition, the e2m security draft talks about disclosing information to intermediaries. The policy draft addresses this issue and defines a means to disclose *only* the information needed by the proxy. My comments on the e2m requirements draft apply also to this one. We should try to align both efforts (session policies and e2m security). Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 09:55:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28700 for <sipping-archive@odin.ietf.org>; Mon, 23 Feb 2004 09:55:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHUP-0007LS-GZ for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 09:55:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NEtLTR028228 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 09:55:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHUP-0007LD-Aa for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 09:55:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28692 for <sipping-web-archive@ietf.org>; Mon, 23 Feb 2004 09:55:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvHUN-0001ew-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 09:55:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvHTP-0001b9-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 09:54:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvHTF-0001Xw-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 09:54:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHT8-0007A3-4z; Mon, 23 Feb 2004 09:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHSQ-000791-9Y for sipping@optimus.ietf.org; Mon, 23 Feb 2004 09:53:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28599 for <sipping@ietf.org>; Mon, 23 Feb 2004 09:53:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvHSO-0001Wk-00 for sipping@ietf.org; Mon, 23 Feb 2004 09:53:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvHRV-0001TH-00 for sipping@ietf.org; Mon, 23 Feb 2004 09:52:22 -0500 Received: from [209.116.120.7] (helo=tnint11.telogy.design.ti.com) by ietf-mx with esmtp (Exim 4.12) id 1AvHQq-0001LT-00 for sipping@ietf.org; Mon, 23 Feb 2004 09:51:40 -0500 Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19) id <FNGPXGY3>; Mon, 23 Feb 2004 09:49:42 -0500 Message-ID: <37A3C2F21006D611995100B0D0F9B73C04C3E444@tnint11.telogy.design.ti.com> From: "Scoggins, Sophia" <sscoggins@telogy.com> To: sipping@ietf.org Subject: RE: [Sipping] SIP Proxy servers -- security encryption protocol Date: Mon, 23 Feb 2004 09:49:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FA1C.431BCEB0" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe> List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org> List-Post: <mailto:sipping@ietf.org> List-Help: <mailto:sipping-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 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. ------_=_NextPart_001_01C3FA1C.431BCEB0 Content-Type: text/plain Thanks for the information. For each security association establishment, there is a significant delay. Depending on the DH group, both phases (phase 1 authentication, phase 2 key exchange) have delays ranging from 2 seconds to 10 seconds using ISKIKE. That is before any signaling messages started. This is not acceptable in call processing. Is any key exchange protocol recommended? What is the performance (delays) for key exchange? Why is AES blocked? AES is supposed to have better performance than 3DES. Regards, Sophia -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Sunday, February 22, 2004 3:40 PM To: ranjit.avasarala@wipro.com; sscoggins@telogy.com; sipping@ietf.org Subject: Re: [Sipping] SIP Proxy servers -- security encryption protocol And the crypto that is typically being recommended and folks are implementing is RSA for asymmetric key, SHA1 for hash, and 3DES or AES for encryption. Some of the early stuff said 3DES because the RFC would have blocked on AES work. It's a long debate with no clear answer between AES and 3DES (and let's not repeat it on this list) but most SIP implementers seem to be doing AES or both AES and 3DES. On 2/19/04 9:26 PM, "ranjit.avasarala@wipro.com" <ranjit.avasarala@wipro.com> wrote: Hi For secured transactions you could use TLS i.e using sips: instead of normal sip: url. Alternatively IPSec also could be used at IP Layer and for RTP security you could use SRTP (draft-ietf-avt-srtp-09.txt) protocol. Regards Ranjit -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] <mailto:sipping-admin@ietf.org%5d> On Behalf Of Scoggins, Sophia Sent: Friday, February 20, 2004 10:45 AM To: 'sipping@ietf.org' Subject: [Sipping] SIP Proxy servers -- security encryption protocol My group is looking for some security encryption protocol for both SIP and RTP streams for CPE. We were wondering what encryption protocol that most SIP proxy servers currently support or intend to support? Would you please just send your reply to me? Thanks. Regards, Sophia2@ti.com ------_=_NextPart_001_01C3FA1C.431BCEB0 Content-Type: text/html <html> <head> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII"> <meta name=Generator content="Microsoft Word 10 (filtered)"> <title>Re: [Sipping] SIP Proxy servers -- security encryption protocol

Thanks for the information. For each security association establishment, there is a significant delay. Depending on the DH group, both phases (phase 1 authentication, phase 2 key exchange) have delays ranging from 2 seconds to 10 seconds using ISKIKE. That is before any signaling messages started. This is not acceptable in call processing.

 

Is any key exchange protocol recommended? What is the performance (delays) for key exchange?

 

Why is AES blocked? AES is supposed to have better performance than 3DES.

 

 

Regards,

Sophia

 

-----Original Message-----
From: Cullen Jennings [mailto:fluffy@cisco.com]
Sent: Sunday, February 22, 2004 3:40 PM
To: ranjit.avasarala@wipro.com; sscoggins@telogy.com; sipping@ietf.org
Subject: Re: [Sipping] SIP Proxy servers -- security encryption protocol

 


And the crypto that is typically being recommended and folks are implementing is RSA for asymmetric key, SHA1 for hash, and 3DES or AES for encryption. Some of the early stuff said 3DES because the RFC would have blocked on AES work. It's a long debate with no clear answer between AES and 3DES (and let's not repeat it on this list) but most SIP implementers seem to be doing AES or both AES and 3DES.  

On 2/19/04 9:26 PM, "ranjit.avasarala@wipro.com" <ranjit.avasarala@wipro.com> wrote:

Hi
    For secured transactions you could use TLS i.e using sips: instead of normal sip: url.
Alternatively IPSec also could be used at IP Layer
and for RTP security you could use SRTP (draft-ietf-avt-srtp-09.txt) protocol.

Regards
Ranjit


 
-----Original Message-----
From:  sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of  Scoggins, Sophia
Sent: Friday, February 20, 2004 10:45  AM
To: 'sipping@ietf.org'
Subject: [Sipping] SIP Proxy  servers -- security encryption protocol


 

 
 
My group is looking for some  security encryption protocol for both SIP and RTP streams for CPE. We were  wondering what encryption protocol that most SIP proxy servers currently  support or intend to support? Would you please just send your reply to  me?
 
 
 
Thanks.
 
 
 
Regards,
 
Sophia2@ti.com

 

 

------_=_NextPart_001_01C3FA1C.431BCEB0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 10:18:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01388 for ; Mon, 23 Feb 2004 10:18:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHpz-0006Ly-4H for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 10:17:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NFHd2T024397 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 10:17:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHpy-0006LG-9j for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 10:17:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01320 for ; Mon, 23 Feb 2004 10:17:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvHpw-0004HB-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 10:17:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvHp3-0004BF-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 10:16:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvHoX-00044M-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 10:16:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHoR-0005gz-Tf; Mon, 23 Feb 2004 10:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHni-0005TK-KD for sipping@optimus.ietf.org; Mon, 23 Feb 2004 10:15:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00953 for ; Mon, 23 Feb 2004 10:15:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvHng-000412-00 for sipping@ietf.org; Mon, 23 Feb 2004 10:15:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvHmh-0003vH-00 for sipping@ietf.org; Mon, 23 Feb 2004 10:14:16 -0500 Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx with esmtp (Exim 4.12) id 1AvHli-0003ni-00 for sipping@ietf.org; Mon, 23 Feb 2004 10:13:14 -0500 Received: from pingtel.com (user2.pingtel.com[65.220.123.2]) by comcast.net (rwcrmhc11) with SMTP id <2004022315124001300pvt7oe> (Authid: dgpetrie); Mon, 23 Feb 2004 15:12:42 +0000 Message-ID: <403A1862.47679F39@pingtel.com> Date: Mon, 23 Feb 2004 10:12:34 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sipping , Volker Hilt , Jonathan Rosemberg References: <4039FEAD.5070708@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Config framework Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have not gotten through all of draft-hilt-sipping-session-indep-policy-00 yet, but I certainly consider policies such as access and authorization to be part of user and device profile data. Whether directly or by reference the policy data applies to the user or the device. I would hope that this could all be decovered and delivered using the same mechanizm. Ideally, it would be nice if all user profile data (including policies) or all device data could optionally be delivered via one URL. Using XML name spaces the subscriber can specify what it wants and parse out the parts of interest. Cheers, Dan Gonzalo Camarillo wrote: > Hello, > > The following draft defines a framework for session policies in SIP > http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-indep-policy-00.txt > > It defines an event package and a data format to carry session policy > information. Now, the following draft defines a framework for sending > configuration information and user profiles to SIP user agents. > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-02.txt > > We need to decide whether session policies should use the package > defined by the configuration framework or, on the other hand, continue > defining its own package. The XML based data format would remain the > same on both cases. > > I would like to know what type of information folks intend to store as > user profile. Would it make sense to consider session policies as a > subset of the user profile, or it would be better to define a new > profile-name value: "session-policy" (in addition to the already defined > "user" and "device"). > > I tend to think that it would be better to re-use the same package for > session policies as for configuration, defining the new "session-policy" > value for the profile-name Event header field parameter, but I would > like to hear other opinions. > > Comments? > > A further question of the config draft. Is the intention to establish > two subscriptions, one for device configuration and another for user > profiles, or the idea is to use a single subscription and multiplex > somehow both data types into it. > > Thanks, > > Gonzalo > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 11:10:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04123 for ; Mon, 23 Feb 2004 11:10:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIf1-0002zx-Mi for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 11:10:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NGANgO011523 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 11:10:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIf1-0002zl-Cl for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 11:10:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04116 for ; Mon, 23 Feb 2004 11:10:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvIey-00019B-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 11:10:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvIe2-00015j-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 11:09:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvIdp-00012L-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 11:09:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIdi-0002kW-LE; Mon, 23 Feb 2004 11:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvId0-0002gH-3y for sipping@optimus.ietf.org; Mon, 23 Feb 2004 11:08:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04057 for ; Mon, 23 Feb 2004 11:08:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvIcx-00011M-00 for sipping@ietf.org; Mon, 23 Feb 2004 11:08:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvIc2-0000yY-00 for sipping@ietf.org; Mon, 23 Feb 2004 11:07:19 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 1AvIbw-0000vc-00 for sipping@ietf.org; Mon, 23 Feb 2004 11:07:12 -0500 Received: from pingtel.com (user2.pingtel.com[65.220.123.2]) by comcast.net (rwcrmhc12) with SMTP id <20040223160641014008ln7qe> (Authid: dgpetrie); Mon, 23 Feb 2004 16:06:41 +0000 Message-ID: <403A250F.9B29CE10@pingtel.com> Date: Mon, 23 Feb 2004 11:06:40 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Gonzalo Camarillo , sipping , Volker Hilt , Jonathan Rosemberg Subject: Re: [Sipping] Config framework References: <4039FEAD.5070708@ericsson.com> <403A01BD.7080905@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Comments below: Henning Schulzrinne wrote: > My general concern is that the current config framework is far too > device-centric, presumably based on the origin and interests of the This is certainly not the intension. The draft specifies a way to separately subscribe for device or user profile data. I would be happy to clarify this where you think the draft is vague or implies this restriction. Section 3.2 describes parameters that are device specific as even in the ideal world, purely user specific data may need to consider the UA implementation that it is to be applied to. Section 3.2 also specifies a means to indicate the desire for user or device data. Section 3.13 specifies how to form the SUBSCRIBE URI based upon the interest for either a device or user profile. > > authors. Generally, configuration seems to consist of at least three > sources that can all contain pretty much the same data, ranging from > protocol parameters to media policies to user configuration information > such as speed dial buttons and address lists (or IM equivalents). > > The three sources are: > (1) The local network that I happen to be in, represented by the > outbound proxy or other information conveyed by DHCP, identified by my AOR; > > (2) My home provider/network, where I am identified by my AOR; > > > (3) My device, identified by some permanent device identifier, typically > a MAC-address like thing, but some of the other identifiers discussed > here recently may also be possible. > These 3 important concepts are intended to be supported in draft-ietf-sipping-config-framework-02. It is however difficult in practice to keep these three things separate. In many environments it is easier to keep two of the three separate. For example: In an enterprise with physical devices that do not move much, it becomes easier to combine the properties of 1 related to location with the properties of 3. When a user does not know their AOR or does not want to have to provide it to the UA (to provide a plug and play experience), the user's AOR can be associated with 3 (the device). 2 is may then be subscribe implicitly or explicitly. In the automated discover phase for a new UA, the distinction between 1 and 2 become blurred as the device can only discover or derive AORs based upon the local domain (without user input). I think that this illustrates a very good point that the separation between user and device profile data cannot be made concrete. Data such as out bound proxy, or policy may be dictated by any or all of the 3 realms defined above. Only the application and local administrative policies can determine the realm to which data should be associated. In addition it may be desirable to override some of the user or device profile data based upon other local discovery data (e.g. DHCP options for out bound proxy, STUN for NAT traversal). At best we can define a precedence by which the device data can be overridden by user data (or the other way around) along with the ability for administrators to dictate policy (perhaps indicated in the profile data) over what can be overridden. > > So far, only a subset of (3) seems to have been discussed. > > I had raised this issue earlier, but have gotten no response. It seems > fundamental to the whole architecture discussion. The same problem that > Gonzalo raises (one or more events) also applies to the question as to > how this relates to watcher lists and other IM configuration information. > > Gonzalo Camarillo wrote: > > > Hello, > > > > The following draft defines a framework for session policies in SIP > > http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-indep-policy-00.txt > > > > > > It defines an event package and a data format to carry session policy > > information. Now, the following draft defines a framework for sending > > configuration information and user profiles to SIP user agents. > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-02.txt > > > > > > We need to decide whether session policies should use the package > > defined by the configuration framework or, on the other hand, continue > > defining its own package. The XML based data format would remain the > > same on both cases. > > > > I would like to know what type of information folks intend to store as > > user profile. Would it make sense to consider session policies as a > > subset of the user profile, or it would be better to define a new > > profile-name value: "session-policy" (in addition to the already defined > > "user" and "device"). > > > > I tend to think that it would be better to re-use the same package for > > session policies as for configuration, defining the new "session-policy" > > value for the profile-name Event header field parameter, but I would > > like to hear other opinions. > > > > Comments? > > > > A further question of the config draft. Is the intention to establish > > two subscriptions, one for device configuration and another for user > > profiles, or the idea is to use a single subscription and multiplex > > somehow both data types into it. > > > > Thanks, > > > > Gonzalo > > > > > > > > This communication is confidential and intended solely for the > > addressee(s). Any unauthorized review, use, disclosure or distribution > > is prohibited. If you believe this message has been sent to you in > > error, please notify the sender by replying to this transmission and > > delete the message without disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data corruption, > > interruption, unauthorized amendment, tampering and viruses, and we only > > send and receive e-mails on the basis that we are not liable for any > > such corruption, interception, amendment, tampering or viruses or any > > consequences thereof. > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 11:22:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04688 for ; Mon, 23 Feb 2004 11:22:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIqY-0003nF-69 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 11:22:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NGMIoB014570 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 11:22:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIqX-0003mv-IU for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 11:22:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04655 for ; Mon, 23 Feb 2004 11:22:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvIqW-000207-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 11:22:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvIpW-0001wG-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 11:21:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvIoe-0001tg-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 11:20:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIoM-0003ar-S3; Mon, 23 Feb 2004 11:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvInd-0003Zl-BM for sipping@optimus.ietf.org; Mon, 23 Feb 2004 11:19:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04614 for ; Mon, 23 Feb 2004 11:19:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvInc-0001pc-00 for sipping@ietf.org; Mon, 23 Feb 2004 11:19:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvImi-0001mx-00 for sipping@ietf.org; Mon, 23 Feb 2004 11:18:20 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AvImN-0001jn-00 for sipping@ietf.org; Mon, 23 Feb 2004 11:18:00 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Feb 2004 08:28:06 +0000 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 i1NGHR1m025657; Mon, 23 Feb 2004 08:17:27 -0800 (PST) Received: from stealth-10-32-245-156.cisco.com (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMO60035; Mon, 23 Feb 2004 08:17:26 -0800 (PST) Date: Mon, 23 Feb 2004 11:17:25 -0500 From: David Oran To: "Scoggins, Sophia" , sipping@ietf.org Subject: RE: [Sipping] SIP Proxy servers -- security encryption protocol Message-ID: <2147483647.1077535045@[10.32.245.156]> In-Reply-To: <37A3C2F21006D611995100B0D0F9B73C04C3E444@tnint11.telogy.design.ti.com> References: <37A3C2F21006D611995100B0D0F9B73C04C3E444@tnint11.telogy.design. ti.com> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Monday, February 23, 2004 9:49 AM -0500 "Scoggins, Sophia" wrote: > > > Thanks for the information. For each security association establishment, > there is a significant delay. Depending on the DH group, both phases > (phase 1 authentication, phase 2 key exchange) have delays ranging from 2 > seconds to 10 seconds using ISKIKE. That is before any signaling messages > started. This is not acceptable in call processing. > so, set up the TLS connection ahead of time. Do you think you'll have so many inter-provider signaling associations that this would be a scalability concern? You should also look into TLS "fast restart" which caches the results of the first phase of key management and is only one extra RTT since the results of the prior PK computations are kept. > > > Is any key exchange protocol recommended? What is the performance > (delays) for key exchange? > > > > Why is AES blocked? AES is supposed to have better performance than 3DES. > > > > > > Regards, > > Sophia > > > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Sunday, February 22, 2004 3:40 PM > To: ranjit.avasarala@wipro.com; sscoggins@telogy.com; sipping@ietf.org > Subject: Re: [Sipping] SIP Proxy servers -- security encryption protocol > > > > > And the crypto that is typically being recommended and folks are > implementing is RSA for asymmetric key, SHA1 for hash, and 3DES or AES > for encryption. Some of the early stuff said 3DES because the RFC would > have blocked on AES work. It's a long debate with no clear answer between > AES and 3DES (and let's not repeat it on this list) but most SIP > implementers seem to be doing AES or both AES and 3DES. > > On 2/19/04 9:26 PM, "ranjit.avasarala@wipro.com" > wrote: > > Hi > For secured transactions you could use TLS i.e using sips: instead of > normal sip: url. > Alternatively IPSec also could be used at IP Layer > and for RTP security you could use SRTP (draft-ietf-avt-srtp-09.txt) > protocol. > > Regards > Ranjit > > > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf > Of Scoggins, Sophia > Sent: Friday, February 20, 2004 10:45 AM > To: 'sipping@ietf.org' > Subject: [Sipping] SIP Proxy servers -- security encryption protocol > > > > > > > My group is looking for some security encryption protocol for both SIP > and RTP streams for CPE. We were wondering what encryption protocol that > most SIP proxy servers currently support or intend to support? Would you > please just send your reply to me? > > > > Thanks. > > > > Regards, > > Sophia2@ti.com > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 12:06:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06186 for ; Mon, 23 Feb 2004 12:06:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJX9-0006yc-VL for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 12:06:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NH6JtH026812 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 12:06:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJX9-0006yN-RK for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 12:06:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06104 for ; Mon, 23 Feb 2004 12:06:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJX8-0005Lo-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 12:06:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJW9-0005Bh-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 12:05:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvJV9-00050j-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 12:04:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJUv-0006ab-93; Mon, 23 Feb 2004 12:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJUE-0006Rx-ON for sipping@optimus.ietf.org; Mon, 23 Feb 2004 12:03:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05924 for ; Mon, 23 Feb 2004 12:03:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJUD-0004sO-00 for sipping@ietf.org; Mon, 23 Feb 2004 12:03:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJTF-0004jv-00 for sipping@ietf.org; Mon, 23 Feb 2004 12:02:18 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly03b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AvJSV-0004eR-00; Mon, 23 Feb 2004 12:01:31 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly03b.srv.mailcontrol.com (MailControl) with SMTP id i1NH0wgW017256; Mon, 23 Feb 2004 17:00:58 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Mon, 23 Feb 2004 17:00:56 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 23 Feb 2004 17:00:57 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF1FA@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Advanced IM requirements Thread-Index: AcP5C/kBvwKHvMXJS6urOHqe9sfskgA3pGvQABD6gKA= From: "Chris Boulton" To: "Simple WG" , "sipping" X-Scanned-By: MailControl A-01-00-04-90 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Subject: [Sipping] FW: [Simple] Advanced IM requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable As promised. https://www.ubiquity.net/draft-boulton-sipping-message-receipt-00.txt Chris. >-----Original Message----- >From: Chris Boulton >Sent: 23 February 2004 10:40 >To: 'Jonathan Rosenberg'; Simple WG >Cc: 'sipping@ietf.org' >Subject: RE: [Simple] Advanced IM requirements > >Hi Jonathan et al, > > I have an extremely early version (so be gentle) of a draft aimed at >supplying IM delivery reports. It hasn't been formally submitted yet but I >have attached a copy - so would be grateful if the list could take a look >and see if it's worth progressing. I will submit to the archives in the >next few days. I will also put this on the internet somewhere in case this >attachment doesn't survive its journey (Will send link later). > >Best Regards, > >Chris. > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: 22 February 2004 06:17 >>To: Simple WG >>Subject: [Simple] Advanced IM requirements >> >>Folks, >> >>As I noted earlier, I resubmitted the advanced IM requirements draft. It >>specifies a bunch of advanced IM functions we havent yet tackled here. >>They are: >> >>* delivery reports for IM >>* is-typing indicator (Henning had an I-D on this that has expired) >>* capabilities indications of maximum desired message sizes for IM >>* page mode groups (under discussion in the context of exploders in >>sipping) >>* invitations to non-real time sessions >> >> >>The last of these is particularly interesting. One use case is "call >>alerts" in PTT. There, I send you a request to have a PTT chat. The >>request is not answered in real time. Rather, its stored by the >>recipient as if it were an IM, and can be answered at any time later. >>"Answering it" merely involves setting up a PTT call back to the caller. >>Its also possible to cancel the call alert at any time. >> >>There are some interesting ways to accomplish this function. The one >>I've been thinking about is taking a SIP INVITE message, and sending it >>in the body of a MESSAGE request as a message/sip content. I'm sure >>there are other ways. >> >>Are these topics for which there is still group interest in working on? >>I think all of them remain quite important. >> >>Thanks, >>Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 12:14:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06620 for ; Mon, 23 Feb 2004 12:14:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJeu-0007vL-0d for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 12:14:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NHEJ3w030453 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 12:14:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJet-0007v6-RI for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 12:14:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06512 for ; Mon, 23 Feb 2004 12:14:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJes-0006Bv-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 12:14:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJds-00062m-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 12:13:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvJcv-0005vt-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 12:12:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJcf-0007ca-79; Mon, 23 Feb 2004 12:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJcC-0007bO-Oe for sipping@optimus.ietf.org; Mon, 23 Feb 2004 12:11:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06403 for ; Mon, 23 Feb 2004 12:11:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJcB-0005rq-00 for sipping@ietf.org; Mon, 23 Feb 2004 12:11:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJbC-0005mq-00 for sipping@ietf.org; Mon, 23 Feb 2004 12:10:31 -0500 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by ietf-mx with esmtp (Exim 4.12) id 1AvJap-0005ii-00 for sipping@ietf.org; Mon, 23 Feb 2004 12:10:08 -0500 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i1NH9KcD059576; Mon, 23 Feb 2004 12:09:20 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i1NH9Dws076435; Mon, 23 Feb 2004 12:09:13 -0500 (EST) Received: from bell-labs.com (volker-hopc [135.180.240.186]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i1NH9Ci0014240; Mon, 23 Feb 2004 12:09:12 -0500 (EST) Message-ID: <403A335F.8090403@bell-labs.com> Date: Mon, 23 Feb 2004 12:07:43 -0500 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: "Daniel G. Petrie" CC: Henning Schulzrinne , Gonzalo Camarillo , sipping , Jonathan Rosemberg Subject: Re: [Sipping] Config framework References: <4039FEAD.5070708@ericsson.com> <403A01BD.7080905@cs.columbia.edu> <403A250F.9B29CE10@pingtel.com> In-Reply-To: <403A250F.9B29CE10@pingtel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Policies and configuration information seem to share a number of commonalities. Thus, I think it would make sense to use the same framework for both. The framework should probably be able to transfer any kind of information from a network entity to a user agent. More comments inline. Daniel G. Petrie wrote: > Henning Schulzrinne wrote: >>My general concern is that the current config framework is far too >>device-centric, presumably based on the origin and interests of the > > This is certainly not the intension. The draft specifies a way to separately > subscribe for device or user profile data. I would be happy to clarify this > where you think the draft is vague or implies this restriction. > Is it safe to assume that policy information is always part of the device or user configuration or can it be an independent piece of information a UA wants to subscribe to? Thus, would it make sense to define a profile-name "session-policies"? This could be useful if a device is configured by other means and simply wants to keep track of the policies in a network. >> >>The three sources are: >>(1) The local network that I happen to be in, represented by the >>outbound proxy or other information conveyed by DHCP, identified by my AOR; >> >>(2) My home provider/network, where I am identified by my AOR; >> >>(3) My device, identified by some permanent device identifier, typically >>a MAC-address like thing, but some of the other identifiers discussed >>here recently may also be possible. > > These 3 important concepts are intended to be supported in > draft-ietf-sipping-config-framework-02. It is however difficult in > practice to keep these three things separate. In many environments > it is easier to keep two of the three separate. > > For example: > In an enterprise with physical devices that do not move much, it becomes > easier to combine the properties of 1 related to location with the properties > of 3. > > When a user does not know their AOR or does not want to have to provide > it to the UA (to provide a plug and play experience), the user's AOR can be > associated with 3 (the device). 2 is may then be subscribe implicitly or explicitly. > > In the automated discover phase for a new UA, the distinction between > 1 and 2 become blurred as the device can only discover or derive > AORs based upon the local domain (without user input). > A difference between configuration data and other information (such as policies) seems to be that subscriptions to configuration data must work on an "out-of-the-box" device that has not been configured yet. Once the configuration is done, its probably easier to subscribe to the different sources of information. Is there information that applies to a device besides the device configuration? If not, would it make sense to differentiate into the device configuration (requiring a discovery process) and subscriptions to the local network using my AOR as well as subscriptions to my home network (also using my AOR)? Thanks, Volker > I think that this illustrates a very good point that the separation between > user and device profile data cannot be made concrete. Data such as > out bound proxy, or policy may be dictated by any or all of the 3 > realms defined above. Only the application and local administrative > policies can determine the realm to which data should be associated. > In addition it may be desirable to override some of the user or device > profile data based upon other local discovery data (e.g. DHCP options > for out bound proxy, STUN for NAT traversal). > > At best we can define a precedence by which the device data > can be overridden by user data (or the other way around) > along with the ability for administrators to dictate policy (perhaps indicated > in the profile data) over what can be overridden. > > >>So far, only a subset of (3) seems to have been discussed. >> >>I had raised this issue earlier, but have gotten no response. It seems >>fundamental to the whole architecture discussion. The same problem that >>Gonzalo raises (one or more events) also applies to the question as to >>how this relates to watcher lists and other IM configuration information. >> >>Gonzalo Camarillo wrote: >> >> >>>Hello, >>> >>>The following draft defines a framework for session policies in SIP >>>http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-indep-policy-00.txt >>> >>> >>>It defines an event package and a data format to carry session policy >>>information. Now, the following draft defines a framework for sending >>>configuration information and user profiles to SIP user agents. >>> >>>http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-02.txt >>> >>> >>>We need to decide whether session policies should use the package >>>defined by the configuration framework or, on the other hand, continue >>>defining its own package. The XML based data format would remain the >>>same on both cases. >>> >>>I would like to know what type of information folks intend to store as >>>user profile. Would it make sense to consider session policies as a >>>subset of the user profile, or it would be better to define a new >>>profile-name value: "session-policy" (in addition to the already defined >>>"user" and "device"). >>> >>>I tend to think that it would be better to re-use the same package for >>>session policies as for configuration, defining the new "session-policy" >>>value for the profile-name Event header field parameter, but I would >>>like to hear other opinions. >>> >>>Comments? >>> >>>A further question of the config draft. Is the intention to establish >>>two subscriptions, one for device configuration and another for user >>>profiles, or the idea is to use a single subscription and multiplex >>>somehow both data types into it. >>> >>>Thanks, >>> >>>Gonzalo >>> >>> >>> >>>This communication is confidential and intended solely for the >>>addressee(s). Any unauthorized review, use, disclosure or distribution >>>is prohibited. If you believe this message has been sent to you in >>>error, please notify the sender by replying to this transmission and >>>delete the message without disclosing it. Thank you. >>> >>>E-mail including attachments is susceptible to data corruption, >>>interruption, unauthorized amendment, tampering and viruses, and we only >>>send and receive e-mails on the basis that we are not liable for any >>>such corruption, interception, amendment, tampering or viruses or any >>>consequences thereof. >>> >>> >>>_______________________________________________ >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the application of SIP >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sip@ietf.org for new developments of core SIP > > -- Volker Hilt Bell Labs / Lucent Technologies phone: +1 732 332 6432 101 Crawfords Corner Rd email: volkerh@bell-labs.com Holmdel, NJ 07733 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 12:31:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07807 for ; Mon, 23 Feb 2004 12:31:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJvT-0001NY-K5 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 12:31:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NHVRgW005294 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 12:31:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJvT-0001NJ-Fo for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 12:31:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07786 for ; Mon, 23 Feb 2004 12:31:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJvS-0000Oo-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 12:31:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJuW-0000KX-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 12:30:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvJuF-0000GU-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 12:30:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJu7-000157-61; Mon, 23 Feb 2004 12:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJtV-00012U-VK for sipping@optimus.ietf.org; Mon, 23 Feb 2004 12:29:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07720 for ; Mon, 23 Feb 2004 12:29:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJtU-0000Eq-00 for sipping@ietf.org; Mon, 23 Feb 2004 12:29:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJsc-0000B0-00 for sipping@ietf.org; Mon, 23 Feb 2004 12:28:31 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AvJrw-000046-00 for sipping@ietf.org; Mon, 23 Feb 2004 12:27:48 -0500 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1NHRG1m008038; Mon, 23 Feb 2004 09:27:16 -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 JAA04299; Mon, 23 Feb 2004 09:27:15 -0800 (PST) Message-Id: <4.3.2.7.2.20040223110846.03817e70@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 23 Feb 2004 11:27:17 -0600 To: sipping@ietf.org From: "James M. Polk" Cc: "Rosen, Brian" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sipping] New version of Location Conveyance Reqs ID out Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 All This is to update the list on the submission of the latest version of the Location Conveyance ID posted recently. http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirements-00.txt Open issues since the last version that are addressed in this version are: 1. Location should always be transmitted, even if not considered reliable. 2. UAs SHOULD be able to inform the ERC if it considers the location info "probably wrong". should a flag saying this LI is probably wrong be included? This could be a listed open item. 3. In the situation of a VPN, the UA SHOULD keep the first DHCP Location Reply, and not the one sent in the VPN set-up. 4. Requirement to indicate in the INVITE where the LI came from (GPS, Cell Tower Triangulation, WiFi, DHCP, manual entry as examples). And possibly include all that is available 5. Use TLS in emergency calls (eliminates the issue of self signed certs and S/MIME), and use S/MIME in normal location conveyance scenarios between UAs. 6. Title should have the work "Requirements" in it. Not addressed and looking for more clarity on each requirement N1. Requirement to allow ERCs to do "after the fact" investigation on why a location was provided (that ended up being wrong). N2. MUST be able to communicate an MSAG-like equivalent location field. Part that is still open: O1. Proxies SHOULD be able to insert Location into an emergency call in a multipart body or return an LO in a Redirect Response New open issues are New-1 - surprised the requirement doesn't exist for a self signed cert for S/MIME? Current status - Not sure if this should be MUST, SHOULD or MAY (or even mentioned, but not disallowed) New-2 - - there needs to be a "confidence value" included with the LI in a SIP message. Currently Cell tower triangulation provides this, and isn't sure how many other technologies do. New-3 - - there should be a flag of where the LI was derived (.11, GPS, manual entry, etc) Any discussion prior to the SIPPING meeting would be appreciated Thanks cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 12:45:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08284 for ; Mon, 23 Feb 2004 12:45:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvK90-0002Li-Sc for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 12:45:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NHjQBj009030 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 12:45:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvK90-0002LZ-Mi for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 12:45:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08274 for ; Mon, 23 Feb 2004 12:45:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvK8y-0001RJ-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 12:45:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvK80-0001Nc-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 12:44:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvK7d-0001KF-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 12:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvK7c-00024M-Kp; Mon, 23 Feb 2004 12:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvK6x-00023T-Ob for sipping@optimus.ietf.org; Mon, 23 Feb 2004 12:43:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08224 for ; Mon, 23 Feb 2004 12:43:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvK6w-0001Ie-00 for sipping@ietf.org; Mon, 23 Feb 2004 12:43:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvK5w-0001Dm-00 for sipping@ietf.org; Mon, 23 Feb 2004 12:42:17 -0500 Received: from firewall.citel.com ([62.190.107.60] helo=ivor.citel.com) by ietf-mx with esmtp (Exim 4.12) id 1AvK4y-00013k-00 for sipping@ietf.org; Mon, 23 Feb 2004 12:41:16 -0500 Subject: RE: [Sipping] updated dialog package MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Feb 2004 17:40:55 -0000 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: Thread-Topic: [Sipping] updated dialog package Thread-Index: AcP3E6Ys3YyagvD5SJ6XMkicg4nf/gDIGZHw From: "Paul Pepper" To: "Rohan Mahy" , "sipping" Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I work for a company that has developed handset gateway devices that enable legacy, digital, business-grade telephones to be driven using SIP. For example, this enables an existing legacy PBX user to retain their telephones and cabling, but to replace the PBX by a Softswitch or IP Centrex system. As most business-grade telephone systems make use of a shared line facility, the addition of a shared line example to the dialog event package ID is of great interest to us, and others who support these types of feature. Although incorporating a shared line example is a step towards a common approach to shared line implementation, I don't believe it goes far enough. Our current implementation of shared lines has shown that the following issues need to be addressed by the spec, and should be shown in the examples: o Line seize, an essential part of any shared line implementation, is not adequately described. When more than one user agent attempts to seize a line at approximately the same instant, a race condition arises. No description of how to handle the race is given - an example application/dialog-info+xml NOTIFY payload is provided, but this alone is inadequate, as message sequencing is an important part of seizing a line. The Line Seize condition will be covered in the "anil-sipping-bla-draft" that Venkatesh refers to. o Handling of multiple instances of a shared line has been overlooked. On business-grade PBX systems a line will roughly correspond to an AOR. However, many such systems permit multiple "instances" of a shared line to appear on a single endpoint. For example, a number of instances of a "product support" shared line might appear on all the endpoints of the product support group, thereby allowing multiple calls to be taken and passed around within the group. o The mechanism used to convey that a call has been placed on hold appears to rely upon implementation-specific parameters, found in the xml's element. I can't see any reference to definitions of the values used by this element's pname and pval attributes (pname=3D"+activity" pval=3D"noninteractive"), so I assume they're non-standard. Thanks, Paul. > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com]=20 > Sent: Thursday, February 19, 2004 6:00 PM > To: sipping > Cc: rohan@cisco.com > Subject: [Sipping] updated dialog package >=20 >=20 > Hi Everyone, >=20 > I've updated the dialog packages with the changes we agreed to in=20 > Minneapolis (removing CSeq and the Route-Set). >=20 > I've also provided a detailed example of using the dialog=20 > package for a=20 > "shared-line" application. I apologize for my tardiness here. I was=20 > supposed to post something shortly after the meeting. I any case, I=20 > believe this demonstrates that the current syntax is at least=20 > sufficient for the use cases we've discussed. I would like to hear=20 > from all of you if this does the trick. >=20 > many thanks, > -rohan >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 14:05:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12457 for ; Mon, 23 Feb 2004 14:05:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLOD-0007g0-JF for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 14:05:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NJ5DfZ029502 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 14:05:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLOD-0007fl-EF for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 14:05:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12297 for ; Mon, 23 Feb 2004 14:05:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvLOB-0000lV-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 14:05:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvLM1-0000Kl-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 14:02:58 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AvLKc-00005G-02 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 14:01:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AvL9k-0001u9-Ed for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 13:50:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvL9X-00071E-7D; Mon, 23 Feb 2004 13:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvL8x-00070N-Ss for sipping@optimus.ietf.org; Mon, 23 Feb 2004 13:49:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11127 for ; Mon, 23 Feb 2004 13:49:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvL8v-0006cH-00 for sipping@ietf.org; Mon, 23 Feb 2004 13:49:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvL7x-0006YQ-00 for sipping@ietf.org; Mon, 23 Feb 2004 13:48:26 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1AvL7G-0006PO-00 for sipping@ietf.org; Mon, 23 Feb 2004 13:47:42 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 23 Feb 2004 10:49:36 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1NIl7T4000885; Mon, 23 Feb 2004 13:47:07 -0500 (EST) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGG12282; Mon, 23 Feb 2004 13:47:06 -0500 (EST) Message-ID: <403A4AAA.30206@cisco.com> Date: Mon, 23 Feb 2004 13:47:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harry Behrens CC: sipping@ietf.org, knuettel@fokus.fraunhofer.de Subject: Re: [Sipping] Roaming Architecture for SIP References: <000501c3fa01$2bb50220$2c00a8c0@RocknRoll> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Harry Behrens wrote: > We have submitted a draft to the IETF > (draft-behrens-sipping-roaming-architecture-00.txt), > in which we describe a mechanism to enable VoIP roaming based on a > unique ID - the NAI - which constitutes > a handle into the billing relationship for a user. > The original draft has some mistakes in the discussion of the call flows > as well as not being 100% correctly formatted. > We will therefore submit an updated version after the cutoff date, which > we attach in this mail. > Comments etc. are very welcome. I have specific comment inline below, and then a question. Paul > - A user registers with the VN (atlanta.com in the call flow > given). The user submits his NAI in new header field 'P-NAI'. > The user submits a bogus URI in both the From and the To header. > (F1 in section 8.2.1) > - The VN recognizes the registration as a P-NAI registration and > sends back a "401 Unauthorized" response, with both the 'From' > and the 'To' URI set to the temporary URI that will be assigned > to the user upon successful authentication and authorization (F2). This isn't legal. The From and To (with exception of To-tag) of response must be same as in the request. The question is: why would the UAC want to register with the VN? Assuming it is able to send sip messages, (which apparently it can), why wouldn't it simply send a REGISTER to its HN? I presume there must be some service that you intend the VN won't perform, that will prevent the UAC from doing this. But it isn't apparent what service that is. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 14:13:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12923 for ; Mon, 23 Feb 2004 14:13:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLVK-0000VG-Mi for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 14:12:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NJCYXZ001928 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 14:12:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLVK-0000V1-JR for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 14:12:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12873 for ; Mon, 23 Feb 2004 14:12:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvLVI-0001cO-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 14:12:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvLUK-0001XB-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 14:11:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvLTs-0001SU-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 14:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLTr-0008NQ-Nz; Mon, 23 Feb 2004 14:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvLTG-0008J7-25 for sipping@optimus.ietf.org; Mon, 23 Feb 2004 14:10:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12747 for ; Mon, 23 Feb 2004 14:10:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvLTD-0001Qd-00 for sipping@ietf.org; Mon, 23 Feb 2004 14:10:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvLSF-0001MQ-00 for sipping@ietf.org; Mon, 23 Feb 2004 14:09:24 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AvLRM-0001Eu-00; Mon, 23 Feb 2004 14:08:28 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1NJ7t1m026920; Mon, 23 Feb 2004 11:07:55 -0800 (PST) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGG14576; Mon, 23 Feb 2004 14:07:54 -0500 (EST) Message-ID: <403A4F8A.1040500@cisco.com> Date: Mon, 23 Feb 2004 14:07:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: Simple WG , sipping References: <45730E094814E44488F789C1CDED27AE02BDF1FA@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: draft-boulton-sipping-message-receipt-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chris Boulton wrote: > As promised. > > https://www.ubiquity.net/draft-boulton-sipping-message-receipt-00.txt Chris - just a couple of comments: 1) I don't see any particular reason to link this draft to GRUUs. The way receipts work, they may not be delivered until long after the message is sent. Anything that forces the receipt to be delivered to the same UA instance that sent the message is likely to cause problems. The response may well need to be captured by a recording device that wouldn't share a GRUU with the sending device. So I suspect that normally Receipt-To should mention the AOR of the sender. Of course the sender is still free to use a GRUU if desired, but it certainly isn't required. 2) I have some doubts about the need and value of the message-receipt option tag. Even if I sent you a message with Require: message-receipt, you are still free to not send me a receipt. (In the case of receipts with email I generally refuse to send them to parties unknown to me.) As a result, the option tag adds little or nothing. It should be sufficient to simply use the Receipt-To header without any option tag, and hope the recipient is willing and able to send a response. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 15:04:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15859 for ; Mon, 23 Feb 2004 15:04:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMIf-00081f-Le for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 15:03:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NK3Xuc030843 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 15:03:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMIe-00081I-Vc for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 15:03:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15822 for ; Mon, 23 Feb 2004 15:03:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvMIb-0006Ue-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 15:03:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvMHh-0006R4-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 15:02:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvMHH-0006Ms-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 15:02:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMHC-0006KB-8Z; Mon, 23 Feb 2004 15:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMGf-0005tG-Uq for sipping@optimus.ietf.org; Mon, 23 Feb 2004 15:01:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15769 for ; Mon, 23 Feb 2004 15:01:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvMGd-0006La-00 for sipping@ietf.org; Mon, 23 Feb 2004 15:01:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvMFi-0006H5-00 for sipping@ietf.org; Mon, 23 Feb 2004 15:00:30 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AvMEo-00068u-00 for sipping@ietf.org; Mon, 23 Feb 2004 14:59:34 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1NJx11m020149 for ; Mon, 23 Feb 2004 11:59:02 -0800 (PST) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGG20141; Mon, 23 Feb 2004 14:59:00 -0500 (EST) Message-ID: <403A5B84.3040103@cisco.com> Date: Mon, 23 Feb 2004 14:59:00 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org References: <200402172139.QAA07727@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re:draft-ietf-sipping-cc-conferencing-03.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In section 4.1 a change was made around the descriptin of handling a subscription. The new wording seems wrong: The SUBSCRIBE should be sent outside the INVITE-initiated dialog. Participants leaving the conference send a BYE to the focus. If they have a current subscription to the conference package, they also must send a SUBSCRIBE with an Expires:0 header field to terminate both dialogs. There is nothing for "The SUBSCRIBE" to refer back to. I wonder if this sentence wasn't intended to be in section 3.4, where it would make more sense. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 15:22:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17867 for ; Mon, 23 Feb 2004 15:22:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMaz-00075G-RG for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 15:22:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NKMTNe027224 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 15:22:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMaz-000751-MT for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 15:22:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17801 for ; Mon, 23 Feb 2004 15:22:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvMay-00006y-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 15:22:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvMa7-000029-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 15:21:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvMZm-0007lg-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 15:21:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMZZ-0006nL-BK; Mon, 23 Feb 2004 15:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMZ6-0006QX-UA for sipping@optimus.ietf.org; Mon, 23 Feb 2004 15:20:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17740 for ; Mon, 23 Feb 2004 15:20:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvMZ5-0007k7-00 for sipping@ietf.org; Mon, 23 Feb 2004 15:20:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvMYE-0007fZ-00 for sipping@ietf.org; Mon, 23 Feb 2004 15:19:38 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AvMXd-0007Yy-00 for sipping@ietf.org; Mon, 23 Feb 2004 15:19:01 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1NKHpZ29788; Mon, 23 Feb 2004 15:17:51 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1FN2BQPF; Mon, 23 Feb 2004 15:17:51 -0500 Received: from nortelnetworks.com (acart1hf.ca.nortel.com [47.129.129.223]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DBDZJK28; Mon, 23 Feb 2004 15:17:50 -0500 Message-ID: <403A5FEE.9020205@nortelnetworks.com> Date: Mon, 23 Feb 2004 15:17:50 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: Henning Schulzrinne , Mpierce1@aol.com, jgunn6@csc.com, sipping@ietf.org Subject: Re: [Sipping] Re: sos - dead or alive References: <4.3.2.7.2.20040220093002.00b283f0@cia.cisco.com> <4.3.2.7.2.20040220093002.00b283f0@cia.cisco.com> <4.3.2.7.2.20040220103319.02fbf370@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20040220103319.02fbf370@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This discussion is relevant to the case where the ECC is IP-reachable, but what about legacy ECCs reachable through gateways? What happens when some node along the chain tries to run a reachability test in this case? Bear in mind that only the gateway is likely to know that the call is going to the PSTN. Michael Hammer wrote: > Henning, > > The reality of deployment would be that every ECC would have it's own > proxy, so that would be more like 1000 x $2k = $2 million. But, the > corresponding distribution of load across those servers means it is even > more of a non-problem at any given site. > > One question: A real successful test to a wrong ECC doesn't buy you > much. I hope that mobility is addressed in the solution as well. Many > of those 100 million phones are mobile, which might become SIP-based > some time in the future. so I would add a 6) "works with mobile > terminals" to your list below. > > Mike > > At 10:00 AM 2/20/2004 -0500, Henning Schulzrinne wrote: > >> I think there are five goals, somewhat contradictory: >> >> (1) make it as realistic as possible, to make sure you are really >> testing the emergency calling system, not the testing system; after >> all, the fire safety officer doesn't go around ringing a cowbell >> instead of the real fire alarms. >> >> (2) do not impose any additional operator involvement; this is solved >> by the OPTIONS mechanism proposed; >> >> (3) allow for reasonable scaling; >> >> (4) avoid interfering with real emergency calls >> >> (5) allow user on-demand testing. >> >> With the proxy-based testing I proposed, we get very close to all >> goals. In the worst case, i.e., every device does this once a day, we >> get roughly 100 million calls a day in the US, or 1157/second. That's >> about 10 proxy servers worth of equipment, i.e., about $20k. This >> hardly seems worth spending inordinate engineering resources on >> avoiding, particularly since the likely load is going to be lower by >> probably a factor of 1000 or more (I'm assuming that most residential >> users will use a cable or DSL provider for this, for example). >> >> With even a few hundred systems, you'll get almost perfect smoothing >> and very little burstiness. >> >> I know protocol design is fun, but I'm very worried about adding >> complexity to solve largely a non-problem. >> >> Michael Hammer wrote: >> >>> At 09:03 AM 2/19/2004 -0500, Mpierce1@aol.com wrote: >>> >>>> In a message dated 2/19/2004 1:58:18 AM Eastern Standard Time, >>>> jgunn6@csc.com writes: >>>> >>>> >>>>> So any kind of regular, scheduled test should be designed so it does >>>>> NOT >>>>> tie up the operators. >>>> >>>> >>>> >>>> I believe the test must be devised so that it does not involve the >>>> emergency center or any of the equipment directly supporting the >>>> emergency center at all. >>>> >>>> Mike >>> >>> >>> Then there is not much point in doing any test. As Brian points out, >>> the question is how do you stage these reachability tests so that >>> they scale, ie. you don't have millions of users pinging the ECC >>> directly. >>> But, instead of the proxies pinging the ECC, which might reduce the >>> load, but might not make the burstiness more deterministic, perhaps a >>> presence subscription would be more appropriate. The proxies could >>> subscribe to the presence of the ECC, and the ECC could periodically >>> Notify those proxies that it is still there and able to receive calls. >>> The ECC could then control the scheduling and load distribution for >>> sending the Notifies. Failing to receive the notifications beyond >>> some interval could provide an indication that something is wrong and >>> trigger an inquiry. You might even be able to extend this to the >>> users, where emergency help is a "buddy" you subscribe to on the >>> local proxy. I haven't thought this through, but thought I'd throw >>> that out. >>> Mike H. > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 17:22:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27302 for ; Mon, 23 Feb 2004 17:22:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOSK-0007mS-OP for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 17:21:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NMLe0t029904 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 17:21:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOSK-0007mF-KQ for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 17:21:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27224 for ; Mon, 23 Feb 2004 17:21:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvOSI-00048X-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 17:21:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvORO-0003zz-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 17:20:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvOPr-0003pg-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 17:19:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOPm-0007Ek-EL; Mon, 23 Feb 2004 17:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOPP-0007CT-BK for sipping@optimus.ietf.org; Mon, 23 Feb 2004 17:18:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27035 for ; Mon, 23 Feb 2004 17:18:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvOPN-0003ls-00 for sipping@ietf.org; Mon, 23 Feb 2004 17:18:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvOOP-0003d1-00 for sipping@ietf.org; Mon, 23 Feb 2004 17:17:38 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AvOMs-0003FG-00 for sipping@ietf.org; Mon, 23 Feb 2004 17:16:02 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1NMFCmR018076; Mon, 23 Feb 2004 17:15:12 -0500 (EST) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1NMFCH15051; Mon, 23 Feb 2004 17:15:12 -0500 Message-ID: <403A7B6F.8000000@cs.columbia.edu> Date: Mon, 23 Feb 2004 17:15:11 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor CC: Michael Hammer , Mpierce1@aol.com, jgunn6@csc.com, sipping@ietf.org Subject: Re: [Sipping] Re: sos - dead or alive References: <4.3.2.7.2.20040220093002.00b283f0@cia.cisco.com> <4.3.2.7.2.20040220093002.00b283f0@cia.cisco.com> <4.3.2.7.2.20040220103319.02fbf370@cia.cisco.com> <403A5FEE.9020205@nortelnetworks.com> In-Reply-To: <403A5FEE.9020205@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If it's an OPTIONS and/or sos.test request, it will get to the last SIP hop, but no further. I don't think we can do more than that unless ISUP or Q.931 has a 'just testing' request. Tom Taylor wrote: > This discussion is relevant to the case where the ECC is IP-reachable, > but what about legacy ECCs reachable through gateways? What happens > when some node along the chain tries to run a reachability test in this > case? Bear in mind that only the gateway is likely to know that the > call is going to the PSTN. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 17:39:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28192 for ; Mon, 23 Feb 2004 17:39:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOit-0000mU-Ju for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 17:38:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NMclJp002996 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 17:38:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOit-0000mF-FR for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 17:38:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28172 for ; Mon, 23 Feb 2004 17:38:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvOiq-0005iH-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 17:38:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvOhu-0005d0-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 17:37:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvOhJ-0005X7-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 17:37:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOhB-0000IR-LP; Mon, 23 Feb 2004 17:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOgi-0000BI-6Y for sipping@optimus.ietf.org; Mon, 23 Feb 2004 17:36:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28085 for ; Mon, 23 Feb 2004 17:36:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvOgf-0005Vb-00 for sipping@ietf.org; Mon, 23 Feb 2004 17:36:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvOfl-0005Rk-00 for sipping@ietf.org; Mon, 23 Feb 2004 17:35:34 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AvOf5-0005KX-00 for sipping@ietf.org; Mon, 23 Feb 2004 17:34:51 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 13417; Mon, 23 Feb 2004 17:34:46 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: [Sipping] I-D ACTION:draft-ietf-sipping-kpml-02.txt Date: Mon, 23 Feb 2004 17:34:22 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB2432A@zoe.office.snowshore.com> Thread-Topic: [Sipping] I-D ACTION:draft-ietf-sipping-kpml-02.txt Thread-Index: AcPrvJS3Tb8eO6j3T6manyiYRVFsXAOoHxyQ From: "Eric Burger" To: "Jonathan Rosenberg" , Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Yep, yep, yep, we can (and will) use GRUU. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, February 05, 2004 2:46 AM > To: sipping@ietf.org > Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-kpml-02.txt >=20 >=20 > Eric, >=20 > The draft talks about sending the subscribe requests on the=20 > same dialog=20 > as the INVITE. For many reasons that have been discussed ad=20 > nauseam on=20 > the list, dialog sharing is a bad idea. GRUU provides a solution that=20 > does not require dialog sharing. As I recall, there was discussion on=20 > this point in the last ietf, and this seemed to be the=20 > preferred direction. >=20 > Is there any reason we cant change this to use gruu's rather=20 > than dialog=20 > sharing? >=20 > Also, you are missing the IANA registration for the kpml=20 > event package. >=20 > Thanks, > Jonathan R. >=20 > Internet-Drafts@ietf.org wrote: >=20 > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > This draft is a work item of the Session Initiation=20 > Proposal Investigation Working Group of the IETF. > >=20 > > Title : Keypad Stimulus Protocol (KPML) > > Author(s) : E. Burger > > Filename : draft-ietf-sipping-kpml-02.txt > > Pages : 42 > > Date : 2004-2-4 > > =09 > > The Key Press Stimulus Protocol uses the SIP SUBSCRIBE/NOTIFY > > mechanism and Keypad Markup Language (KPML) to provide=20 > instructions > > to SIP User Agents for the reporting of user key presses. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-02.txt > >=20 > > To remove yourself from the IETF Announcement list, send a=20 > message to=20 > > ietf-announce-request with the word unsubscribe in the body=20 > of the message. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-sipping-kpml-02.txt". > >=20 > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html=20 > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-sipping-kpml-02.txt". > > =09 > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > =09 > > =09 > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 18:16:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01005 for ; Mon, 23 Feb 2004 18:16:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvPIs-0000A9-NK for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 18:15:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NNFwXI000619 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 18:15:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvPIs-00009u-He for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 18:15:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00960 for ; Mon, 23 Feb 2004 18:15:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvPIp-0001B1-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 18:15:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvPI3-00014U-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 18:15:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvPH7-0000wU-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 18:14:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvPGz-0007xx-5t; Mon, 23 Feb 2004 18:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvPGY-0007qz-Pt for sipping@optimus.ietf.org; Mon, 23 Feb 2004 18:13:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00589 for ; Mon, 23 Feb 2004 18:13:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvPGV-0000tT-00 for sipping@ietf.org; Mon, 23 Feb 2004 18:13:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvPFY-0000lu-00 for sipping@ietf.org; Mon, 23 Feb 2004 18:12:33 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AvPEa-0000d6-00 for sipping@ietf.org; Mon, 23 Feb 2004 18:11:32 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1NNBSmR005491; Mon, 23 Feb 2004 18:11:28 -0500 (EST) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1NNBRH19671; Mon, 23 Feb 2004 18:11:27 -0500 Message-ID: <403A889F.4010601@cs.columbia.edu> Date: Mon, 23 Feb 2004 18:11:27 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel G. Petrie" CC: Gonzalo Camarillo , sipping Subject: Re: [Sipping] Config framework References: <4039FEAD.5070708@ericsson.com> <403A01BD.7080905@cs.columbia.edu> <403A250F.9B29CE10@pingtel.com> In-Reply-To: <403A250F.9B29CE10@pingtel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > This is certainly not the intension. The draft specifies a way to separately > subscribe for device or user profile data. I would be happy to clarify this > where you think the draft is vague or implies this restriction. > > Section 3.2 describes parameters that are device specific as even in the > ideal world, purely user specific data may need to consider the UA > implementation that it is to be applied to. Section 3.2 also specifies a > means to indicate the desire for user or device data. > > Section 3.13 specifies how to form the SUBSCRIBE URI based upon > the interest for either a device or user profile. 3.13 and 4.1 don't really spell out that user (as opposed to device) data may need to go elsewhere. It only has a single set of steps that aborts as soon as (say) DHCP-based discovery succeeds. I think the two modes, user and device, are somewhat dissimilar. For device, I may need to combine local information (e.g., information about outbound proxies and local dialplans) with home information (local dialplan, device-specific UI configuration, etc.). For user configuration, I probably need to assume that the device has an AOR, either initially or discovered via device configuration, which is realistic for laptops and other personal devices. 4.1 does not seem to spell out what to do if either the device or the user knows the AOR, but wants to get the remainder of the device and user configuration automatically. Thus, I'd suggest separating the two discovery models and possibly logically separating user configuration as being derived (among other sources of AORs) from the device configuration, as in: DHCP -> device configuration query -> AOR -> user-based query > These 3 important concepts are intended to be supported in > draft-ietf-sipping-config-framework-02. It is however difficult in > practice to keep these three things separate. In many environments > it is easier to keep two of the three separate. > > For example: > In an enterprise with physical devices that do not move much, it becomes > easier to combine the properties of 1 related to location with the properties > of 3. I'd rather be more general; if the user configuration spans multiple devices, it's a lot cleaner if I only have to update one server rather than each device-based server. (Device-based servers may well be more local than user-based servers.) > > When a user does not know their AOR or does not want to have to provide > it to the UA (to provide a plug and play experience), the user's AOR can be > associated with 3 (the device). 2 is may then be subscribe implicitly or explicitly. In my two-stage model, this is supported. > I think that this illustrates a very good point that the separation between > user and device profile data cannot be made concrete. Data such as > out bound proxy, or policy may be dictated by any or all of the 3 > realms defined above. Only the application and local administrative > policies can determine the realm to which data should be associated. > In addition it may be desirable to override some of the user or device > profile data based upon other local discovery data (e.g. DHCP options > for out bound proxy, STUN for NAT traversal). There may well be information that could be considered both, but in my book, user-based configuration is independent of where I plug in my device and does not depend on the device itself. Thus, an outbound proxy and related transport parameters are clearly device-related, while speed dial functionality, media preferences, home dial plans and buddy lists are probably not. Some parameters may be hierarchical, in that local network configuration overrides my general configuration. If my visited network doesn't allow video, that takes precedence over my user configuration that prefers video calls. > > At best we can define a precedence by which the device data > can be overridden by user data (or the other way around) > along with the ability for administrators to dictate policy (perhaps indicated > in the profile data) over what can be overridden. I agree. I think we'll have both directions of override. For example, a CIA agent user configuration may mandate use of TLS and AES encryption and accept that a call will fail in some local environments that don't allow this. Having a sample set of configuration parameters that we can work through might test our assumptions. draft-stredicke-sipping-ep-config-00.txt seems to be the last one on this topic, or is there something else? It unfortunately conflates local parameters (e.g., outbound proxy, 3.1.4.3) with user-based parameters (registration period, 3.1.4.1). Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 21:59:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08900 for ; Mon, 23 Feb 2004 21:59:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvSmN-0003pp-Sg for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 21:58:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O2wdUk014741 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 21:58:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvSmN-0003pg-6X for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 21:58:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08897 for ; Mon, 23 Feb 2004 21:58:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvSmK-00034X-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 21:58:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvSlM-00031J-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 21:57:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvSkq-0002yN-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 21:57:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvSkm-0003fo-0g; Mon, 23 Feb 2004 21:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvSkQ-0003cN-Fl for sipping@optimus.ietf.org; Mon, 23 Feb 2004 21:56:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08877 for ; Mon, 23 Feb 2004 21:56:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvSkN-0002xZ-00 for sipping@ietf.org; Mon, 23 Feb 2004 21:56:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvSjR-0002uI-00 for sipping@ietf.org; Mon, 23 Feb 2004 21:55:38 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AvSib-0002nT-00 for sipping@ietf.org; Mon, 23 Feb 2004 21:54:45 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1O2sBuC004588; Mon, 23 Feb 2004 18:54:14 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQO37318; Mon, 23 Feb 2004 18:54:10 -0800 (PST) In-Reply-To: <22ACFCD87A5780449EEBDD6D78BB8DB50C37EF@sylmail1> References: <22ACFCD87A5780449EEBDD6D78BB8DB50C37EF@sylmail1> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , sipping From: Rohan Mahy Subject: Re: [Sipping] updated dialog package Date: Mon, 23 Feb 2004 18:54:47 -0800 To: "Venkatesh Venkataramanan" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, On Feb 23, 2004, at 5:43 AM, Venkatesh Venkataramanan wrote: > Resending the same as my first posting somehow was empty in the > mailing list ! > > From a shared line application perspective: > > There is a piece missing from a implementation perspective for shared > line appearances. > > - Ability to signal Hold. I know there have been a few discussions > in the SIPPING mailing list around this and it there was no conclusion > about what "hold" actually is ! However, one of the important aspects > of shared lines is the ability to communicate a held call to the other > parties in the group. Currently the anil-sipping-bla draft uses the > SDP information to help other UA's decide a dialog is transitioning to > hold and off hold. It would be definitely useful to have the dialog > state express this state to the far end rather than having to send out > SDP information. I'm sorry. I dropped the ball on this. I was going to propose a new callee-caps style "media feature parameter" called "interactive". I think this satisfies the requirement for what folks are actually interested in for "hold", but I need to send out the proposal tomorrow to verify this with everyone on the list. > For the purpose of SLA, instead of going down defining what is Hold, I > was wondering if we can create a state/or an attribute in the dialog > state package say "pickable" dialog to indicate the same. I've heard > comments saying a UA can block relevant fields of a dialog whenever it > wants others to be able to pick or not to pick a dialog, however the > same is not clean why isn't this clean? > and it breaks when say the same UA that put the dialog on Hold, > retrieves the dialog. Nothing in the dialog identifiers have changed. I don't see why this is a problem. Also, if I'm already in a dialog, the implicit filtering of the dialog package prevent me from receiving notifications about state that I already know about directly. Not exactly sure what you mean. In any case, lets take two cases, cooperating and non-cooperating UAs. Cooperating UAs can use the presence or existence of dialog identifiers in notifications that they receive to convey that a call is pickable by them. Non-cooperating UAs that happen to learn the dialog identifiers but aren't authorized, can try to pick calls all they want, but will just get 403 Forbidden responses for their requests. thanks, -rohan > The anil-sipping-bla-draft covers other various aspects of SLA from an > application implementation perspective with call flow examples. > > regards, > Venkatesh > > -----Original Message----- > From: sipping-admin@ietf.org on behalf of Rohan Mahy > Sent: Thu 2/19/2004 9:59 AM > To: sipping > Cc: rohan@cisco.com > Subject: [Sipping] updated dialog package > > > > Hi Everyone, > > I've updated the dialog packages with the changes we agreed to in > Minneapolis (removing CSeq and the Route-Set). > > I've also provided a detailed example of using the dialog package for > a > "shared-line" application. I apologize for my tardiness here. I was > supposed to post something shortly after the meeting. I any case, I > believe this demonstrates that the current syntax is at least > sufficient for the use cases we've discussed. I would like to hear > from all of you if this does the trick. > > many thanks, > -rohan > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Feb 23 22:18:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09651 for ; Mon, 23 Feb 2004 22:18:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvT55-0004r3-3A for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 22:17:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O3HxP7018655 for sipping-archive@odin.ietf.org; Mon, 23 Feb 2004 22:17:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvT54-0004ql-Uo for sipping-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 22:17:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09636 for ; Mon, 23 Feb 2004 22:17:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvT51-0004hN-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 22:17:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvT48-0004bK-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 22:17:01 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AvT3E-0004VB-00 for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 22:16:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AvT3F-0006sE-Vd for sipping-web-archive@ietf.org; Mon, 23 Feb 2004 22:16:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvT3D-0004bO-Je; Mon, 23 Feb 2004 22:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvT2s-0004aI-SN for sipping@optimus.ietf.org; Mon, 23 Feb 2004 22:15:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09545 for ; Mon, 23 Feb 2004 22:15:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvT2p-0004Tn-00 for sipping@ietf.org; Mon, 23 Feb 2004 22:15:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvT1s-0004Q6-00 for sipping@ietf.org; Mon, 23 Feb 2004 22:14:41 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AvT1Y-0004MJ-00 for sipping@ietf.org; Mon, 23 Feb 2004 22:14:20 -0500 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 i1O3Dm4U019423; Mon, 23 Feb 2004 19:13:49 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQO38734; Mon, 23 Feb 2004 19:13:47 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8C2FF3B2-6677-11D8-9B6B-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , "sipping" From: Rohan Mahy Subject: Re: [Sipping] updated dialog package Date: Mon, 23 Feb 2004 19:14:24 -0800 To: "Paul Pepper" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Feb 23, 2004, at 9:40 AM, Paul Pepper wrote: > Hi, > > I work for a company that has developed handset gateway devices that > enable legacy, digital, business-grade telephones to be driven using > SIP. For example, this enables an existing legacy PBX user to retain > their telephones and cabling, but to replace the PBX by a Softswitch or > IP Centrex system. As most business-grade telephone systems make use > of > a shared line facility, the addition of a shared line example to the > dialog event package ID is of great interest to us, and others who > support these types of feature. > > Although incorporating a shared line example is a step towards a common > approach to shared line implementation, I don't believe it goes far > enough. Our current implementation of shared lines has shown that the > following issues need to be addressed by the spec, and should be shown > in the examples: > > o Line seize, an essential part of any shared line implementation, is > not adequately described. When more than one user agent attempts to > seize a line at approximately the same instant, a race condition > arises. > No description of how to handle the race is given - an example > application/dialog-info+xml NOTIFY payload is provided, but this alone > is inadequate, as message sequencing is an important part of seizing a > line. The Line Seize condition will be covered in the > "anil-sipping-bla-draft" that Venkatesh refers to. Line seizure is well beyond what would be appropriate to standardize in SIPPING because for many types of UAs that concept does not even exist. I was just trying to demonstrate a non-normative description of how it could be implemented. How you judge who "wins" a seizure race condition is an implementation specific issue. In fact, its quite likely that different behaviors will be desired by different customers. When talking about implementing this at Cisco, we concluded that a configuration knob was needed to satisfy essentially opposite requirements from two different customers. Each customer was equally adamant that he was "right" and the other was "wrong". As a result, I find it unlikely that SIPPING could come to come to consensus on what "proper seizing behavior" is even if we ignored the fact that the bulk of deployed SIP UAs are software UAs which have no lines to seize. > o Handling of multiple instances of a shared line has been overlooked. > On business-grade PBX systems a line will roughly correspond to an AOR. > However, many such systems permit multiple "instances" of a shared line > to appear on a single endpoint. For example, a number of instances of a > "product support" shared line might appear on all the endpoints of the > product support group, thereby allowing multiple calls to be taken and > passed around within the group. This has not been overlooked at all. You can have multiple subscriptions (one per AOR), or you can subscribe to a list of AORs with the event list extension: http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-04.txt > o The mechanism used to convey that a call has been placed on hold > appears to rely upon implementation-specific parameters, found in the > xml's element. I can't see any reference to definitions of the > values used by this element's pname and pval attributes > (pname="+activity" pval="noninteractive"), so I assume they're > non-standard. This was due to distraction on my part. I had intended to include a discussion of this in the current draft, but somehow left it out at 2am the day of the draft deadline. I'm terribly sorry about that. I'll send out more about the hold issue tomorrow. thanks, -rohan > Thanks, > > Paul. > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@cisco.com] >> Sent: Thursday, February 19, 2004 6:00 PM >> To: sipping >> Cc: rohan@cisco.com >> Subject: [Sipping] updated dialog package >> >> >> Hi Everyone, >> >> I've updated the dialog packages with the changes we agreed to in >> Minneapolis (removing CSeq and the Route-Set). >> >> I've also provided a detailed example of using the dialog >> package for a >> "shared-line" application. I apologize for my tardiness here. I was >> supposed to post something shortly after the meeting. I any case, I >> believe this demonstrates that the current syntax is at least >> sufficient for the use cases we've discussed. I would like to hear >> from all of you if this does the trick. >> >> many thanks, >> -rohan >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 00:55:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16000 for ; Tue, 24 Feb 2004 00:55:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvVWv-00077S-3D for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 00:54:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O5sqK2027359 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 00:54:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvVWu-00077C-EN for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 00:54:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15958 for ; Tue, 24 Feb 2004 00:54:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvVWr-000226-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 00:54:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvVVq-0001vd-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 00:53:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvVV9-0001rA-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 00:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvVV7-0006wx-6t; Tue, 24 Feb 2004 00:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvVUo-0006wf-Kp for sipping@optimus.ietf.org; Tue, 24 Feb 2004 00:52:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15898 for ; Tue, 24 Feb 2004 00:52:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvVUl-0001pb-00 for sipping@ietf.org; Tue, 24 Feb 2004 00:52:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvVTp-0001lE-00 for sipping@ietf.org; Tue, 24 Feb 2004 00:51:41 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AvVSu-0001dd-00 for sipping@ietf.org; Tue, 24 Feb 2004 00:50:44 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1O5oAtf004816; Tue, 24 Feb 2004 14:50:10 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1O5o9vq007317; Tue, 24 Feb 2004 14:50:09 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1O5o8ui029639; Tue, 24 Feb 2004 14:50:08 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1O5o8ZK029630; Tue, 24 Feb 2004 14:50:08 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1O5o632029036; Tue, 24 Feb 2004 14:50:07 +0900 (JST) Received: from img.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id OAA05572; Tue, 24 Feb 2004 14:50:05 +0900 (JST) Received: from lab.ntt.co.jp by img.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with SMTP id OAA05373; Tue, 24 Feb 2004 14:50:04 +0900 (JST) Date: Tue, 24 Feb 2004 14:49:51 +0900 From: Kumiko Ono To: Gonzalo Camarillo , sipping Cc: volkerh@bell-labs.com, tachimoto.shinya@lab.ntt.co.jp MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 3.07beta6 (WinNT,501) In-Reply-To: <403A0679.1010609@ericsson.com> References: <403A0679.1010609@ericsson.com> Message-Id: <6AC3FA9A0545F4ono.kumiko@lab.ntt.co.jp> Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: E2M security solution Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I agree with you about the e2m security solution could partly solve the session-specific policies. In my understanding, the policy draft proposes new headers to disclose only the information to *all* proxies in the path. Some mechanism are needed in order to disclose the information to *specific* proxies. The e2m security can be applied as one of the mechanisms. Regards, Kumiko >Hello, > >The e2m security solution, described in the draft below, >http://www.ietf.org/internet-drafts/draft-ono-sipping-end2middle-security- >01.txt > >attempts to resolve some of the problems that the session-specific >policies draft addresses: >http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-spec-policy- >00.txt > >The need of a UA to obtain the policies that a particular proxy has is >dealt with in both drafts. In addition, the e2m security draft talks >about disclosing information to intermediaries. The policy draft >addresses this issue and defines a means to disclose *only* the >information needed by the proxy. > >My comments on the e2m requirements draft apply also to this one. We >should try to align both efforts (session policies and e2m security). > >Thanks, > >Gonzalo > > >This communication is confidential and intended solely for the addressee(s) >. Any unauthorized review, use, disclosure or distribution is prohibited. >If you believe this message has been sent to you in error, please notify >the sender by replying to this transmission and delete the message without >disclosing it. Thank you. > >E-mail including attachments is susceptible to data corruption, >interruption, unauthorized amendment, tampering and viruses, and we only >send and receive e-mails on the basis that we are not liable for any such >corruption, interception, amendment, tampering or viruses or any >consequences thereof. -- Kumiko Ono NTT Network Service Systems Labs. Tel +81 422 59 4508/Fax +81 422 60 4012 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 03:21:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06098 for ; Tue, 24 Feb 2004 03:21:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvXoJ-00007r-8K for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 03:20:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O8KxHT000482 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 03:20:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvXoI-00007h-Vb for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 03:20:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06078 for ; Tue, 24 Feb 2004 03:20:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvXoG-0000gW-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 03:20:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvXnK-0000aQ-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 03:19:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvXmQ-0000Uu-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 03:19:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvXmP-0008Lk-Sz; Tue, 24 Feb 2004 03:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvXmI-0008KT-Dc for sipping@optimus.ietf.org; Tue, 24 Feb 2004 03:18:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05942 for ; Tue, 24 Feb 2004 03:18:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvXmG-0000TZ-00 for sipping@ietf.org; Tue, 24 Feb 2004 03:18:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvXlK-0000Nl-00 for sipping@ietf.org; Tue, 24 Feb 2004 03:17:55 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AvXke-0000Iv-00 for sipping@ietf.org; Tue, 24 Feb 2004 03:17:12 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1O8HCYG027598 for ; Tue, 24 Feb 2004 09:17:12 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 09:17:12 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FKWDR6D8; Tue, 24 Feb 2004 09:17:12 +0100 Message-ID: <403B0888.4070601@ericsson.com> Date: Tue, 24 Feb 2004 10:17:12 +0200 X-Sybari-Trust: 18cfd69a c77f3eb6 59788f6c 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: sipping , Henning Schulzrinne , Eric Burger Subject: Re: [Sipping] SDP in draft-ietf-sipping-transc-3pcc-00 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2004 08:17:12.0716 (UTC) FILETIME=[9AEFB4C0:01C3FAAE] Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cullen, inline: Cullen Jennings wrote: > SDP is a scary place so using SDP to separate the SDP bodies for A and B is > scary. Consider the following use case: > > I have a transcoder that takes a audio from a UA connected to a microphone > and another camera UA that sends video. I am going to feed both of these to > a transcoder and produce a single mpeg output stream that contains both > audio video. Here I need so specify that the input SDP has two IP addresses > and the output has one. This would be even more complicated if one UA did > the offer/ans in INV/200 while the other used the 200/ACK. > > Also related to all this, would be nice to be confident that pre conditions > stuff worked while using all this. > > Anyways, I like the overall solution to all this stuff. I wish there was a > better solution to separating the A+B, TA+TB information to the transcoder > than adding more semantics to SDP. Previous version of this draft use to provide this information using SDP attributes, which were defined in the draft below: http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-source-sink-01.txt Nevertheless, the feedback we got from, among others, MMUSIC and SIPPING, was that we did not need those parameters. The Request-URI will indentify the service the transcoder provides, making unnecessary more information. In your example, you would have a URI that indentifies the service (taking both inputs and creating the mpeg). Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 03:38:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06924 for ; Tue, 24 Feb 2004 03:38:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvY4g-0001Vw-Tp for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 03:37:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O8bs7O005810 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 03:37:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvY4g-0001VZ-2h for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 03:37:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06900 for ; Tue, 24 Feb 2004 03:37:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvY4d-0002Nb-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 03:37:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvY3j-0002IA-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 03:36:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvY2u-0002D3-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 03:36:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvY2s-0001Al-Kz; Tue, 24 Feb 2004 03:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvY2i-00019x-HW for sipping@optimus.ietf.org; Tue, 24 Feb 2004 03:35:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06806 for ; Tue, 24 Feb 2004 03:35:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvY2g-0002BF-00 for sipping@ietf.org; Tue, 24 Feb 2004 03:35:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvY1m-00026k-00 for sipping@ietf.org; Tue, 24 Feb 2004 03:34:55 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AvY15-00022F-00 for sipping@ietf.org; Tue, 24 Feb 2004 03:34:11 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1O8YBAh022735 for ; Tue, 24 Feb 2004 09:34:11 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 09:34:11 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FMHBTZ4M; Tue, 24 Feb 2004 09:34:19 +0100 Message-ID: <403B0C82.20407@ericsson.com> Date: Tue, 24 Feb 2004 10:34:10 +0200 X-Sybari-Trust: f6e91cc3 c77f3eb6 59788f6c 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping CC: Cullen Jennings , bstucker@nortelnetworks.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2004 08:34:11.0417 (UTC) FILETIME=[FA212490:01C3FAB0] Content-Transfer-Encoding: 7bit Subject: [Sipping] UA indentification and HIP Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, the following two drafts describe how to indentify a particular UA using globally unique identifiers: http://www.ietf.org/internet-drafts/draft-stucker-sip-guid-00.txt http://www.ietf.org/internet-drafts/draft-jennings-sipping-instance-id-00.txt Cullen pointed out that this work may be able to take advantage of the work carried out in the HIP (Host Identity Protocol) WG, which supplemental web page is: http://hip.piuha.net/ Here you have a *very* brief introduction to HIP. I will also be providing a brief introduction to the drafts above to the HIP community. Hopefully, we will have a useful exchange of ideas between both WGs. HIP consists of a layer between the network and the tranport layers (e.g., between IP and TCP). It uses HIs (Host Identifiers) to identify hosts. The idea is that, when a host changes its IP address, it keeps its HI. This facilitates mobility, for instance. HIs (Host Identifiers) are public keys, which may have different lengths and formats. To resolve this, HIP defines the HITs (Host Identity Tags), which are hashes of the HI. That is, a HIT is a hash of a public key. They are 128 bit long, and can be used instead of IPv6 addresses in socket calls. HIP also defines LSIs (Local Scope Indetifiers), that are 32 bit long and can be used instead of IPv4 addresses in socket calls. Regards, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 04:26:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08846 for ; Tue, 24 Feb 2004 04:26:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYpJ-0005Sf-Rg for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 04:26:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O9Q5Bf020975 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 04:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYpH-0005SE-DB for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 04:26:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08802 for ; Tue, 24 Feb 2004 04:26:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvYpE-0006PE-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 04:26:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvYo8-0006Id-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 04:24:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvYnO-0006ES-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 04:24:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYnN-0005Fm-Bm; Tue, 24 Feb 2004 04:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYmK-00058K-L5 for sipping@optimus.ietf.org; Tue, 24 Feb 2004 04:23:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08715 for ; Tue, 24 Feb 2004 04:22:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvYmH-000684-00 for sipping@ietf.org; Tue, 24 Feb 2004 04:22:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvYlM-00063S-00 for sipping@ietf.org; Tue, 24 Feb 2004 04:22:01 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AvYl3-0005yc-00 for sipping@ietf.org; Tue, 24 Feb 2004 04:21:41 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1O9LgqY004097 for ; Tue, 24 Feb 2004 10:21:42 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 10:21:42 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FMHB4RKW; Tue, 24 Feb 2004 10:21:50 +0100 Message-ID: <403B17A5.1040700@ericsson.com> Date: Tue, 24 Feb 2004 11:21:41 +0200 X-Sybari-Trust: a57f479b c77f3eb6 59788f6c 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping CC: a.vwijk@viataal.nl, gv@trace.wisc.edu, henry.sinnreich@mci.com, rrroy@att.com, paulej@packetizer.com, gunnar.hellstrom@omnitor.se, barry.dingle@bigfoot.com.au Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2004 09:21:42.0297 (UTC) FILETIME=[9D62E890:01C3FAB7] Content-Transfer-Encoding: 7bit Subject: [Sipping] ToIP Requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, the draft below provides a set of requirements for real-time conversations using SIP. http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-toip-01.txt Nevertheless, I have found a lot of device requirements in the text, but I fail to understand which particular protocol requirements we need to fulfill with new protocol extensions. While SIPPING is the right place to handle requirements that will lead to new SIP protocol extensions, SIPPING may not be the right place to deal with device requirements (e.g., text phones MUST have a display of at least 100 characters). Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 04:35:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09120 for ; Tue, 24 Feb 2004 04:35:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYxu-0005ye-Ln for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 04:34:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O9YwqR022944 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 04:34:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYxs-0005xp-Hu for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 04:34:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09105 for ; Tue, 24 Feb 2004 04:34:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvYxp-00076I-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 04:34:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvYwu-00071i-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 04:33:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvYw4-0006x4-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 04:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYw2-0005jN-3r; Tue, 24 Feb 2004 04:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYvu-0005ip-E0 for sipping@optimus.ietf.org; Tue, 24 Feb 2004 04:32:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09063 for ; Tue, 24 Feb 2004 04:32:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvYvr-0006vb-00 for sipping@ietf.org; Tue, 24 Feb 2004 04:32:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvYuz-0006s1-00 for sipping@ietf.org; Tue, 24 Feb 2004 04:31:57 -0500 Received: from firewall.citel.com ([62.190.107.60] helo=ivor.citel.com) by ietf-mx with esmtp (Exim 4.12) id 1AvYuc-0006nY-00 for sipping@ietf.org; Tue, 24 Feb 2004 04:31:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable content-class: urn:content-classes:message Date: Tue, 24 Feb 2004 09:30:48 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: Thread-Topic: Roaming Architecture for SIP vs Mobile IP Thread-Index: AcP6uTK52evysk9FQa2afn6zJeQqTw== From: "Steve Langstaff" To: Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Roaming Architecture for SIP vs Mobile IP Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All. =20 Sorry if this is a much asked and much answered question, but haven't the basic problems being solved in a "Roaming Architecture for SIP", i.e. allowing a SIP host to roam to foreign networks, already been solved using Mobile IP? What else does "Roaming Architecture for SIP" give me? =20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 05:30:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11496 for ; Tue, 24 Feb 2004 05:30:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZp9-0001oz-5p for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 05:29:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OATxen006997 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 05:29:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZp8-0001oj-MI for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 05:29:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11482 for ; Tue, 24 Feb 2004 05:29:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvZp5-000432-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 05:29:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvZoA-0003yR-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 05:28:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvZnJ-0003tk-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 05:28:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZnF-0001an-LU; Tue, 24 Feb 2004 05:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZmH-0001aG-R3 for sipping@optimus.ietf.org; Tue, 24 Feb 2004 05:27:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11427 for ; Tue, 24 Feb 2004 05:26:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvZmE-0003nq-00 for sipping@ietf.org; Tue, 24 Feb 2004 05:26:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvZlM-0003jK-00 for sipping@ietf.org; Tue, 24 Feb 2004 05:26:05 -0500 Received: from natsmtp00.rzone.de ([81.169.145.165] helo=natsmtp00.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 1AvZkt-0003eI-00 for sipping@ietf.org; Tue, 24 Feb 2004 05:25:35 -0500 Received: from RocknRoll (pD9E6D8F4.dip.t-dialin.net [217.230.216.244]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i1OAPVnI021346; Tue, 24 Feb 2004 11:25:32 +0100 (MET) From: "Harry Behrens" To: "'Steve Langstaff'" , Subject: AW: [Sipping] Roaming Architecture for SIP vs Mobile IP Date: Tue, 24 Feb 2004 11:27:08 +0100 Message-ID: <006401c3fac0$c2e6db40$2c00a8c0@RocknRoll> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Steve, I do not think one can always assume the existence of Mobile IP on SIP UAs, in fact I have yet to see one instance of such a combination - unless custom-made. While MIP is a good concept in theory, it is less than widely spread and cannot be assumed as given in any standard application or IP stack. Furthermore - depending on the exact configuration - MIP introduces additional latencies, which is something to be avoided for VoIP. You are however correct in stating that MIP is one approach to solving roaming issues. I believe its most obvious application seems to be WLAN/GSM/3GPP, i.e. layer 2 or layer 3 rather than layer 5-7. The focus on this draft is to have a pure SIP-based approach, specifically geared towards VoIP. As you are probably aware, we are still far away from having completely vertically integrated AAA infrastructures - though an NAI-based approach could eventually lead there. Regards, Harry > -----Urspr=FCngliche Nachricht----- > Von: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]=20 > Im Auftrag von Steve Langstaff > Gesendet: Dienstag, 24. Februar 2004 10:31 > An: sipping@ietf.org > Betreff: [Sipping] Roaming Architecture for SIP vs Mobile IP >=20 >=20 > Hi All. > =20 > Sorry if this is a much asked and much answered question, but=20 > haven't the basic problems being solved in a "Roaming=20 > Architecture for SIP", i.e. allowing a SIP host to roam to=20 > foreign networks, already been solved using Mobile IP? What=20 > else does "Roaming Architecture for SIP" give me? > =20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 05:57:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12680 for ; Tue, 24 Feb 2004 05:57:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvaFE-000444-BY for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 05:56:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OAuuKI015624 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 05:56:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvaFE-00043v-6H for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 05:56:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12658 for ; Tue, 24 Feb 2004 05:56:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvaFA-0006Xe-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 05:56:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvaEE-0006Tj-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 05:55:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvaDV-0006QJ-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 05:55:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvaDN-0003oo-I2; Tue, 24 Feb 2004 05:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvaCO-0003mg-Q5 for sipping@optimus.ietf.org; Tue, 24 Feb 2004 05:54:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12596 for ; Tue, 24 Feb 2004 05:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvaCL-0006Jh-00 for sipping@ietf.org; Tue, 24 Feb 2004 05:53:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvaBU-0006Fr-00 for sipping@ietf.org; Tue, 24 Feb 2004 05:53:05 -0500 Received: from natsmtp01.rzone.de ([81.169.145.166]) by ietf-mx with esmtp (Exim 4.12) id 1AvaAu-0006BA-00 for sipping@ietf.org; Tue, 24 Feb 2004 05:52:28 -0500 Received: from RocknRoll (pD9E6D8F4.dip.t-dialin.net [217.230.216.244]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i1OAqIKN017822; Tue, 24 Feb 2004 11:52:20 +0100 (MET) From: "Harry Behrens" To: "'Paul Kyzivat'" Cc: , Subject: AW: [Sipping] Roaming Architecture for SIP Date: Tue, 24 Feb 2004 11:53:55 +0100 Message-ID: <007201c3fac4$826a1470$2c00a8c0@RocknRoll> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <403A4AAA.30206@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Paul, inline > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Gesendet: Montag, 23. Februar 2004 19:47 > An: Harry Behrens > Cc: sipping@ietf.org; knuettel@fokus.fraunhofer.de > Betreff: Re: [Sipping] Roaming Architecture for SIP >=20 >=20 > I have specific comment inline below, and then a question. >=20 > Paul >=20 > > - A user registers with the VN (atlanta.com in the call flow=20 > > given). The user submits his NAI in new header field 'P-NAI'.=20 > > The user submits a bogus URI in both the From and the=20 > To header.=20 > > (F1 in section 8.2.1) > > - The VN recognizes the registration as a P-NAI registration and=20 > > sends back a "401 Unauthorized" response, with both=20 > the 'From'=20 > > and the 'To' URI set to the temporary URI that will=20 > be assigned=20 > > to the user upon successful authentication and authorization=20 > > (F2). >=20 > This isn't legal. The From and To (with exception of To-tag)=20 > of response=20 > must be same as in the request. >=20 This is true. The reason we have this crutch in there is to allow the VN server to pass a user ID to the client, which the client can use to register to the VN. This would otherwise have to happen out-of-band, which we were trying to avoid. We are thinking about alternative approaches to this requirement and are grateful for any input. > The question is: why would the UAC want to register with the VN?=20 > Assuming it is able to send sip messages, (which apparently=20 > it can), why=20 > wouldn't it simply send a REGISTER to its HN? >=20 > I presume there must be some service that you intend the VN won't=20 > perform, that will prevent the UAC from doing this. But it isn't=20 > apparent what service that is. >=20 The scenario is of a user based e.g. in Berlin/Germany on a business trip in Beijing/China. The user will want to both be reachable under his home AOR (for that he registers with his HN) as well as make use of the VN for local calls, especially local PSTN breakout (this is why he wants to have a valid registration with the VN). Furthermore, in a number of cases, one encounters RTP-proxying, where around-the-world loops are to be avoided. Another issue which we foresee is that in the near future hotels, airports or other semi-closed (walled garden) Internet access points, will force users through their own VoIP (SIP) proxy infrastructure, similar to what a lot of sites aleady do in the case of HTTP. Harry > Paul >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 07:11:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15254 for ; Tue, 24 Feb 2004 07:11:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbOt-0000Mu-Oe for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 07:11:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OCAxLv001412 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 07:10:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbOt-0000Mh-FA for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 07:10:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15220 for ; Tue, 24 Feb 2004 07:10:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbOp-00056d-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:10:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbNt-00051S-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:09:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvbN3-0004xO-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:09:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbMz-0008Tk-2V; Tue, 24 Feb 2004 07:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbM4-0008QD-Gx for sipping@optimus.ietf.org; Tue, 24 Feb 2004 07:08:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15134 for ; Tue, 24 Feb 2004 07:08:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbM0-0004s3-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:08:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbL4-0004ne-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:07:02 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AvbKH-0004j1-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:06:13 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1OC6EqY016517 for ; Tue, 24 Feb 2004 13:06:14 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 13:06:14 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FKWD4DJX; Tue, 24 Feb 2004 13:06:14 +0100 Message-ID: <403B3E35.9010304@ericsson.com> Date: Tue, 24 Feb 2004 14:06:13 +0200 X-Sybari-Trust: 86b586af c77f3eb6 59788f6c 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping CC: Alan Johnston , Orit Levin , Miguel Angel Garcia Martin Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2004 12:06:14.0314 (UTC) FILETIME=[999128A0:01C3FACE] Content-Transfer-Encoding: 7bit Subject: [Sipping] Conferencing for UAs Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, some comments on the following draft: http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conferencing-03.txt The focus of a conference returns the conference URI in the contact header field of the 200 OK for the INVITE. The UAC uses this URI to SUBSCRIBE to the conf package (using a new dialog)... Why are we forcing the focus to use the same URI for receiving the INVITEs from all the users and for receiving the SUBSCRIBEs? I believe the solution would be cleaner if we defined a new header field (e.g., Associated-Conf-State) that carried a globally routable URI. The 200 OK for the initial INVITE (or the INVITE in a dial-out case) would carry this header field. This would keep separate the URI used for joining the conference and the URI used for subscribing to the state of the conference. This is actually the approach that the draft below follows: http://www.ietf.org/internet-drafts/draft-camarillo-sipping-transac-package-00.txt We define the Associated-Transactions-State to be returned, for example, in the 200 OK of a MESSAGE sent to an exploder. Note that we had to create this new header because MESSAGE does not carry a Contact header... following the same approach in both, the conferencing work and the exploders work would be good, in my opinion. Comments? Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 07:17:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15604 for ; Tue, 24 Feb 2004 07:17:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbV4-00011s-DP for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 07:17:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OCHMPd003950 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 07:17:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbV4-00011d-9j for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 07:17:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15498 for ; Tue, 24 Feb 2004 07:17:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbV3-0005nY-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:17:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbTq-0005cZ-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:16:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvbSr-0005WS-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:15:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbSq-0000eL-39; Tue, 24 Feb 2004 07:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbRs-0000d8-CZ for sipping@optimus.ietf.org; Tue, 24 Feb 2004 07:14:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15410 for ; Tue, 24 Feb 2004 07:14:03 -0500 (EST) From: Miguel.An.Garcia@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbRr-0005QU-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:14:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbR0-0005Lv-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:13:11 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1AvbQe-0005Gn-00; Tue, 24 Feb 2004 07:12:48 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1OCBkS03127; Tue, 24 Feb 2004 14:12:16 +0200 (EET) X-Scanned: Tue, 24 Feb 2004 14:11:25 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i1OCBP9d002598; Tue, 24 Feb 2004 14:11:25 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00RGtzt5; Tue, 24 Feb 2004 14:11:23 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1OCBM701440; Tue, 24 Feb 2004 14:11:22 +0200 (EET) Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 24 Feb 2004 14:11:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2004 14:11:20 +0200 Message-ID: <357AEC66DB509A4EA46CB85D7968B6AF46753E@esebe006.ntc.nokia.com> Thread-Topic: [Simple] Advanced IM requirements Thread-Index: AcP5C/kBvwKHvMXJS6urOHqe9sfskgA3pGvQABD6gKAAJ+XiMA== To: , , X-OriginalArrivalTime: 24 Feb 2004 12:11:22.0262 (UTC) FILETIME=[511E4B60:01C3FACF] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: Advanced IM requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable A comment on the usage of the Require header in the MESSAGE receipt = draft. As far as I know, the Require header is used to indicate the peer that = the request should not be processed if the extension is not supported. You apply the Require header to the response... which is a bit weird, = because you tell me what should be the action of the UAC if it does not = support the functionality. You can argue that we have already used Require headers in SIP responses = (e.g.., 100rel). But there it had a clear meaning: there is an action = that has to be taken upon the reception of the response: to generate a = PRACK. But in your draft, I didn't see an equivalence. In my view, this mechanism should only be applicable to Support headers = in requests. If the message is no delivered, then a DSN can be = generated, because of the Support header tag in the request. And that comes to my next question. Do you intend proxies to generate = DSNs to non delivered messages? I guess this is the idea, but I didn't = find a "Proxy behavior" section in the document. /Miguel > -----Original Message----- > From: sipping-admin@ietf.org=20 > [mailto:sipping-admin@ietf.org]On Behalf Of > ext Chris Boulton > Sent: 23 February, 2004 19:01 > To: Simple WG; sipping > Subject: [Sipping] FW: [Simple] Advanced IM requirements >=20 >=20 >=20 >=20 > As promised. >=20 > https://www.ubiquity.net/draft-boulton-sipping-message-receipt-00.txt >=20 > Chris. >=20 >=20 > >-----Original Message----- > >From: Chris Boulton > >Sent: 23 February 2004 10:40 > >To: 'Jonathan Rosenberg'; Simple WG > >Cc: 'sipping@ietf.org' > >Subject: RE: [Simple] Advanced IM requirements > > > >Hi Jonathan et al, > > > > I have an extremely early version (so be gentle) of a draft > aimed at > >supplying IM delivery reports. It hasn't been formally submitted yet > but I > >have attached a copy - so would be grateful if the list could take a > look > >and see if it's worth progressing. I will submit to the archives in > the > >next few days. I will also put this on the internet=20 > somewhere in case > this > >attachment doesn't survive its journey (Will send link later). > > > >Best Regards, > > > >Chris. > > > > > >>-----Original Message----- > >>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >>Sent: 22 February 2004 06:17 > >>To: Simple WG > >>Subject: [Simple] Advanced IM requirements > >> > >>Folks, > >> > >>As I noted earlier, I resubmitted the advanced IM=20 > requirements draft. > It > >>specifies a bunch of advanced IM functions we havent yet=20 > tackled here. > >>They are: > >> > >>* delivery reports for IM > >>* is-typing indicator (Henning had an I-D on this that has expired) > >>* capabilities indications of maximum desired message sizes for IM > >>* page mode groups (under discussion in the context of exploders in > >>sipping) > >>* invitations to non-real time sessions > >> > >> > >>The last of these is particularly interesting. One use case is "call > >>alerts" in PTT. There, I send you a request to have a PTT chat. The > >>request is not answered in real time. Rather, its stored by the > >>recipient as if it were an IM, and can be answered at any=20 > time later. > >>"Answering it" merely involves setting up a PTT call back to the > caller. > >>Its also possible to cancel the call alert at any time. > >> > >>There are some interesting ways to accomplish this function. The one > >>I've been thinking about is taking a SIP INVITE message, and sending > it > >>in the body of a MESSAGE request as a message/sip content. I'm sure > >>there are other ways. > >> > >>Are these topics for which there is still group interest in working > on? > >>I think all of them remain quite important. > >> > >>Thanks, > >>Jonathan R. > >>-- > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>Chief Technology Officer Parsippany, NJ=20 > 07054-2711 > >>dynamicsoft > >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >>http://www.jdrosen.net PHONE: (973) 952-5000 > >>http://www.dynamicsoft.com > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > This message has been scanned for viruses by MailControl -=20 www.mailcontrol.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 07:21:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16081 for ; Tue, 24 Feb 2004 07:21:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbYd-0001UA-Fx for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 07:21:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OCL3Xd005696 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 07:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbYc-0001Tj-Jw for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 07:21:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16007 for ; Tue, 24 Feb 2004 07:21:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbYb-0006OZ-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:21:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbXe-0006FS-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:20:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvbWg-00064y-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:19:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbWg-00018w-5S; Tue, 24 Feb 2004 07:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbWC-00016j-TG for sipping@optimus.ietf.org; Tue, 24 Feb 2004 07:18:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15736 for ; Tue, 24 Feb 2004 07:18:32 -0500 (EST) From: Miguel.An.Garcia@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbWC-0005zJ-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:18:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbV0-0005nE-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:17:18 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1AvbTp-0005cD-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:16:05 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1OCFuT10570; Tue, 24 Feb 2004 14:15:56 +0200 (EET) X-Scanned: Tue, 24 Feb 2004 14:15:56 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i1OCFusk018273; Tue, 24 Feb 2004 14:15:56 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00e94Xm4; Tue, 24 Feb 2004 14:15:55 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1OCFn705173; Tue, 24 Feb 2004 14:15:49 +0200 (EET) Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 24 Feb 2004 14:15:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2004 14:15:30 +0200 Message-ID: <357AEC66DB509A4EA46CB85D7968B6AF84E117@esebe006.ntc.nokia.com> Thread-Topic: Conferencing for UAs Thread-Index: AcP6ztU4oXJ9S3miSPeZmrd+xR68KAAAM6bg To: , Cc: , X-OriginalArrivalTime: 24 Feb 2004 12:15:50.0040 (UTC) FILETIME=[F0B9F980:01C3FACF] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: Conferencing for UAs Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Gonzalo: The idea is fine, but I am afraid we may end up defining = Associated-Transaction-State, Associated-Conference-State, = Associated-XXX-State. Aren't we heading to defining a generic Associated-State header with a = "role" parameter that contains a value "transaction", "conference", = "xxx", etc... /Miguel > -----Original Message----- > From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: 24 February, 2004 14:06 > To: sipping > Cc: Alan Johnston; Orit Levin; Garcia Miguel.An (Nokia-NRC/Helsinki) > Subject: Conferencing for UAs >=20 >=20 > Hello, >=20 > some comments on the following draft: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conf > erencing-03.txt >=20 > The focus of a conference returns the conference URI in the contact=20 > header field of the 200 OK for the INVITE. The UAC uses this URI to=20 > SUBSCRIBE to the conf package (using a new dialog)... >=20 > Why are we forcing the focus to use the same URI for receiving the=20 > INVITEs from all the users and for receiving the SUBSCRIBEs?=20 > I believe=20 > the solution would be cleaner if we defined a new header field (e.g.,=20 > Associated-Conf-State) that carried a globally routable URI.=20 > The 200 OK=20 > for the initial INVITE (or the INVITE in a dial-out case) would carry=20 > this header field. This would keep separate the URI used for=20 > joining the=20 > conference and the URI used for subscribing to the state of=20 > the conference. >=20 > This is actually the approach that the draft below follows: > http://www.ietf.org/internet-drafts/draft-camarillo-sipping-tr ansac-package-00.txt We define the Associated-Transactions-State to be returned, for example, = in the 200 OK of a MESSAGE sent to an exploder. Note that we had to=20 create this new header because MESSAGE does not carry a Contact=20 header... following the same approach in both, the conferencing work and = the exploders work would be good, in my opinion. Comments? Thanks, Gonzalo This communication is confidential and intended solely for the = addressee(s). Any unauthorized review, use, disclosure or distribution = is prohibited. If you believe this message has been sent to you in = error, please notify the sender by replying to this transmission and = delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, = interruption, unauthorized amendment, tampering and viruses, and we only = send and receive e-mails on the basis that we are not liable for any = such corruption, interception, amendment, tampering or viruses or any = consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 07:25:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16338 for ; Tue, 24 Feb 2004 07:25:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbcO-00028X-Ga for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 07:24:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OCOuxj008207 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 07:24:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbcO-00028I-CI for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 07:24:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16300 for ; Tue, 24 Feb 2004 07:24:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbcN-0006oQ-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:24:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbbR-0006ib-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:23:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvbaY-0006dQ-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:23:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbaX-0001hX-Fw; Tue, 24 Feb 2004 07:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbZn-0001eF-Ji for sipping@optimus.ietf.org; Tue, 24 Feb 2004 07:22:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16166 for ; Tue, 24 Feb 2004 07:22:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbZn-0006Yd-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:22:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbYw-0006RV-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:21:23 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AvbY4-0006Ih-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:20:28 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1OCKQYG029748 for ; Tue, 24 Feb 2004 13:20:26 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 13:20:26 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FMFLYZ46; Tue, 24 Feb 2004 13:20:37 +0100 Message-ID: <403B418A.8020004@ericsson.com> Date: Tue, 24 Feb 2004 14:20:26 +0200 X-Sybari-Trust: b1e16697 c77f3eb6 59788f6c 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel.An.Garcia@nokia.com CC: sipping@ietf.org, alan.johnston@mci.com, oritl@microsoft.com References: <357AEC66DB509A4EA46CB85D7968B6AF84E117@esebe006.ntc.nokia.com> In-Reply-To: <357AEC66DB509A4EA46CB85D7968B6AF84E117@esebe006.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2004 12:20:26.0606 (UTC) FILETIME=[959298E0:01C3FAD0] Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Conferencing for UAs Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > Aren't we heading to defining a generic Associated-State header with > a "role" parameter that contains a value "transaction", "conference", > "xxx", etc... I actually do not care how we encode this information; in a header with several parameters or in multiple headers (in any case, you may be right that using a single header could be cleaner). What I want to know is whether or not people think that it is worthwhile keeping separate the URI used for the INVITE dialog and the one (or ones) used for subscriptions to some piece of state that is associated somehow with that dialog. My personal opinion is that we should keep them separate. Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 07:27:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16487 for ; Tue, 24 Feb 2004 07:27:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbeV-0002cb-Ip for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 07:27:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OCR7Y9010071 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 07:27:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbeV-0002cM-FS for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 07:27:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16434 for ; Tue, 24 Feb 2004 07:27:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbeU-00075g-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:27:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbdU-0006x7-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:26:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvbcW-0006pc-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbcU-00029J-OX; Tue, 24 Feb 2004 07:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbbW-0001qd-0B for sipping@optimus.ietf.org; Tue, 24 Feb 2004 07:24:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16272 for ; Tue, 24 Feb 2004 07:24:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbbV-0006j3-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:24:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avbaj-0006et-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:23:13 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly02b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AvbaF-0006YQ-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:22:44 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly02b.srv.mailcontrol.com (MailControl) with SMTP id i1OCM74O031325; Tue, 24 Feb 2004 12:22:08 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Tue, 24 Feb 2004 12:22:05 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Conferencing for UAs X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 24 Feb 2004 12:22:10 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF202@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sipping] Conferencing for UAs Thread-Index: AcP6zw1DPXE5gvvcRCi1/oe+ljGq3wAATy9Q From: "Chris Boulton" To: "Gonzalo Camarillo" , "sipping" Cc: "Alan Johnston" , "Orit Levin" , "Miguel Angel Garcia Martin" X-Scanned-By: MailControl A-01-00-04-90 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >Sent: 24 February 2004 12:06 >To: sipping >Cc: Alan Johnston; Orit Levin; Miguel Angel Garcia Martin >Subject: [Sipping] Conferencing for UAs > >Hello, > >some comments on the following draft: >http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conferencing- >03.txt > >The focus of a conference returns the conference URI in the contact >header field of the 200 OK for the INVITE. The UAC uses this URI to >SUBSCRIBE to the conf package (using a new dialog)... > >Why are we forcing the focus to use the same URI for receiving the >INVITEs from all the users and for receiving the SUBSCRIBEs? I believe >the solution would be cleaner if we defined a new header field (e.g., >Associated-Conf-State) that carried a globally routable URI. The 200 OK >for the initial INVITE (or the INVITE in a dial-out case) would carry >this header field. This would keep separate the URI used for joining the >conference and the URI used for subscribing to the state of the conference. [Chris Boulton] I agree that it would be better to convey this information separately for instances where the presence module is a separate entity to the conference focus. This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 07:28:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16557 for ; Tue, 24 Feb 2004 07:28:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbfT-0002hi-T4 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 07:28:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OCS79A010388 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 07:28:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbfT-0002hT-Ns for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 07:28:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16517 for ; Tue, 24 Feb 2004 07:28:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbfS-0007EG-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:28:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbeS-00075H-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:27:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvbdS-0006wj-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbdR-0002Ir-UC; Tue, 24 Feb 2004 07:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbcT-00028s-9h for sipping@optimus.ietf.org; Tue, 24 Feb 2004 07:25:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16314 for ; Tue, 24 Feb 2004 07:25:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbcS-0006p8-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:25:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbbZ-0006jf-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:24:06 -0500 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 1Avbat-0006fB-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:23:23 -0500 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id NAA90689 for ; Tue, 24 Feb 2004 13:26:14 +0100 (CET) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma090335; Tue, 24 Feb 04 13:25:03 +0100 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Tue, 24 Feb 2004 13:21:57 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Tue, 24 Feb 2004 13:21:52 +0100 From: "A vWijk" To: , Cc: , , , , , Subject: Betr.: [Sipping] ToIP Requirements Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Gonzalo, While there are device requirements in the text. Those requirements and = the explanation on the different analogue text telephone systems is = included to give the reader an understanding what kind of devices will = connect with ToIP. And the need for the text gateways. And what the = different behaviour can/may be compared to end to end IP devices. The most important part will be the ToIP framwork and the text gateways = and how such gateways will be used and work with the ToIP framework. There is a ToIP framework where a terminal uses streaming text as defined = in RFC2793 to connect with any other Interactive texting/real-time = streaming text device. This can be end-to-end IP, and a direct T140/RTP stream is established = with SIP. But in other cases, a text gateway must be used to allow = T.140/RTP to connect with a non IP text telephony device. It can be an analogue text telephone (TDD/TTY) that uses a text gateway to = be able to understand RFC2793 text. (PSTN-IP) It can be a mobile phone running GPRS that uses the text gateway to = understand RFC2793 text. (this exist right NOW using SIP! And those = gateways will be used in mobile networks this year!) Or a mobile text telephone using CTM via the text gateway to communicate = with RFC2793 text. Or even one analogue text telephone connecting to another analogue text = telephone in a different country, and the PSTN's use IP to connect the = call. The question is for example, how do we use that gateway from the IP side? = Is it invisible for the IP side? Or do we need special extensions in SIP = to that the IP terminal knows it is communicating with the end-device = through the text gateway? There may be a slightly different call setup flow when a text gateway is = included. Or additional SIP messages indicating gateway activity. When you connect = for example to an analogue text telephone with an RFC2793 capable IP = terminal the capabilities will be less then IP to IP terminal directly = (different transmission speeds, half/full duplex etc). Or what to do with emergency calls that are in RFC 2793 text only?=20 That are requirements that will be defined and worked out in this draft. Also, we want to make everybody in SIP and SIPPING aware about those text = gateways. So that complicated matters like how to send analogue text = telephone text through a PSTN and connect with a SIP telephone using = RFC2793 interactive texting. When using the text gateway, there is then no = need for RFC 2833 events at the PSTN for text telephones.=20 So, yes. I believe that this should be in the SIPPING WG. And it will fit = in the charter - support for hearing-/speech-impaired calling. greetz Arnoud Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 International text telephone: +31735588408 >>> Gonzalo Camarillo 24-02-04 10:21 >>> Hello, the draft below provides a set of requirements for real-time=20 conversations using SIP. http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-toip-01.txt=20 Nevertheless, I have found a lot of device requirements in the text, = but=20 I fail to understand which particular protocol requirements we need to=20 fulfill with new protocol extensions. While SIPPING is the right place to handle requirements that will lead=20 to new SIP protocol extensions, SIPPING may not be the right place to=20 deal with device requirements (e.g., text phones MUST have a display of=20 at least 100 characters). Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s)= . Any unauthorized review, use, disclosure or distribution is prohibited. = If you believe this message has been sent to you in error, please notify = the sender by replying to this transmission and delete the message without = disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruptio= n, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corruption= , interception, amendment, tampering or viruses or any consequences = thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping=20 This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 07:50:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17500 for ; Tue, 24 Feb 2004 07:50:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avc0g-00042q-SQ for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 07:50:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OCo288015545 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 07:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avc0g-00042e-MK for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 07:50:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17468 for ; Tue, 24 Feb 2004 07:50:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avc0f-0001Wb-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:50:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avbzh-0001Rl-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:49:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avbym-0001Np-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 07:48:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avbyj-0003nA-MH; Tue, 24 Feb 2004 07:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avbxp-0003lr-EY for sipping@optimus.ietf.org; Tue, 24 Feb 2004 07:47:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17383 for ; Tue, 24 Feb 2004 07:47:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avbxo-0001Ig-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:47:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avbwn-0001Ea-00 for sipping@ietf.org; Tue, 24 Feb 2004 07:46:02 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly10b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AvbwM-0001Af-00; Tue, 24 Feb 2004 07:45:34 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly10b.srv.mailcontrol.com (MailControl) with SMTP id i1OCj11M031046; Tue, 24 Feb 2004 12:45:01 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Tue, 24 Feb 2004 12:44:59 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 24 Feb 2004 12:45:01 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE0219B1AF@gbnewp0758m.eu.ubiquity.net> Thread-Topic: Advanced IM requirements Thread-Index: AcP5C/kBvwKHvMXJS6urOHqe9sfskgA3pGvQABD6gKAAJ+XiMAABBLRg From: "Chris Boulton" To: , , X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: Advanced IM requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Miguel - thanks for taking the time to read this - I have included a couple of comments in-line. >-----Original Message----- >From: Miguel.An.Garcia@nokia.com [mailto:Miguel.An.Garcia@nokia.com] >Sent: 24 February 2004 12:11 >To: Chris Boulton; simple@ietf.org; sipping@ietf.org >Subject: RE: Advanced IM requirements > >A comment on the usage of the Require header in the MESSAGE receipt draft. > >As far as I know, the Require header is used to indicate the peer that the >request should not be processed if the extension is not supported. > >You apply the Require header to the response... which is a bit weird, >because you tell me what should be the action of the UAC if it does not >support the functionality. > >You can argue that we have already used Require headers in SIP responses >(e.g.., 100rel). But there it had a clear meaning: there is an action that >has to be taken upon the reception of the response: to generate a PRACK. >But in your draft, I didn't see an equivalence. > >In my view, this mechanism should only be applicable to Support headers in >requests. If the message is no delivered, then a DSN can be generated, >because of the Support header tag in the request. [Chris Boulton] Seems reasonable to me. This is an early version and I will note this as a point for my discussions in Korea. My intention was to encourage a stateless mechanism that allowed for state-full processing if required when used with a GRUU. In that if a UAC issued a MESSAGE with a GRUU + grid parameter, it would need state for the grid association on the incoming receipt(Even though this is discouraged). So the intended action for the UAC was to remain state-full for that particular grid parameter - otherwise dispose of state (But I agree - not a SIP action). > >And that comes to my next question. Do you intend proxies to generate DSNs >to non delivered messages? I guess this is the idea, but I didn't find a >"Proxy behavior" section in the document. [Chris Boulton] In this initial draft, the mechanism only applies to successful MESSAGE requests (2xx class recpose). It covered scenarios where the message had arrived at a store-forward device OR delivered to the handset but had not been read etc. Again, I am interested in the lists thoughts on this so please let me know. I will also note this down for discussion. Chris. > >/Miguel > > > >> -----Original Message----- >> From: sipping-admin@ietf.org >> [mailto:sipping-admin@ietf.org]On Behalf Of >> ext Chris Boulton >> Sent: 23 February, 2004 19:01 >> To: Simple WG; sipping >> Subject: [Sipping] FW: [Simple] Advanced IM requirements >> >> >> >> >> As promised. >> >> https://www.ubiquity.net/draft-boulton-sipping-message-receipt-00.txt >> >> Chris. >> >> >> >-----Original Message----- >> >From: Chris Boulton >> >Sent: 23 February 2004 10:40 >> >To: 'Jonathan Rosenberg'; Simple WG >> >Cc: 'sipping@ietf.org' >> >Subject: RE: [Simple] Advanced IM requirements >> > >> >Hi Jonathan et al, >> > >> > I have an extremely early version (so be gentle) of a draft >> aimed at >> >supplying IM delivery reports. It hasn't been formally submitted yet >> but I >> >have attached a copy - so would be grateful if the list could take a >> look >> >and see if it's worth progressing. I will submit to the archives in >> the >> >next few days. I will also put this on the internet >> somewhere in case >> this >> >attachment doesn't survive its journey (Will send link later). >> > >> >Best Regards, >> > >> >Chris. >> > >> > >> >>-----Original Message----- >> >>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >> >>Sent: 22 February 2004 06:17 >> >>To: Simple WG >> >>Subject: [Simple] Advanced IM requirements >> >> >> >>Folks, >> >> >> >>As I noted earlier, I resubmitted the advanced IM >> requirements draft. >> It >> >>specifies a bunch of advanced IM functions we havent yet >> tackled here. >> >>They are: >> >> >> >>* delivery reports for IM >> >>* is-typing indicator (Henning had an I-D on this that has expired) >> >>* capabilities indications of maximum desired message sizes for IM >> >>* page mode groups (under discussion in the context of exploders in >> >>sipping) >> >>* invitations to non-real time sessions >> >> >> >> >> >>The last of these is particularly interesting. One use case is "call >> >>alerts" in PTT. There, I send you a request to have a PTT chat. The >> >>request is not answered in real time. Rather, its stored by the >> >>recipient as if it were an IM, and can be answered at any >> time later. >> >>"Answering it" merely involves setting up a PTT call back to the >> caller. >> >>Its also possible to cancel the call alert at any time. >> >> >> >>There are some interesting ways to accomplish this function. The one >> >>I've been thinking about is taking a SIP INVITE message, and sending >> it >> >>in the body of a MESSAGE request as a message/sip content. I'm sure >> >>there are other ways. >> >> >> >>Are these topics for which there is still group interest in working >> on? >> >>I think all of them remain quite important. >> >> >> >>Thanks, >> >>Jonathan R. >> >>-- >> >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> >>Chief Technology Officer Parsippany, NJ >> 07054-2711 >> >>dynamicsoft >> >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> >>http://www.jdrosen.net PHONE: (973) 952-5000 >> >>http://www.dynamicsoft.com >> >> >> >> >> >>_______________________________________________ >> >>Simple mailing list >> >>Simple@ietf.org >> >>https://www1.ietf.org/mailman/listinfo/simple >> >> >> This message has been scanned for viruses by MailControl - >www.mailcontrol.com > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 08:58:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20364 for ; Tue, 24 Feb 2004 08:58:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avd4X-0007R8-QW for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 08:58:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ODw5KX028583 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 08:58:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avd4W-0007Qw-Ue for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 08:58:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20328 for ; Tue, 24 Feb 2004 08:58:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avd4V-0007Vf-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 08:58:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avd3a-0007PP-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 08:57:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avd2j-0007JC-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 08:56:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avd2Y-0007Bb-9W; Tue, 24 Feb 2004 08:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDLr-0005ua-0W for sipping@optimus.ietf.org; Fri, 20 Feb 2004 11:18:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00425 for ; Fri, 20 Feb 2004 11:18:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuDLq-0005EE-00 for sipping@ietf.org; Fri, 20 Feb 2004 11:18:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuDKw-0005BA-00 for sipping@ietf.org; Fri, 20 Feb 2004 11:17:10 -0500 Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx with esmtp (Exim 4.12) id 1AuDKf-00057T-00 for sipping@ietf.org; Fri, 20 Feb 2004 11:16:54 -0500 Received: from csc.com (va-fch32.csc.com [20.6.39.233]) by amer-mta02.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1KGI0i8000859 for ; Fri, 20 Feb 2004 11:18:02 -0500 (EST) Subject: Re: [Sipping] Re: sos - dead or alive To: Michael Hammer Cc: Henning Schulzrinne , Mpierce1@aol.com, sipping@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Fri, 20 Feb 2004 11:20:31 -0500 X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 6.0.3|September 26, 2003) at 02/20/2004 11:16:41 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 From a different perspective- and this is a US centric comment but the principle is applicable worldwide. In the US, the Government "mandated" E-911 (911 with location info for mobile phones, among other things) by imposing requirements on the manufacturers of the switching equipment, and on the service providers. However, there was no mechanism to require the PSAPs to do anything with the information, as there was no direct jurisdiction. As a result, the vast majority of the PSAPs simply "throw it on the floor". They have no GIS, and no mechanism to DO anything with the location information. Furthermore , a large number of the PSAPs have no plans to do anything with the location information. Therefore, I would be VERY cautious about basing any solution on the expectation, that the PSAPs will make ANY additional investment that is not required by law. For instance, when I saw "$2k per proxy, one proxy per ECC", it threw up a red flag for me. Janet ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- Michael Hammer @cisco.com> cc: Mpierce1@aol.com, Janet P Gunn/FED/CSC@CSC, sipping@ietf.org Subject: Re: [Sipping] Re: sos - dead or alive 02/20/2004 10:41 AM Henning, The reality of deployment would be that every ECC would have it's own proxy, so that would be more like 1000 x $2k = $2 million. But, the corresponding distribution of load across those servers means it is even more of a non-problem at any given site. One question: A real successful test to a wrong ECC doesn't buy you much. I hope that mobility is addressed in the solution as well. Many of those 100 million phones are mobile, which might become SIP-based some time in the future. so I would add a 6) "works with mobile terminals" to your list below. Mike At 10:00 AM 2/20/2004 -0500, Henning Schulzrinne wrote: >I think there are five goals, somewhat contradictory: > >(1) make it as realistic as possible, to make sure you are really testing >the emergency calling system, not the testing system; after all, the fire >safety officer doesn't go around ringing a cowbell instead of the real >fire alarms. > >(2) do not impose any additional operator involvement; this is solved by >the OPTIONS mechanism proposed; > >(3) allow for reasonable scaling; > >(4) avoid interfering with real emergency calls > >(5) allow user on-demand testing. > >With the proxy-based testing I proposed, we get very close to all goals. >In the worst case, i.e., every device does this once a day, we get roughly >100 million calls a day in the US, or 1157/second. That's about 10 proxy >servers worth of equipment, i.e., about $20k. This hardly seems worth >spending inordinate engineering resources on avoiding, particularly since >the likely load is going to be lower by probably a factor of 1000 or more >(I'm assuming that most residential users will use a cable or DSL provider >for this, for example). > >With even a few hundred systems, you'll get almost perfect smoothing and >very little burstiness. > >I know protocol design is fun, but I'm very worried about adding >complexity to solve largely a non-problem. > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 09:05:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20711 for ; Tue, 24 Feb 2004 09:05:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvdBH-0007x5-HU for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 09:05:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OE53oV030560 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 09:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvdBH-0007wp-DX for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 09:05:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20639 for ; Tue, 24 Feb 2004 09:05:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvdBF-0000P9-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 09:05:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvdAE-0000Dk-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 09:03:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avd9J-000067-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 09:03:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avd9J-0007iY-H3; Tue, 24 Feb 2004 09:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avd8K-0007ct-UQ for sipping@optimus.ietf.org; Tue, 24 Feb 2004 09:02:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20511 for ; Tue, 24 Feb 2004 09:01:58 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avd8J-00000M-00 for sipping@ietf.org; Tue, 24 Feb 2004 09:01:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avd7N-0007kR-00 for sipping@ietf.org; Tue, 24 Feb 2004 09:01:02 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Avd6k-0007gp-00 for sipping@ietf.org; Tue, 24 Feb 2004 09:00:22 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1OE0CH20672; Tue, 24 Feb 2004 16:00:12 +0200 (EET) X-Scanned: Tue, 24 Feb 2004 16:00:09 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i1OE09fg002390; Tue, 24 Feb 2004 16:00:09 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00cklywP; Tue, 24 Feb 2004 16:00:07 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1OE07712101; Tue, 24 Feb 2004 16:00:07 +0200 (EET) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 24 Feb 2004 16:00:05 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 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: [Sipping] Conferencing for UAs Date: Tue, 24 Feb 2004 16:00:03 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] Conferencing for UAs Thread-Index: AcP6z1CNytIQSr55Q4mrKtEf7k3yrwADnRqA To: , Cc: , , X-OriginalArrivalTime: 24 Feb 2004 14:00:05.0909 (UTC) FILETIME=[8183D450:01C3FADE] Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: sipping-admin@ietf.org=20 > [mailto:sipping-admin@ietf.org]On Behalf Of > ext Gonzalo Camarillo > Sent: 24.February.2004 14:06 > To: sipping > Cc: Alan Johnston; Orit Levin; Garcia Miguel.An (Nokia-NRC/Helsinki) > Subject: [Sipping] Conferencing for UAs >=20 >=20 >=20 > Hello, >=20 > some comments on the following draft: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conf > erencing-03.txt >=20 > The focus of a conference returns the conference URI in the contact=20 > header field of the 200 OK for the INVITE. The UAC uses this URI to=20 > SUBSCRIBE to the conf package (using a new dialog)... >=20 > Why are we forcing the focus to use the same URI for receiving the=20 > INVITEs from all the users and for receiving the SUBSCRIBEs?=20 > I believe=20 > the solution would be cleaner if we defined a new header field (e.g.,=20 > Associated-Conf-State) that carried a globally routable URI.=20 > The 200 OK=20 > for the initial INVITE (or the INVITE in a dial-out case) would carry=20 > this header field. This would keep separate the URI used for=20 > joining the=20 > conference and the URI used for subscribing to the state of=20 > the conference. I don't see what the problem is here and why it is a problem? Why do = they need to be separate. Both the INVITEs and SUBSCRIBEs are destined = to the same resource. You have a resource (in this case a conference ID). You invite yourself = to that resource. You also subscribe to that resource, using the same = URI. Note that the Request-URI on the SUBSCRIBE request carries the = resource you are subscribing to. /Hisham >=20 > This is actually the approach that the draft below follows: > http://www.ietf.org/internet-drafts/draft-camarillo-sipping-tr > ansac-package-00.txt >=20 > We define the Associated-Transactions-State to be returned,=20 > for example,=20 > in the 200 OK of a MESSAGE sent to an exploder. Note that we had to=20 > create this new header because MESSAGE does not carry a Contact=20 > header... following the same approach in both, the=20 > conferencing work and=20 > the exploders work would be good, in my opinion. >=20 > Comments? >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 09:31:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22201 for ; Tue, 24 Feb 2004 09:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvdaU-00024X-7y for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 09:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OEV6r8007958 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 09:31:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvdaU-00024F-3A for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 09:31:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22148 for ; Tue, 24 Feb 2004 09:31:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvdaS-0003EK-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 09:31:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvdZW-00037h-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 09:30:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvdYY-000311-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 09:29:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvdYT-0001i8-40; Tue, 24 Feb 2004 09:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvdXY-0001ZQ-HW for sipping@optimus.ietf.org; Tue, 24 Feb 2004 09:28:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22060 for ; Tue, 24 Feb 2004 09:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvdXW-0002tR-00 for sipping@ietf.org; Tue, 24 Feb 2004 09:28:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvdWb-0002pe-00 for sipping@ietf.org; Tue, 24 Feb 2004 09:27:06 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AvdVk-0002lb-00 for sipping@ietf.org; Tue, 24 Feb 2004 09:26:12 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1OEQBAh009976 for ; Tue, 24 Feb 2004 15:26:11 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 15:26:11 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.26]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSLDCW07; Tue, 24 Feb 2004 15:26:11 +0100 Message-ID: <403B5F02.50404@ericsson.com> Date: Tue, 24 Feb 2004 16:26:10 +0200 X-Sybari-Trust: 5fd9dea2 c77f3eb6 6ea67f5e 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: sipping@ietf.org, alan.johnston@mci.com, oritl@microsoft.com, Miguel.An.Garcia@nokia.com Subject: Re: [Sipping] Conferencing for UAs References: <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2004 14:26:11.0175 (UTC) FILETIME=[267C7770:01C3FAE2] Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, > I don't see what the problem is here and why it is a problem? Why do > they need to be separate. Both the INVITEs and SUBSCRIBEs are > destined to the same resource. You send an INVITE to a conference server that will INVITE the rest of the participants in the conference. This INVITE is creating: 1) a dialog 2) an INVITE explosion 3) a conference I find it cleaner to have three separate URIs instead of a single URI where the server figures out what the UAC is trying to do by looking at the contents of the request (in this case, the event header). In addition, the application server handling the presence for the conference may not be co-located with the entity handling the SIP signalling for the conference. Furthermore, when you deal with requests that do not establish a dialog (e.g., MESSAGE), the server needs to convey the URI of the resource to the UAC using a different mechanism (Contact is not allowed). It would be good to use the same mechanism for requests that create a dialog and for requests that do not create a dialog. This avoids overloading the Contact header field. I believe that having something like this: Associated-Resource: sip:abc@a.com;purpose=conference-state Associated-Resource: sip:def@a.com;purpose=explosion-state makes it easier for the UAC to know what can be done; it is more explicit. Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 09:49:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23023 for ; Tue, 24 Feb 2004 09:49:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avdrv-000300-CP for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 09:49:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OEn70g011527 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 09:49:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avdrv-0002zq-6a for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 09:49:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22980 for ; Tue, 24 Feb 2004 09:49:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avdrt-0004s0-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 09:49:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avdqx-0004lr-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 09:48:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avdpz-0004fC-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 09:47:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avdpu-0002mg-Pz; Tue, 24 Feb 2004 09:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avdp4-0002kF-1S for sipping@optimus.ietf.org; Tue, 24 Feb 2004 09:46:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22892 for ; Tue, 24 Feb 2004 09:46:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avdp2-0004ZD-00 for sipping@ietf.org; Tue, 24 Feb 2004 09:46:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avdo1-0004Tw-00 for sipping@ietf.org; Tue, 24 Feb 2004 09:45:05 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1Avdn5-0004Kl-01 for sipping@ietf.org; Tue, 24 Feb 2004 09:44:08 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTL00IDYF54NP@firewall.mci.com> for sipping@ietf.org; Tue, 24 Feb 2004 14:34:34 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTL00E01F4RRP@pmismtp01.mcilink.com>; Tue, 24 Feb 2004 14:34:30 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.152.158]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTL00DOWF5CO2@pmismtp01.mcilink.com>; Tue, 24 Feb 2004 14:34:27 +0000 (GMT) Date: Tue, 24 Feb 2004 08:14:33 -0600 From: Alan Johnston Subject: Re: [Sipping] Conferencing for UAs In-reply-to: <403B3E35.9010304@ericsson.com> X-Sender: Alan.Johnston@pop.mcit.com To: Gonzalo Camarillo , sipping Cc: Orit Levin , Miguel Angel Garcia Martin Message-id: <5.2.1.1.0.20040224080705.02834708@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 02:06 PM 2/24/2004 +0200, Gonzalo Camarillo wrote: >Hello, > >some comments on the following draft: >http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conferencing-03.txt > >The focus of a conference returns the conference URI in the contact header >field of the 200 OK for the INVITE. The UAC uses this URI to SUBSCRIBE to >the conf package (using a new dialog)... > >Why are we forcing the focus to use the same URI for receiving the INVITEs >from all the users and for receiving the SUBSCRIBEs? I believe the >solution would be cleaner if we defined a new header field (e.g., >Associated-Conf-State) that carried a globally routable URI. The 200 OK >for the initial INVITE (or the INVITE in a dial-out case) would carry this >header field. This would keep separate the URI used for joining the >conference and the URI used for subscribing to the state of the conference. Gonzalo, This is a fundamental design decision made in SIP conferencing nearly two years ago, and I believe it is a good one. A requirement for conferencing is that a UA must be able to find out information about a conference (by subscribing to the conference package, for example) by only knowing the conference URI. Why is this very useful property a problem? >This is actually the approach that the draft below follows: >http://www.ietf.org/internet-drafts/draft-camarillo-sipping-transac-package-00.txt > >We define the Associated-Transactions-State to be returned, for example, >in the 200 OK of a MESSAGE sent to an exploder. Note that we had to create >this new header because MESSAGE does not carry a Contact header... >following the same approach in both, the conferencing work and the >exploders work would be good, in my opinion. With all due respect, the exploders work should follow the approaches described in the conferencing work. Note that the exploders work should not also contradict the XCON work in related areas, as well... Thanks, Alan Johnston MCI sip:alan@sipstation.com >Comments? > >Thanks, > >Gonzalo > > >This communication is confidential and intended solely for the >addressee(s). Any unauthorized review, use, disclosure or distribution is >prohibited. If you believe this message has been sent to you in error, >please notify the sender by replying to this transmission and delete the >message without disclosing it. Thank you. > >E-mail including attachments is susceptible to data corruption, >interruption, unauthorized amendment, tampering and viruses, and we only >send and receive e-mails on the basis that we are not liable for any such >corruption, interception, amendment, tampering or viruses or any >consequences thereof. > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 10:02:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23838 for ; Tue, 24 Feb 2004 10:02:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ave4V-0005qA-Kp for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 10:02:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OF272l022444 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 10:02:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ave4V-0005pr-Fq for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 10:02:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23809 for ; Tue, 24 Feb 2004 10:02:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ave4T-0006UZ-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 10:02:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ave3W-0006Pn-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 10:01:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ave2d-0006LT-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 10:00:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ave2e-00055B-EV for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 10:00:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ave2V-0004ls-BW; Tue, 24 Feb 2004 10:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ave1Z-0004kB-RA for sipping@optimus.ietf.org; Tue, 24 Feb 2004 09:59:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23662 for ; Tue, 24 Feb 2004 09:59:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ave1X-0006FI-00 for sipping@ietf.org; Tue, 24 Feb 2004 09:59:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ave0g-00069Z-00 for sipping@ietf.org; Tue, 24 Feb 2004 09:58:11 -0500 Received: from omzesmtp02.mci.com ([199.249.17.9]) by ietf-mx with esmtp (Exim 4.12) id 1Avdzp-0005yg-00 for sipping@ietf.org; Tue, 24 Feb 2004 09:57:18 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTL0067PFUROD@firewall.mci.com> for sipping@ietf.org; Tue, 24 Feb 2004 14:49:39 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTL00901FO79P@pmismtp02.mcilink.com>; Tue, 24 Feb 2004 14:49:39 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.152.158]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTL008ONFTUY3@pmismtp02.mcilink.com>; Tue, 24 Feb 2004 14:49:08 +0000 (GMT) Date: Tue, 24 Feb 2004 08:49:05 -0600 From: Alan Johnston Subject: Re: [Sipping] Conferencing for UAs In-reply-to: <403B5F02.50404@ericsson.com> X-Sender: Alan.Johnston@pop.mcit.com To: Gonzalo Camarillo , hisham.khartabil@nokia.com Cc: sipping@ietf.org, oritl@microsoft.com, Miguel.An.Garcia@nokia.com Message-id: <5.2.1.1.0.20040224084212.02819ef8@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 04:26 PM 2/24/2004 +0200, Gonzalo Camarillo wrote: >Hello, > >>I don't see what the problem is here and why it is a problem? Why do >>they need to be separate. Both the INVITEs and SUBSCRIBEs are >>destined to the same resource. > >You send an INVITE to a conference server that will INVITE the rest of the >participants in the conference. This INVITE is creating: > >1) a dialog >2) an INVITE explosion >3) a conference No - this is the problem. You are looking at your single narrow application. Conferencing is a very broad application, and we have developed a very general framework and set of primitives. It is a mistake to invent a whole new set to fit a single application, or change our framework to fit your application. Sending an INVITE creates a dialog. Period. Everything else that happens, happens because of properties (we call it policy) of the URI. Your application (conference policy of a URI) may cause a conference (called a focus) to be created, and an INVITE explosion (called a dial out participant list). >I find it cleaner to have three separate URIs instead of a single URI >where the server figures out what the UAC is trying to do by looking at >the contents of the request (in this case, the event header). > >In addition, the application server handling the presence for the >conference may not be co-located with the entity handling the SIP >signalling for the conference. >Furthermore, when you deal with requests that do not establish a dialog >(e.g., MESSAGE), the server needs to convey the URI of the resource to the >UAC using a different mechanism (Contact is not allowed). It would be good >to use the same mechanism for requests that create a dialog and for >requests that do not create a dialog. This avoids overloading the Contact >header field. > >I believe that having something like this: > >Associated-Resource: sip:abc@a.com;purpose=conference-state >Associated-Resource: sip:def@a.com;purpose=explosion-state No. There is policy related to the conference URI. Not an endless set of Associated-Something header fields that try to describe a set of application specific information. And we need general mechanisms to find out and modify the policy associated with that URI. This the work being done in XCON. Thanks, Alan Johnston MCI sip:alan@sipstation.com >makes it easier for the UAC to know what can be done; it is more explicit. > >Gonzalo > > >This communication is confidential and intended solely for the >addressee(s). Any unauthorized review, use, disclosure or distribution is >prohibited. If you believe this message has been sent to you in error, >please notify the sender by replying to this transmission and delete the >message without disclosing it. Thank you. > >E-mail including attachments is susceptible to data corruption, >interruption, unauthorized amendment, tampering and viruses, and we only >send and receive e-mails on the basis that we are not liable for any such >corruption, interception, amendment, tampering or viruses or any >consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 10:31:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26358 for ; Tue, 24 Feb 2004 10:31:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AveWY-00058M-AN for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 10:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OFV6kv019728 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 10:31:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AveWX-00057d-Fr for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 10:31:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26302 for ; Tue, 24 Feb 2004 10:31:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AveWU-0001Wp-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 10:31:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AveVY-0001QW-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 10:30:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AveUa-0001JJ-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 10:29:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AveUX-0004pq-Fg; Tue, 24 Feb 2004 10:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AveTe-0004oX-2C for sipping@optimus.ietf.org; Tue, 24 Feb 2004 10:28:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26094 for ; Tue, 24 Feb 2004 10:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AveTb-0001Cq-00 for sipping@ietf.org; Tue, 24 Feb 2004 10:28:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AveSd-00016n-00 for sipping@ietf.org; Tue, 24 Feb 2004 10:27:04 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AveRg-000112-00 for sipping@ietf.org; Tue, 24 Feb 2004 10:26:04 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1OFQ2YG016223 for ; Tue, 24 Feb 2004 16:26:02 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 16:26:02 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Feb 2004 16:26:14 +0100 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'eburger@snowshore.com'" , "'jdrosen@dynamicsoft.com'" , "'sipping@ietf.org'" Subject: [Fwd: RE: [Sipping] I-D ACTION:draft-ietf-sipping-kpml-02.txt] Date: Tue, 24 Feb 2004 16:25:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 24 Feb 2004 15:26:02.0633 (UTC) FILETIME=[83297790:01C3FAEA] Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Hi, I guess this is a clarification question on kpml, as well as on gruu (and functions where gruu is used) in general. If you have a node that doesn't register, but eg wants to use kpml (a gateway, for example), could it generate the gruu on its own, or is it "mandated" to use the register mechanism? If the register mechanism is not used, are there any issues which could come up? Regards, Christer Holmberg Ericsson Finland > -------- Original Message -------- > Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-kpml-02.txt > Date: Mon, 23 Feb 2004 17:34:22 -0500 > From: Eric Burger > To: Jonathan Rosenberg , > > Yep, yep, yep, we can (and will) use GRUU. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Thursday, February 05, 2004 2:46 AM > > To: sipping@ietf.org > > Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-kpml-02.txt > > > > > > Eric, > > > > The draft talks about sending the subscribe requests on the > > same dialog > > as the INVITE. For many reasons that have been discussed ad > > nauseam on > > the list, dialog sharing is a bad idea. GRUU provides a > solution that > > does not require dialog sharing. As I recall, there was > discussion on > > this point in the last ietf, and this seemed to be the > > preferred direction. > > > > Is there any reason we cant change this to use gruu's rather > > than dialog > > sharing? > > > > Also, you are missing the IANA registration for the kpml > > event package. > > > > Thanks, > > Jonathan R. > > > > Internet-Drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > This draft is a work item of the Session Initiation > > Proposal Investigation Working Group of the IETF. > > > > > > Title : Keypad Stimulus Protocol (KPML) > > > Author(s) : E. Burger > > > Filename : draft-ietf-sipping-kpml-02.txt > > > Pages : 42 > > > Date : 2004-2-4 > > > > > > The Key Press Stimulus Protocol uses the SIP SUBSCRIBE/NOTIFY > > > mechanism and Keypad Markup Language (KPML) to provide > > instructions > > > to SIP User Agents for the reporting of user key presses. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-02.txt > > > > > > To remove yourself from the IETF Announcement list, send a > > message to > > > ietf-announce-request with the word unsubscribe in the body > > of the message. > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > > "anonymous" and a password of your e-mail address. After > logging in, > > > type "cd internet-drafts" and then > > > "get draft-ietf-sipping-kpml-02.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE /internet-drafts/draft-ietf-sipping-kpml-02.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before the "FILE" > > > command. To decode the response(s), you will need "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which have been split > > > up into multiple messages), so check your local documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ > 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 11:30:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28335 for ; Tue, 24 Feb 2004 11:30:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvfRw-0003Vm-Hq for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 11:30:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OGUOC3013492 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 11:30:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvfRw-0003VX-DO for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 11:30:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28280 for ; Tue, 24 Feb 2004 11:30:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvfRv-00075j-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 11:30:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvfR0-0006vY-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 11:29:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvfPs-0006lO-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 11:28:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvfPf-0002oA-Qd; Tue, 24 Feb 2004 11:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvfPC-0002jm-5c for sipping@optimus.ietf.org; Tue, 24 Feb 2004 11:27:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27962 for ; Tue, 24 Feb 2004 11:27:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvfPB-0006Zu-00 for sipping@ietf.org; Tue, 24 Feb 2004 11:27:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvfG1-0005fk-00 for sipping@ietf.org; Tue, 24 Feb 2004 11:18:06 -0500 Received: from smtp.terra.es ([213.4.129.129] helo=tsmtp6.mail.isp) by ietf-mx with esmtp (Exim 4.12) id 1AvfF9-0005ZY-00 for sipping@ietf.org; Tue, 24 Feb 2004 11:17:12 -0500 Received: from localhost.localdomain ([212.166.192.132]) by tsmtp6.mail.isp (terra.es) with ESMTP id HTLJWF01.HMX for ; Tue, 24 Feb 2004 17:17:03 +0100 From: Curro To: sipping@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 24 Feb 2004 17:12:40 +0100 Message-Id: <1077639161.2909.60.camel@Frodo> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sipping] SIP and IPv4/IPv6 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello all I would like to make you some questions about SIP and IPv6.Please, excuse me if this is not the right list. I'm interested in SIP and testing behaviour with IPv6/IPv4 interworking. I know IETF recommend dual-stack. But it describes a SIP/SDP ALG in draft-ietf-v6ops-3gpp-analysis-08.txt like a transition mechanism. I want to have an IPv6-only SIP network and a 'SIP Edge Proxy' and 'Media translator' to communicate IPv6 and IPv4, as described in mentioned draft. I would like to know whether someone is working on this. Is there some implementation of this SIP/SDP ALG? Is SIP/SDP ALG worth or is better waiting to have all legacy IPv4 hosts with dual-stack? Or maybe in my scenario, it could be better other type of IPv6/IPv4 interworking? By the way, should the SIP/SDP ALG modify SDP body or not? Also, draft-elmalki-sipping-3gpp-translator-00.txt proposes a SIP extension called ALT. But, if I have understand, it implies modify end-points, doesn't? Please, help me to clarify mi ideas. Thank you very much for your time and responses. Curro _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 11:30:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28352 for ; Tue, 24 Feb 2004 11:30:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvfRy-0003W4-3O for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 11:30:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OGUQK5013510 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 11:30:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvfRx-0003Vp-WB for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 11:30:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28284 for ; Tue, 24 Feb 2004 11:30:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvfRw-00075w-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 11:30:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvfR1-0006vj-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 11:29:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvfPs-0006lU-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 11:28:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvfPl-0002qJ-3B; Tue, 24 Feb 2004 11:28:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvfPR-0002mE-PK for sipping@optimus.ietf.org; Tue, 24 Feb 2004 11:27:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28010 for ; Tue, 24 Feb 2004 11:27:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvfPQ-0006bv-01 for sipping@ietf.org; Tue, 24 Feb 2004 11:27:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvfAE-0005Cc-00 for sipping@ietf.org; Tue, 24 Feb 2004 11:12:07 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Avf9e-00053M-00 for sipping@ietf.org; Tue, 24 Feb 2004 11:11:31 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 24 Feb 2004 08:11:07 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1OGAvcw008070; Tue, 24 Feb 2004 08:10:57 -0800 (PST) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGG87395; Tue, 24 Feb 2004 11:10:56 -0500 (EST) Message-ID: <403B7790.4020507@cisco.com> Date: Tue, 24 Feb 2004 11:10:56 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sipping , Cullen Jennings , bstucker@nortelnetworks.com Subject: Re: [Sipping] UA indentification and HIP References: <403B0C82.20407@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Does this really work for us? It sounds like it only works for *hosts*. That doesn't sound like it covers the case of a UA (e.g. softphone) that may move from host to host while retaining its identity. Nor does it seem to cover the case of multiple UAs that share a host. Paul Gonzalo Camarillo wrote: > Folks, > > the following two drafts describe how to indentify a particular UA using > globally unique identifiers: > > http://www.ietf.org/internet-drafts/draft-stucker-sip-guid-00.txt > http://www.ietf.org/internet-drafts/draft-jennings-sipping-instance-id-00.txt > > > Cullen pointed out that this work may be able to take advantage of the > work carried out in the HIP (Host Identity Protocol) WG, which > supplemental web page is: > > http://hip.piuha.net/ > > Here you have a *very* brief introduction to HIP. I will also be > providing a brief introduction to the drafts above to the HIP community. > Hopefully, we will have a useful exchange of ideas between both WGs. > > HIP consists of a layer between the network and the tranport layers > (e.g., between IP and TCP). It uses HIs (Host Identifiers) to identify > hosts. The idea is that, when a host changes its IP address, it keeps > its HI. This facilitates mobility, for instance. > > HIs (Host Identifiers) are public keys, which may have different lengths > and formats. To resolve this, HIP defines the HITs (Host Identity Tags), > which are hashes of the HI. That is, a HIT is a hash of a public key. > They are 128 bit long, and can be used instead of IPv6 addresses in > socket calls. HIP also defines LSIs (Local Scope Indetifiers), that are > 32 bit long and can be used instead of IPv4 addresses in socket calls. > > Regards, > > Gonzalo > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any > such corruption, interception, amendment, tampering or viruses or any > consequences thereof. > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 11:44:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28797 for ; Tue, 24 Feb 2004 11:44:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avff9-0004mV-2i for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 11:44:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OGi3KF018373 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 11:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avff8-0004mG-VQ for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 11:44:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28779 for ; Tue, 24 Feb 2004 11:44:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avff7-0000YC-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 11:44:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avfe9-0000U1-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 11:43:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvfdE-0000Po-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 11:42:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvfdB-0004W2-IT; Tue, 24 Feb 2004 11:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvfcK-0004Tw-1H for sipping@optimus.ietf.org; Tue, 24 Feb 2004 11:41:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28726 for ; Tue, 24 Feb 2004 11:41:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvfcI-0000L1-00 for sipping@ietf.org; Tue, 24 Feb 2004 11:41:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvfbN-0000EJ-00 for sipping@ietf.org; Tue, 24 Feb 2004 11:40:10 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AvfaS-00005G-00 for sipping@ietf.org; Tue, 24 Feb 2004 11:39:12 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1OGcPR17143; Tue, 24 Feb 2004 08:38:25 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Feb 2004 10:38:25 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304D02901@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Paul Kyzivat , Gonzalo Camarillo Cc: sipping , Cullen Jennings Subject: RE: [Sipping] UA indentification and HIP Date: Tue, 24 Feb 2004 10:38:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FAF4.9C0B69C6" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 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. ------_=_NextPart_001_01C3FAF4.9C0B69C6 Content-Type: text/plain; charset="iso-8859-1" I'm inclined to say that it may work for us in some cases (where HIP-like behavior is desired), but I agree with you Paul that it does not seem to cover the case of multiple UAs that share a host at the very least. It also seems a bit heavy for environments that don't have easy access to the layer 2/3 information regarding HIP. Regards, Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, February 24, 2004 10:11 AM > To: Gonzalo Camarillo > Cc: sipping; Cullen Jennings; Stucker, Brian [NGC:B617:EXCH] > Subject: Re: [Sipping] UA indentification and HIP > > > Does this really work for us? > > It sounds like it only works for *hosts*. That doesn't sound like it > covers the case of a UA (e.g. softphone) that may move from > host to host > while retaining its identity. Nor does it seem to cover the case of > multiple UAs that share a host. > > Paul > > Gonzalo Camarillo wrote: > > Folks, > > > > the following two drafts describe how to indentify a > particular UA using > > globally unique identifiers: > > > > http://www.ietf.org/internet-drafts/draft-stucker-sip-guid-00.txt > > > http://www.ietf.org/internet-drafts/draft-jennings-sipping-ins > tance-id-00.txt > > > > > > Cullen pointed out that this work may be able to take > advantage of the > > work carried out in the HIP (Host Identity Protocol) WG, which > > supplemental web page is: > > > > http://hip.piuha.net/ > > > > Here you have a *very* brief introduction to HIP. I will also be > > providing a brief introduction to the drafts above to the > HIP community. > > Hopefully, we will have a useful exchange of ideas between both WGs. > > > > HIP consists of a layer between the network and the tranport layers > > (e.g., between IP and TCP). It uses HIs (Host Identifiers) > to identify > > hosts. The idea is that, when a host changes its IP > address, it keeps > > its HI. This facilitates mobility, for instance. > > > > HIs (Host Identifiers) are public keys, which may have > different lengths > > and formats. To resolve this, HIP defines the HITs (Host > Identity Tags), > > which are hashes of the HI. That is, a HIT is a hash of a > public key. > > They are 128 bit long, and can be used instead of IPv6 addresses in > > socket calls. HIP also defines LSIs (Local Scope > Indetifiers), that are > > 32 bit long and can be used instead of IPv4 addresses in > socket calls. > > > > Regards, > > > > Gonzalo > > > > > > This communication is confidential and intended solely for the > > addressee(s). Any unauthorized review, use, disclosure or > distribution > > is prohibited. If you believe this message has been sent to you in > > error, please notify the sender by replying to this > transmission and > > delete the message without disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data corruption, > > interruption, unauthorized amendment, tampering and > viruses, and we only > > send and receive e-mails on the basis that we are not > liable for any > > such corruption, interception, amendment, tampering or > viruses or any > > consequences thereof. > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > ------_=_NextPart_001_01C3FAF4.9C0B69C6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] UA indentification and HIP

I'm inclined to say that it may work for us in some = cases (where HIP-like
behavior is desired), but I agree with you Paul that = it does not seem to
cover the case of multiple UAs that share a host at = the very least. It also
seems a bit heavy for environments that don't have = easy access to the layer 2/3
information regarding HIP.

Regards,

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=
> Sent: Tuesday, February 24, 2004 10:11 = AM
> To: Gonzalo Camarillo
> Cc: sipping; Cullen Jennings; Stucker, Brian = [NGC:B617:EXCH]
> Subject: Re: [Sipping] UA indentification and = HIP
>
>
> Does this really work for us?
>
> It sounds like it only works for *hosts*. That = doesn't sound like it
> covers the case of a UA (e.g. softphone) that = may move from
> host to host
> while retaining its identity. Nor does it seem = to cover the case of
> multiple UAs that share a host.
>
>       Paul
>
> Gonzalo Camarillo wrote:
> > Folks,
> >
> > the following two drafts describe how to = indentify a
> particular UA using
> > globally unique identifiers:
> >
> > http://www.ietf.org/internet-drafts/draft-stucker-sip-= guid-00.txt
> >
> http://www.ietf.org/internet-drafts/draft-jennings-sip= ping-ins
> tance-id-00.txt
> >
> >
> > Cullen pointed out that this work may be = able to take
> advantage of the
> > work carried out in the HIP (Host Identity = Protocol) WG, which
> > supplemental web page is:
> >
> > http://hip.piuha.net/
> >
> > Here you have a *very* brief introduction = to HIP. I will also be
> > providing a brief introduction to the = drafts above to the
> HIP community.
> > Hopefully, we will have a useful exchange = of ideas between both WGs.
> >
> > HIP consists of a layer between the = network and the tranport layers
> > (e.g., between IP and TCP). It uses HIs = (Host Identifiers)
> to identify
> > hosts. The idea is that, when a host = changes its IP
> address, it keeps
> > its HI. This facilitates mobility, for = instance.
> >
> > HIs (Host Identifiers) are public keys, = which may have
> different lengths
> > and formats. To resolve this, HIP defines = the HITs (Host
> Identity Tags),
> > which are hashes of the HI. That is, a HIT = is a hash of a
> public key.
> > They are 128 bit long, and can be used = instead of IPv6 addresses in
> > socket calls. HIP also defines LSIs (Local = Scope
> Indetifiers), that are
> > 32 bit long and can be used instead of = IPv4 addresses in
> socket calls.
> >
> > Regards,
> >
> > Gonzalo
> >
> >
> > This communication is confidential and = intended solely for the
> > addressee(s). Any unauthorized review, = use, disclosure or
> distribution
> > is prohibited. If you believe this message = has been sent to you in
> > error, please notify the sender by = replying to this
> transmission and
> > delete the message without disclosing it. = Thank you.
> >
> > E-mail including attachments is = susceptible to data corruption,
> > interruption, unauthorized amendment, = tampering and
> viruses, and we only
> > send and receive e-mails on the basis that = we are not
> liable for any
> > such corruption, interception, amendment, = tampering or
> viruses or any
> > consequences thereof.
> >
> >
> > = _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the = application of SIP
> > Use sip-implementors@cs.columbia.edu for = questions on current sip
> > Use sip@ietf.org for new developments of = core SIP
> >
>
>

------_=_NextPart_001_01C3FAF4.9C0B69C6-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 11:48:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29011 for ; Tue, 24 Feb 2004 11:48:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avfj5-0005FQ-0H for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 11:48:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OGm6NE020166 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 11:48:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avfj4-0005FB-TH for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 11:48:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28980 for ; Tue, 24 Feb 2004 11:48:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avfj3-0000xG-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 11:48:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avfi4-0000qs-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 11:47:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avfh5-0000lD-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 11:46:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avfh4-0004qJ-P8; Tue, 24 Feb 2004 11:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvfgB-0004o8-Sv for sipping@optimus.ietf.org; Tue, 24 Feb 2004 11:45:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28846 for ; Tue, 24 Feb 2004 11:45:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvfgA-0000fs-00 for sipping@ietf.org; Tue, 24 Feb 2004 11:45:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvffK-0000ZZ-00 for sipping@ietf.org; Tue, 24 Feb 2004 11:44:14 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AvfeR-0000VG-00 for sipping@ietf.org; Tue, 24 Feb 2004 11:43:19 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1OGhIqY026163 for ; Tue, 24 Feb 2004 17:43:18 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 17:43:18 +0100 Received: from ericsson.com (rvi2-92-155.sw.ericsson.se [153.88.92.155]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSLBYX6A; Tue, 24 Feb 2004 17:43:27 +0100 Message-ID: <403B7F21.7010703@ericsson.com> Date: Tue, 24 Feb 2004 18:43:13 +0200 X-Sybari-Trust: 23cd7776 c77f3eb6 6ea67f5e 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: sipping , Cullen Jennings , bstucker@nortelnetworks.com Subject: Re: [Sipping] UA indentification and HIP References: <403B0C82.20407@ericsson.com> <403B7790.4020507@cisco.com> In-Reply-To: <403B7790.4020507@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2004 16:43:18.0921 (UTC) FILETIME=[4E9ADF90:01C3FAF5] Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul, > That doesn't sound like it > covers the case of a UA (e.g. softphone) that may move from host to host > while retaining its identity. The drafts mention things like MAC addresses.... my impression is that the indentity would be bundled to the hardware the phone is running on, but it would be good to clarify the purpose of the identity in this situation. > Nor does it seem to cover the case of > multiple UAs that share a host. I believe HIP covers this case, because different UAs would use different public keys, and thus, different HITs. Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 12:38:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00725 for ; Tue, 24 Feb 2004 12:38:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgVW-00018l-0m for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 12:38:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OHc98R004377 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 12:38:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgVV-00018W-SG for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 12:38:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00674 for ; Tue, 24 Feb 2004 12:38:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvgVU-00069S-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 12:38:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvgUV-000636-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 12:37:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvgTY-0005y5-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 12:36:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgTS-0000hC-0h; Tue, 24 Feb 2004 12:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgSb-0000Zo-AD for sipping@optimus.ietf.org; Tue, 24 Feb 2004 12:35:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00538 for ; Tue, 24 Feb 2004 12:35:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvgSZ-0005tA-00 for sipping@ietf.org; Tue, 24 Feb 2004 12:35:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvgRh-0005oa-00 for sipping@ietf.org; Tue, 24 Feb 2004 12:34:13 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AvgQt-0005e4-00 for sipping@ietf.org; Tue, 24 Feb 2004 12:33:23 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Feb 2004 09:42:59 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1OHWn1m028055; Tue, 24 Feb 2004 09:32:50 -0800 (PST) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGG95554; Tue, 24 Feb 2004 12:32:44 -0500 (EST) Message-ID: <403B8ABC.8020602@cisco.com> Date: Tue, 24 Feb 2004 12:32:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harry Behrens CC: sipping@ietf.org, knuettel@fokus.fraunhofer.de Subject: Re: AW: [Sipping] Roaming Architecture for SIP References: <007201c3fac4$826a1470$2c00a8c0@RocknRoll> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA00539 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Harry Behrens wrote: > Dear Paul, >=20 > inline >=20 >=20 >>-----Urspr=FCngliche Nachricht----- >>Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 >>Gesendet: Montag, 23. Februar 2004 19:47 >>An: Harry Behrens >>Cc: sipping@ietf.org; knuettel@fokus.fraunhofer.de >>Betreff: Re: [Sipping] Roaming Architecture for SIP >> >> >>I have specific comment inline below, and then a question. >> >> Paul >> >> >>> - A user registers with the VN (atlanta.com in the call flow=20 >>> given). The user submits his NAI in new header field 'P-NAI'.=20 >>> The user submits a bogus URI in both the From and the=20 >> >>To header.=20 >> >>> (F1 in section 8.2.1) >>> - The VN recognizes the registration as a P-NAI registration and=20 >>> sends back a "401 Unauthorized" response, with both=20 >> >>the 'From'=20 >> >>> and the 'To' URI set to the temporary URI that will=20 >> >>be assigned=20 >> >>> to the user upon successful authentication and authorization=20 >>>(F2). >> >>This isn't legal. The From and To (with exception of To-tag)=20 >>of response=20 >>must be same as in the request. >=20 > This is true. The reason we have this crutch in there is to allow the V= N > server to pass a user ID to the client, which the client can use to > register to the VN. This would otherwise have to happen out-of-band, > which we were trying to avoid. > We are thinking about alternative approaches to this requirement and ar= e > grateful for any input. No good idea comes immediately to mind. I'm still not convinced of why I=20 would want this at all. >>The question is: why would the UAC want to register with the VN?=20 >>Assuming it is able to send sip messages, (which apparently=20 >>it can), why=20 >>wouldn't it simply send a REGISTER to its HN? >> >>I presume there must be some service that you intend the VN won't=20 >>perform, that will prevent the UAC from doing this. But it isn't=20 >>apparent what service that is. >=20 > The scenario is of a user based e.g. in Berlin/Germany on a business > trip in Beijing/China. > The user will want to both be reachable under his home AOR (for that he > registers with his HN) I'm ok with that. > as well as make use of the VN for local calls, > especially local PSTN breakout (this is why he wants to have a valid > registration with the VN). Why? His billing relationship is with his HN. Why not let the HN figure=20 out the best way to route this calls? If it is via the VN's gateways,=20 then it can route the calls to the VN. > Furthermore, in a number of cases, one encounters RTP-proxying, where > around-the-world loops are to be avoided. Certainly that is likely to be a bad thing. But does it require a=20 signaling identity with the VN to achieve that? > Another issue which we foresee is that in the near future hotels, > airports or other semi-closed (walled garden) Internet access points, > will force users through their own VoIP (SIP) proxy infrastructure, > similar to what a lot of sites aleady do in the case of HTTP. Sure. But as long as those things are *proxies*, the UA should still be=20 able to register with his HN. Dealing with that depends a bit on how users will be forced. The way=20 hotels do it today depends on details of http that won't necessarily=20 work for sip. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 12:43:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00857 for ; Tue, 24 Feb 2004 12:43:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgaT-0001bH-V4 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 12:43:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OHhHVF006145 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 12:43:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgaT-0001b2-O8 for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 12:43:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00852 for ; Tue, 24 Feb 2004 12:43:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvgaR-0006Zz-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 12:43:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvgZT-0006U3-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 12:42:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvgZF-0006Oi-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 12:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgZG-0001P4-17; Tue, 24 Feb 2004 12:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgYO-0001O7-6i for sipping@optimus.ietf.org; Tue, 24 Feb 2004 12:41:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00804 for ; Tue, 24 Feb 2004 12:41:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvgYM-0006Mz-00 for sipping@ietf.org; Tue, 24 Feb 2004 12:41:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvgXO-0006JF-00 for sipping@ietf.org; Tue, 24 Feb 2004 12:40:07 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AvgWv-0006F1-00 for sipping@ietf.org; Tue, 24 Feb 2004 12:39:37 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 24 Feb 2004 09:39:02 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1OHcocw013085; Tue, 24 Feb 2004 09:38:51 -0800 (PST) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGG96159; Tue, 24 Feb 2004 12:38:49 -0500 (EST) Message-ID: <403B8C29.8070403@cisco.com> Date: Tue, 24 Feb 2004 12:38:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sipping , Alan Johnston , Orit Levin , Miguel Angel Garcia Martin Subject: Re: [Sipping] Conferencing for UAs References: <403B3E35.9010304@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > Hello, > > some comments on the following draft: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conferencing-03.txt > > > The focus of a conference returns the conference URI in the contact > header field of the 200 OK for the INVITE. The UAC uses this URI to > SUBSCRIBE to the conf package (using a new dialog)... > > Why are we forcing the focus to use the same URI for receiving the > INVITEs from all the users and for receiving the SUBSCRIBEs? Why? Because that URI identifies the entity that I want information about. It is the same reason that you might send a subscription for the dialog package, or the presence package to the same address you send an INVITE or MESSAGE to. One of the advantages of sip is that it simplifies addressing. > I believe > the solution would be cleaner if we defined a new header field (e.g., > Associated-Conf-State) that carried a globally routable URI. The 200 OK > for the initial INVITE (or the INVITE in a dial-out case) would carry > this header field. This would keep separate the URI used for joining the > conference and the URI used for subscribing to the state of the conference. Why complicate life for users by introducing more addresses to deal with? If the conference server wants to decompose the service, it can always return an AOR as its contact address, with a proxy routing subscribe requests one way, invite requests a different way, etc. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 12:52:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01316 for ; Tue, 24 Feb 2004 12:52:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avgj1-00029X-7a for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 12:52:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OHq7Ki008271 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 12:52:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avgj0-00029K-Vp for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 12:52:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01287 for ; Tue, 24 Feb 2004 12:52:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avgiz-0007V3-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 12:52:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avgi0-0007Pt-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 12:51:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avgh2-0007Jv-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 12:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avgh1-0001uE-JT; Tue, 24 Feb 2004 12:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvggS-0001tM-1U for sipping@optimus.ietf.org; Tue, 24 Feb 2004 12:49:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01187 for ; Tue, 24 Feb 2004 12:49:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvggQ-0007GP-00 for sipping@ietf.org; Tue, 24 Feb 2004 12:49:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvgfW-00079e-00 for sipping@ietf.org; Tue, 24 Feb 2004 12:48:31 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Avgey-00071d-00 for sipping@ietf.org; Tue, 24 Feb 2004 12:47:56 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1OHlN1m016003; Tue, 24 Feb 2004 09:47:23 -0800 (PST) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGG96980; Tue, 24 Feb 2004 12:47:22 -0500 (EST) Message-ID: <403B8E2A.1010402@cisco.com> Date: Tue, 24 Feb 2004 12:47:22 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: hisham.khartabil@nokia.com, sipping@ietf.org, alan.johnston@mci.com, oritl@microsoft.com, Miguel.An.Garcia@nokia.com Subject: Re: [Sipping] Conferencing for UAs References: <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <403B5F02.50404@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > Hello, > >> I don't see what the problem is here and why it is a problem? Why do >> they need to be separate. Both the INVITEs and SUBSCRIBEs are >> destined to the same resource. I agree. > You send an INVITE to a conference server that will INVITE the rest of > the participants in the conference. This INVITE is creating: > > 1) a dialog > 2) an INVITE explosion > 3) a conference You just jumped to the most complex of cases that combines a bunch of things. Not every invite to a focus generates an invite explosion. As I see it, I send an INVITE to the address of some entity that I want to talk to. Sometimes it turns out to be a conference focus, sometimes not. Either way I am communicating with that entity. If I want to know more about that entity than I get by virtue of my invitation, I send some other request to the address of that entity, defined by the remote contact address of my dialog. I could send OPTIONS for some info. Or I can send SUBSCRIBE if I want to request event updates. Taken to extreme, what you suggest would lead to a different address for OPTIONS, for MESSAGE, for PUBLISH, for REGISTER, etc. And maybe different addresses for each kind of subscription. I don't want to go there. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 13:09:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01977 for ; Tue, 24 Feb 2004 13:09:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgzS-0003eG-AX for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 13:09:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OI96pf014023 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 13:09:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgzS-0003e6-7B for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 13:09:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01929 for ; Tue, 24 Feb 2004 13:09:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvgzQ-0001Kx-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 13:09:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvgyR-0001EI-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 13:08:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvgxT-00017T-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 13:07:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgxR-00037t-DW; Tue, 24 Feb 2004 13:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgwZ-00035a-SM for sipping@optimus.ietf.org; Tue, 24 Feb 2004 13:06:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01808 for ; Tue, 24 Feb 2004 13:06:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvgwY-00012C-00 for sipping@ietf.org; Tue, 24 Feb 2004 13:06:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avgvb-0000wY-00 for sipping@ietf.org; Tue, 24 Feb 2004 13:05:08 -0500 Received: from [209.116.120.7] (helo=tnint11.telogy.design.ti.com) by ietf-mx with esmtp (Exim 4.12) id 1Avguc-0000nJ-00 for sipping@ietf.org; Tue, 24 Feb 2004 13:04:06 -0500 Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Feb 2004 13:03:34 -0500 Message-ID: <37A3C2F21006D611995100B0D0F9B73C04C3E45C@tnint11.telogy.design.ti.com> From: "Scoggins, Sophia" To: sipping Date: Tue, 24 Feb 2004 13:03:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FB00.80F22330" Subject: [Sipping] look for SIP proxy server with TLS or IPSec Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE autolearn=no version=2.60 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. ------_=_NextPart_001_01C3FB00.80F22330 Content-Type: text/plain My group islooking for SIP proxy servers with either TLS, or IPSec, or any other standard based security protocol implementation to perform interop testing. If any one knows any SIP proxy server with the security feature, please let me know. Thanks in advance. Regards, Sophia2@ti.com ------_=_NextPart_001_01C3FB00.80F22330 Content-Type: text/html

My group islooking for SIP proxy servers with either TLS, or IPSec, or any other standard based security protocol implementation to perform interop testing. If any one knows any SIP proxy server with the security feature, please let me know. Thanks in advance.

 

 

Regards,

Sophia2@ti.com

------_=_NextPart_001_01C3FB00.80F22330-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 13:29:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02961 for ; Tue, 24 Feb 2004 13:29:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhIp-0005d3-Cj for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 13:29:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OIT795021631 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 13:29:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhIp-0005co-8i for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 13:29:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02937 for ; Tue, 24 Feb 2004 13:29:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvhIm-0003CU-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 13:29:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvhHo-00037H-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 13:28:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvhGp-00031b-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 13:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhGo-0005QA-W4; Tue, 24 Feb 2004 13:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhG1-0005O0-19 for sipping@optimus.ietf.org; Tue, 24 Feb 2004 13:26:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02878 for ; Tue, 24 Feb 2004 13:26:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvhFy-0002z5-00 for sipping@ietf.org; Tue, 24 Feb 2004 13:26:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvhF6-0002vE-00 for sipping@ietf.org; Tue, 24 Feb 2004 13:25:17 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AvhEo-0002qS-00 for sipping@ietf.org; Tue, 24 Feb 2004 13:24:58 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 24 Feb 2004 10:34:35 +0000 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 i1OION4U025056; Tue, 24 Feb 2004 10:24:24 -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 KAA21195; Tue, 24 Feb 2004 10:24:21 -0800 (PST) Message-Id: <4.3.2.7.2.20040224122055.02462ee8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Feb 2004 12:24:24 -0600 To: Gonzalo Camarillo , sipping From: "James M. Polk" Subject: Re: [Sipping] ToIP Requirements Cc: a.vwijk@viataal.nl, gv@trace.wisc.edu, henry.sinnreich@mci.com, rrroy@att.com, paulej@packetizer.com, gunnar.hellstrom@omnitor.se, barry.dingle@bigfoot.com.au In-Reply-To: <403B17A5.1040700@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 At 11:21 AM 2/24/2004 +0200, Gonzalo Camarillo wrote: >While SIPPING is the right place to handle requirements that will lead to >new SIP protocol extensions, SIPPING may not be the right place to deal >with device requirements (e.g., text phones MUST have a display of at >least 100 characters). In the US, Orgs like the TIA do this device requirement type of work (specifically the TR41.4 group within TIA) >Thanks, > >Gonzalo cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 14:07:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04497 for ; Tue, 24 Feb 2004 14:07:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avhtr-00088J-Kx for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 14:07:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OJ7NFF031249 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 14:07:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avhtr-00087t-4W for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 14:07:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04492 for ; Tue, 24 Feb 2004 14:07:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avhto-0006dp-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 14:07:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avhsx-0006Yq-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 14:06:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avhsa-0006Sa-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 14:06:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhsZ-0007yK-3d; Tue, 24 Feb 2004 14:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avhrk-0007ue-Sj for sipping@optimus.ietf.org; Tue, 24 Feb 2004 14:05:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04301 for ; Tue, 24 Feb 2004 14:05:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avhri-0006P4-00 for sipping@ietf.org; Tue, 24 Feb 2004 14:05:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avhqj-0006Iq-00 for sipping@ietf.org; Tue, 24 Feb 2004 14:04:10 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1Avhpv-0006Ao-00 for sipping@ietf.org; Tue, 24 Feb 2004 14:03:19 -0500 Received: from softarmor.com (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i1OJ23sa022422; Tue, 24 Feb 2004 13:02:03 -0600 Message-ID: <403B9FAB.7030909@softarmor.com> Date: Tue, 24 Feb 2004 13:02:03 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org CC: Rohan Mahy , Gonzalo Camarillo Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] SIPPING Agenda, IETF 59 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hyperlinked version at: http://www.softarmor.com/sipping/meets/ietf59/agenda.html Please get any slides in to Gonzalo well in advance Note that there are GRUU-related entries on both SIPPING and SIP agendae. The SIPPING session is for requirements, and the SIP session for mechanism. MONDAY, March 1, 2004, 0900-1130, Sapphire 4 0900 Angenda Bash Chairs 0905 Status of Work Chairs 0920 Event Package for Configuration Profiles Dan Petrie draft-ietf-sipping-config-framework-02.txt 0935 Session Policies Volker Hilt draft-hilt-sipping-session-indep-policy-00.txt draft-hilt-sipping-session-spec-policy-00.txt Additional Reading draft-ietf-sipping-session-policy-req-01.txt 0945 The dialog package Rohan Mahy draft-ietf-sipping-dialog-package-04 [txt] [html] 0955 End-To-Middle Security Kumiko Ono draft-ietf-sipping-e2m-sec-reqs-01.txt draft-ono-sipping-end2middle-security-01.txt draft-ono-sipping-smime-keyreuse-00.txt 1010 Real-Time Text Conversation Using SIP Arnoud van Wijk draft-manyfolks-sipping-toip-01.txt 1025 QSIG SIP Call Transfer Jean-Francois Rey draft-rey-sipping-qsig2sip-transfer-00.txt 1035 S/MIME Certificates in SIP Cullen Jennings draft-jennings-sipping-certs-02.txt [html] 1045 KPML Eric Burger draft-ietf-sipping-kpml-02.txt 1055 Basic Network Media Services with SIP Eric Burger draft-burger-sipping-netann-08.txt 1105 Instance ID, GRID, GRUU, Resource ID Requirements Brian Stucker, Cullen Jennings draft-stucker-sip-guid-00.txt draft-jennings-sipping-instance-id-00.txt [html] draft-ietf-xmpp-core-22.txt section 2.3 WEDNESDAY, March 3, 2004, 1300-1500, Crystal 3 1300 Agenda Bash Chairs Design Teams 1305 Application Interaction Jonathan Rosenberg draft-ietf-sipping-app-interaction-framework-01.txt 1315 SIP Conferencing Alan Johnston draft-ietf-sipping-cc-conferencing-03.txt draft-ietf-sipping-conference-package-03.txt draft-ietf-sipping-conferencing-requirements-00.txt draft-ietf-sipping-conferencing-framework-01.txt 1325 Transcoding Gonzalo Camarillo draft-camarillo-sipping-transc-b2bua-01.txt [PDF] 1335 SIP Emergency Henning Schulzrinne draft-ietf-sipping-sos-00.txt draft-schulzrinne-sipping-emergency-arch-00.txt 1345 Location Conveyance Requirements James Polk draft-ietf-sipping-location-requirements-00.txt 1355 REFER Extensions Orit Levin, Rohan Mahy, and Gonzalo Camarillo draft-olson-sipping-refer-extensions-01.txt draft-mahy-sip-remote-cc-01.txt draft-camarillo-sipping-multiple-refer-00.txt 1425 Exploders Gonzalo Camarillo draft-camarillo-sipping-exploders-02.txt draft-camarillo-sipping-uri-list-01.txt draft-camarillo-sipping-adhoc-management-00.txt draft-camarillo-sipping-transac-package-00.txt draft-hiller-uri-list-index-00.txt draft-levin-simple-adhoc-list-01.txt 1445 RTCP Summary Report Event Package Alan Johnston draft-johnston-sipping-rtcp-summary-02.txt Additional requests will be accomodated if time allows _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 14:13:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04760 for ; Tue, 24 Feb 2004 14:13:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhzW-0000Lc-5n for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 14:13:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OJDErO001330 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 14:13:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhzV-0000LN-VP for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 14:13:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04757 for ; Tue, 24 Feb 2004 14:13:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvhzT-0007EN-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 14:13:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avhyi-0007AF-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 14:12:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvhyJ-00075U-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 14:11:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhyL-0000Cc-1R; Tue, 24 Feb 2004 14:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avhxb-0000BW-Hz for sipping@optimus.ietf.org; Tue, 24 Feb 2004 14:11:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04690 for ; Tue, 24 Feb 2004 14:11:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvhxY-00072O-00 for sipping@ietf.org; Tue, 24 Feb 2004 14:11:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avhwc-0006w7-00 for sipping@ietf.org; Tue, 24 Feb 2004 14:10:14 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1Avhvl-0006l0-00 for sipping@ietf.org; Tue, 24 Feb 2004 14:09:22 -0500 Received: from softarmor.com (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i1OJ8ssa022485; Tue, 24 Feb 2004 13:08:55 -0600 Message-ID: <403BA146.5030707@softarmor.com> Date: Tue, 24 Feb 2004 13:08:54 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Langstaff CC: sipping@ietf.org Subject: Re: [Sipping] Roaming Architecture for SIP vs Mobile IP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Steve Langstaff wrote: > Hi All. > > Sorry if this is a much asked and much answered question, but haven't > the basic problems being solved in a "Roaming Architecture for SIP", > i.e. allowing a SIP host to roam to foreign networks, already been > solved using Mobile IP? What else does "Roaming Architecture for SIP" > give me? > Multiple concurrent appearance with capability and preference matched request routing. -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 14:40:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05541 for ; Tue, 24 Feb 2004 14:40:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AviPf-000264-4q for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 14:40:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OJeFRj008054 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 14:40:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AviPf-00025p-0L for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 14:40:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05529 for ; Tue, 24 Feb 2004 14:40:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AviPb-0001Uw-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 14:40:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AviOg-0001Qz-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 14:39:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AviOU-0001Mp-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 14:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AviOT-0001xR-IJ; Tue, 24 Feb 2004 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AviNk-0001p5-7e for sipping@optimus.ietf.org; Tue, 24 Feb 2004 14:38:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05469 for ; Tue, 24 Feb 2004 14:38:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AviNh-0001M3-00 for sipping@ietf.org; Tue, 24 Feb 2004 14:38:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AviMl-0001Hq-00 for sipping@ietf.org; Tue, 24 Feb 2004 14:37:16 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AviMM-0001DP-00 for sipping@ietf.org; Tue, 24 Feb 2004 14:36:50 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Feb 2004 11:36:19 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1OJa5vV018782; Tue, 24 Feb 2004 11:36:06 -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 LAA27216; Tue, 24 Feb 2004 11:36:04 -0800 (PST) Message-Id: <4.3.2.7.2.20040224132732.025454d0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Feb 2004 13:36:07 -0600 To: Dean Willis , sipping@ietf.org From: "James M. Polk" Subject: Re: [Sipping] SIPPING Agenda, IETF 59 Cc: Rohan Mahy , Gonzalo Camarillo In-Reply-To: <403B9FAB.7030909@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 01:02 PM 2/24/2004 -0600, Dean Willis wrote: >Hyperlinked version at: >http://www.softarmor.com/sipping/meets/ietf59/agenda.html > >WEDNESDAY, March 3, 2004, 1300-1500, Crystal 3 > >1335 SIP Emergency > Henning Schulzrinne > draft-ietf-sipping-sos-00.txt > draft-schulzrinne-sipping-emergency-arch-00.txt >1345 Location Conveyance Requirements > James Polk > draft-ietf-sipping-location-requirements-00.txt I believe these presentations should be reversed in order because the main points of discussion in the Location Requirements ID are for Emergency location dealing with call routing by proxies, adding LI (location information) by the proxy (whether or not the UA inserted it already) and the security of the LI in transit. Discussing these points after the Emer-Arch doc doesn't seem to make much sense due to potential rehash while the appropriate presenter is not at the podium (in either direction). comments? cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 16:05:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11082 for ; Tue, 24 Feb 2004 16:05:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avjjz-0001pP-PB for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 16:05:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OL5JND007021 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 16:05:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avjjz-0001pA-KJ for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 16:05:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11079 for ; Tue, 24 Feb 2004 16:05:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avjjx-0002NZ-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 16:05:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avjj3-0002JB-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 16:04:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avjip-0002EX-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 16:04:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avjij-0001ho-Mp; Tue, 24 Feb 2004 16:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avjhv-0001gK-Ve for sipping@optimus.ietf.org; Tue, 24 Feb 2004 16:03:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11000 for ; Tue, 24 Feb 2004 16:03:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avjhu-0002CW-00 for sipping@ietf.org; Tue, 24 Feb 2004 16:03:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avjgx-00026T-00 for sipping@ietf.org; Tue, 24 Feb 2004 16:02:11 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1Avjg2-0001wG-00 for sipping@ietf.org; Tue, 24 Feb 2004 16:01:15 -0500 Received: from softarmor.com (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i1OL05sa023339; Tue, 24 Feb 2004 15:00:05 -0600 Message-ID: <403BBB55.2060108@softarmor.com> Date: Tue, 24 Feb 2004 15:00:05 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" CC: sipping@ietf.org, Rohan Mahy , Gonzalo Camarillo , hgxs@cs.columbia.edu Subject: Re: [Sipping] SIPPING Agenda, IETF 59 References: <4.3.2.7.2.20040224132732.025454d0@localhost> In-Reply-To: <4.3.2.7.2.20040224132732.025454d0@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James M. Polk wrote: > At 01:02 PM 2/24/2004 -0600, Dean Willis wrote: > >> Hyperlinked version at: >> http://www.softarmor.com/sipping/meets/ietf59/agenda.html >> >> WEDNESDAY, March 3, 2004, 1300-1500, Crystal 3 >> >> 1335 SIP Emergency >> Henning Schulzrinne >> draft-ietf-sipping-sos-00.txt >> draft-schulzrinne-sipping-emergency-arch-00.txt >> 1345 Location Conveyance Requirements >> James Polk >> draft-ietf-sipping-location-requirements-00.txt > > > > I believe these presentations should be reversed in order because the > main points of discussion in the Location Requirements ID are for > Emergency location dealing with call routing by proxies, adding LI > (location information) by the proxy (whether or not the UA inserted it > already) and the security of the LI in transit. Discussing these points > after the Emer-Arch doc doesn't seem to make much sense due to potential > rehash while the appropriate presenter is not at the podium (in either > direction). > > comments? Works for me. Henning? -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 16:08:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11165 for ; Tue, 24 Feb 2004 16:08:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avjmy-0002JB-GT for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 16:08:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OL8Off008865 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 16:08:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avjmx-0002FT-CL for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 16:08:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11162 for ; Tue, 24 Feb 2004 16:08:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avjmv-0002en-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 16:08:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avjm0-0002ZQ-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 16:07:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avjld-0002U7-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 16:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avjld-0001vO-Kq; Tue, 24 Feb 2004 16:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avjkq-0001tm-Iy for sipping@optimus.ietf.org; Tue, 24 Feb 2004 16:06:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11102 for ; Tue, 24 Feb 2004 16:06:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avjko-0002Rh-00 for sipping@ietf.org; Tue, 24 Feb 2004 16:06:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avjjr-0002Mk-00 for sipping@ietf.org; Tue, 24 Feb 2004 16:05:11 -0500 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx with esmtp (Exim 4.12) id 1Avjiu-0002EK-00 for sipping@ietf.org; Tue, 24 Feb 2004 16:04:12 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTL009IVX63FC@firewall.mci.com> for sipping@ietf.org; Tue, 24 Feb 2004 21:03:39 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTL00J01X62NH@pmismtp01.mcilink.com>; Tue, 24 Feb 2004 21:03:38 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.153.19]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTL00JCMX60AV@pmismtp01.mcilink.com>; Tue, 24 Feb 2004 21:03:38 +0000 (GMT) Date: Tue, 24 Feb 2004 15:03:36 -0600 From: Alan Johnston Subject: Re: [Sipping] Re:draft-ietf-sipping-cc-conferencing-03.txt In-reply-to: <403A5B84.3040103@cisco.com> X-Sender: Alan.Johnston@pop.mcit.com To: Paul Kyzivat , sipping@ietf.org Message-id: <5.2.1.1.0.20040224145945.027c1958@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <200402172139.QAA07727@ietf.org> Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 02:59 PM 2/23/2004 -0500, Paul Kyzivat wrote: >In section 4.1 a change was made around the descriptin of handling a >subscription. The new wording seems wrong: > > The SUBSCRIBE should be sent outside the INVITE-initiated dialog. > > Participants leaving the conference send a BYE to the focus. If they > have a current subscription to the conference package, they also must > send a SUBSCRIBE with an Expires:0 header field to terminate both > dialogs. > >There is nothing for "The SUBSCRIBE" to refer back to. I wonder if this >sentence wasn't intended to be in section 3.4, where it would make more sense. Hi Paul, Thanks for the comment. The SUBSCRIBE mentioned is message F5 in Figure 1, but I agree that the wording is bad. You are right - the statement should be in 3.4. Thanks, Alan Johnston MCI sip:alan@sipstation.com > Paul > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 16:14:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11452 for ; Tue, 24 Feb 2004 16:14:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avjsf-0002rB-Sq for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 16:14:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OLEHoQ010975 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 16:14:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avjsf-0002qu-PF for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 16:14:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11449 for ; Tue, 24 Feb 2004 16:14:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avjsd-0003Fz-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 16:14:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avjrm-0003Bg-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 16:13:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvjrU-000375-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 16:13:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvjrS-0002dR-BA; Tue, 24 Feb 2004 16:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avjqq-0002cX-C5 for sipping@optimus.ietf.org; Tue, 24 Feb 2004 16:12:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11386 for ; Tue, 24 Feb 2004 16:12:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avjqo-00035u-00 for sipping@ietf.org; Tue, 24 Feb 2004 16:12:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avjpv-00030K-00 for sipping@ietf.org; Tue, 24 Feb 2004 16:11:27 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AvjpC-0002ub-00 for sipping@ietf.org; Tue, 24 Feb 2004 16:10:42 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1OLAUmR015029; Tue, 24 Feb 2004 16:10:34 -0500 (EST) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i1OLAUH27550; Tue, 24 Feb 2004 16:10:30 -0500 Message-ID: <403BBDC6.1000004@cs.columbia.edu> Date: Tue, 24 Feb 2004 16:10:30 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: "James M. Polk" , sipping@ietf.org, Rohan Mahy , Gonzalo Camarillo , hgxs@cs.columbia.edu Subject: Re: [Sipping] SIPPING Agenda, IETF 59 References: <4.3.2.7.2.20040224132732.025454d0@localhost> <403BBB55.2060108@softarmor.com> In-Reply-To: <403BBB55.2060108@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Reversal is fine with me. Dean Willis wrote: > James M. Polk wrote: > >> At 01:02 PM 2/24/2004 -0600, Dean Willis wrote: >> >>> Hyperlinked version at: >>> http://www.softarmor.com/sipping/meets/ietf59/agenda.html >>> >>> WEDNESDAY, March 3, 2004, 1300-1500, Crystal 3 >>> >>> 1335 SIP Emergency >>> Henning Schulzrinne >>> draft-ietf-sipping-sos-00.txt >>> draft-schulzrinne-sipping-emergency-arch-00.txt >>> 1345 Location Conveyance Requirements >>> James Polk >>> draft-ietf-sipping-location-requirements-00.txt >> >> >> >> >> I believe these presentations should be reversed in order because the >> main points of discussion in the Location Requirements ID are for >> Emergency location dealing with call routing by proxies, adding LI >> (location information) by the proxy (whether or not the UA inserted it >> already) and the security of the LI in transit. Discussing these >> points after the Emer-Arch doc doesn't seem to make much sense due to >> potential rehash while the appropriate presenter is not at the podium >> (in either direction). >> >> comments? > > > Works for me. Henning? > > -- > Dean > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Feb 24 23:41:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26448 for ; Tue, 24 Feb 2004 23:41:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvqqY-0000YL-3B for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 23:40:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P4eYRW002119 for sipping-archive@odin.ietf.org; Tue, 24 Feb 2004 23:40:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvqqX-0000Y6-T3 for sipping-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 23:40:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26420 for ; Tue, 24 Feb 2004 23:40:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvqqV-0000dv-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 23:40:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvqpY-0000ZG-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 23:39:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvqpB-0000Um-00 for sipping-web-archive@ietf.org; Tue, 24 Feb 2004 23:39:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avqp4-0000HN-8g; Tue, 24 Feb 2004 23:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avqoa-0000Gl-1Q for sipping@optimus.ietf.org; Tue, 24 Feb 2004 23:38:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26353 for ; Tue, 24 Feb 2004 23:38:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvqoX-0000UP-00 for sipping@ietf.org; Tue, 24 Feb 2004 23:38:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avqnf-0000QE-00 for sipping@ietf.org; Tue, 24 Feb 2004 23:37:36 -0500 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1AvqnM-0000LV-00 for sipping@ietf.org; Tue, 24 Feb 2004 23:37:16 -0500 Received: from pingtel.com (h00d01e004cd0.ne.client2.attbi.com[66.30.203.15]) by comcast.net (sccrmhc12) with SMTP id <2004022504364501200f3458e> (Authid: dgpetrie); Wed, 25 Feb 2004 04:36:45 +0000 Message-ID: <403C265D.38884E9A@pingtel.com> Date: Tue, 24 Feb 2004 23:36:45 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Volker Hilt CC: Henning Schulzrinne , Gonzalo Camarillo , sipping , Jonathan Rosemberg Subject: Re: [Sipping] Config framework References: <4039FEAD.5070708@ericsson.com> <403A01BD.7080905@cs.columbia.edu> <403A250F.9B29CE10@pingtel.com> <403A335F.8090403@bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Volker Hilt wrote: > Policies and configuration information seem to share a number of > commonalities. Thus, I think it would make sense to use the same > framework for both. The framework should probably be able to transfer > any kind of information from a network entity to a user agent. > > More comments inline. > > Daniel G. Petrie wrote: > > Henning Schulzrinne wrote: > >>My general concern is that the current config framework is far too > >>device-centric, presumably based on the origin and interests of the > > > > This is certainly not the intension. The draft specifies a way to separately > > subscribe for device or user profile data. I would be happy to clarify this > > where you think the draft is vague or implies this restriction. > > > Is it safe to assume that policy information is always part of the > device or user configuration or can it be an independent piece of > information a UA wants to subscribe to? Thus, would it make sense to > define a profile-name "session-policies"? This could be useful if a > device is configured by other means and simply wants to keep track of > the policies in a network. I can think of applications where policy information is useful by itself (e.g. in a profile server UI which facilitates profile data input) as well as applications were the profile data is needed in conjuntion with the policy data. I would suggest using something like XML name spaces so that everyting may be contained in the same or separate XML documents. > > > >> > >>The three sources are: > >>(1) The local network that I happen to be in, represented by the > >>outbound proxy or other information conveyed by DHCP, identified by my AOR; > >> > >>(2) My home provider/network, where I am identified by my AOR; > >> > >>(3) My device, identified by some permanent device identifier, typically > >>a MAC-address like thing, but some of the other identifiers discussed > >>here recently may also be possible. > > > > These 3 important concepts are intended to be supported in > > draft-ietf-sipping-config-framework-02. It is however difficult in > > practice to keep these three things separate. In many environments > > it is easier to keep two of the three separate. > > > > For example: > > In an enterprise with physical devices that do not move much, it becomes > > easier to combine the properties of 1 related to location with the properties > > of 3. > > > > When a user does not know their AOR or does not want to have to provide > > it to the UA (to provide a plug and play experience), the user's AOR can be > > associated with 3 (the device). 2 is may then be subscribe implicitly or explicitly. > > > > In the automated discover phase for a new UA, the distinction between > > 1 and 2 become blurred as the device can only discover or derive > > AORs based upon the local domain (without user input). > > > A difference between configuration data and other information (such as > policies) seems to be that subscriptions to configuration data must work > on an "out-of-the-box" device that has not been configured yet. Once the > configuration is done, its probably easier to subscribe to the different > sources of information. > > Is there information that applies to a device besides the device > configuration? If not, would it make sense to differentiate into the > device configuration (requiring a discovery process) and subscriptions It is an interesting thought that discover may only be needed for device profiles. > > to the local network using my AOR as well as subscriptions to my home > network (also using my AOR)? > I am not sure I follow how things get routed differently to the local or home network. Are there two different AORs? > > Thanks, > > Volker > > > I think that this illustrates a very good point that the separation between > > user and device profile data cannot be made concrete. Data such as > > out bound proxy, or policy may be dictated by any or all of the 3 > > realms defined above. Only the application and local administrative > > policies can determine the realm to which data should be associated. > > In addition it may be desirable to override some of the user or device > > profile data based upon other local discovery data (e.g. DHCP options > > for out bound proxy, STUN for NAT traversal). > > > > At best we can define a precedence by which the device data > > can be overridden by user data (or the other way around) > > along with the ability for administrators to dictate policy (perhaps indicated > > in the profile data) over what can be overridden. > > > > > >>So far, only a subset of (3) seems to have been discussed. > >> > >>I had raised this issue earlier, but have gotten no response. It seems > >>fundamental to the whole architecture discussion. The same problem that > >>Gonzalo raises (one or more events) also applies to the question as to > >>how this relates to watcher lists and other IM configuration information. > >> > >>Gonzalo Camarillo wrote: > >> > >> > >>>Hello, > >>> > >>>The following draft defines a framework for session policies in SIP > >>>http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-indep-policy-00.txt > >>> > >>> > >>>It defines an event package and a data format to carry session policy > >>>information. Now, the following draft defines a framework for sending > >>>configuration information and user profiles to SIP user agents. > >>> > >>>http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-02.txt > >>> > >>> > >>>We need to decide whether session policies should use the package > >>>defined by the configuration framework or, on the other hand, continue > >>>defining its own package. The XML based data format would remain the > >>>same on both cases. > >>> > >>>I would like to know what type of information folks intend to store as > >>>user profile. Would it make sense to consider session policies as a > >>>subset of the user profile, or it would be better to define a new > >>>profile-name value: "session-policy" (in addition to the already defined > >>>"user" and "device"). > >>> > >>>I tend to think that it would be better to re-use the same package for > >>>session policies as for configuration, defining the new "session-policy" > >>>value for the profile-name Event header field parameter, but I would > >>>like to hear other opinions. > >>> > >>>Comments? > >>> > >>>A further question of the config draft. Is the intention to establish > >>>two subscriptions, one for device configuration and another for user > >>>profiles, or the idea is to use a single subscription and multiplex > >>>somehow both data types into it. > >>> > >>>Thanks, > >>> > >>>Gonzalo > >>> > >>> > >>> > >>>This communication is confidential and intended solely for the > >>>addressee(s). Any unauthorized review, use, disclosure or distribution > >>>is prohibited. If you believe this message has been sent to you in > >>>error, please notify the sender by replying to this transmission and > >>>delete the message without disclosing it. Thank you. > >>> > >>>E-mail including attachments is susceptible to data corruption, > >>>interruption, unauthorized amendment, tampering and viruses, and we only > >>>send and receive e-mails on the basis that we are not liable for any > >>>such corruption, interception, amendment, tampering or viruses or any > >>>consequences thereof. > >>> > >>> > >>>_______________________________________________ > >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >>>This list is for NEW development of the application of SIP > >>>Use sip-implementors@cs.columbia.edu for questions on current sip > >>>Use sip@ietf.org for new developments of core SIP > > > > > > -- > Volker Hilt Bell Labs / Lucent Technologies > phone: +1 732 332 6432 101 Crawfords Corner Rd > email: volkerh@bell-labs.com Holmdel, NJ 07733 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 00:13:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27801 for ; Wed, 25 Feb 2004 00:13:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvrLV-00030J-1A for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 00:12:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P5CW9t011541 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 00:12:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvrLU-000304-Qr for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 00:12:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27792 for ; Wed, 25 Feb 2004 00:12:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvrLS-0003al-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 00:12:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvrKY-0003WL-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 00:11:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvrK3-0003Rj-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 00:11:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvrK2-0002ef-4p; Wed, 25 Feb 2004 00:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvrJV-0002b9-OI for sipping@optimus.ietf.org; Wed, 25 Feb 2004 00:10:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27748 for ; Wed, 25 Feb 2004 00:10:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvrJT-0003QG-00 for sipping@ietf.org; Wed, 25 Feb 2004 00:10:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvrIf-0003Lu-00 for sipping@ietf.org; Wed, 25 Feb 2004 00:09:37 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 1AvrHl-0003CG-00 for sipping@ietf.org; Wed, 25 Feb 2004 00:08:41 -0500 Received: from pingtel.com (h00d01e004cd0.ne.client2.attbi.com[66.30.203.15]) by comcast.net (rwcrmhc12) with SMTP id <20040225050810014001qccje> (Authid: dgpetrie); Wed, 25 Feb 2004 05:08:11 +0000 Message-ID: <403C2DB9.F3A1107D@pingtel.com> Date: Wed, 25 Feb 2004 00:08:09 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Gonzalo Camarillo , sipping Subject: Re: [Sipping] Config framework References: <4039FEAD.5070708@ericsson.com> <403A01BD.7080905@cs.columbia.edu> <403A250F.9B29CE10@pingtel.com> <403A889F.4010601@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I split this into two responses. This is good input. I think making two distict discover approaches makes sense. I will try to incorporate this into the next draft. Henning Schulzrinne wrote: > > This is certainly not the intension. The draft specifies a way to separately > > subscribe for device or user profile data. I would be happy to clarify this > > where you think the draft is vague or implies this restriction. > > > > > Section 3.2 describes parameters that are device specific as even in the > > ideal world, purely user specific data may need to consider the UA > > implementation that it is to be applied to. Section 3.2 also specifies a > > means to indicate the desire for user or device data. > > > > Section 3.13 specifies how to form the SUBSCRIBE URI based upon > > the interest for either a device or user profile. > > 3.13 and 4.1 don't really spell out that user (as opposed to device) > data may need to go elsewhere. It only has a single set of steps that > aborts as soon as (say) DHCP-based discovery succeeds. > > I think the two modes, user and device, are somewhat dissimilar. For > device, I may need to combine local information (e.g., information about > outbound proxies and local dialplans) with home information (local > dialplan, device-specific UI configuration, etc.). > > For user configuration, I probably need to assume that the device has an > AOR, either initially or discovered via device configuration, which is > realistic for laptops and other personal devices. > > 4.1 does not seem to spell out what to do if either the device or the > user knows the AOR, but wants to get the remainder of the device and > user configuration automatically. > > Thus, I'd suggest separating the two discovery models and possibly > logically separating user configuration as being derived (among other > sources of AORs) from the device configuration, as in: > > DHCP -> device configuration query -> AOR -> user-based query _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 00:41:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28598 for ; Wed, 25 Feb 2004 00:41:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvrnW-0004me-4m for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 00:41:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P5fUVG018380 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 00:41:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvrnW-0004mC-0V for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 00:41:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28592 for ; Wed, 25 Feb 2004 00:41:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvrnT-00064Q-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 00:41:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvrmX-00060S-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 00:40:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avrm9-0005wZ-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 00:40:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avrm8-0004ZL-0R; Wed, 25 Feb 2004 00:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avrla-0004Xr-K0 for sipping@optimus.ietf.org; Wed, 25 Feb 2004 00:39:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28507 for ; Wed, 25 Feb 2004 00:39:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvrlY-0005vd-00 for sipping@ietf.org; Wed, 25 Feb 2004 00:39:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avrkc-0005rZ-00 for sipping@ietf.org; Wed, 25 Feb 2004 00:38:30 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 1Avrjw-0005ih-00 for sipping@ietf.org; Wed, 25 Feb 2004 00:37:48 -0500 Received: from pingtel.com (h00d01e004cd0.ne.client2.attbi.com[66.30.203.15]) by comcast.net (rwcrmhc12) with SMTP id <20040225053718014001ptq1e> (Authid: dgpetrie); Wed, 25 Feb 2004 05:37:19 +0000 Message-ID: <403C348D.21C43F72@pingtel.com> Date: Wed, 25 Feb 2004 00:37:17 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Gonzalo Camarillo , sipping Subject: Re: [Sipping] Config framework References: <4039FEAD.5070708@ericsson.com> <403A01BD.7080905@cs.columbia.edu> <403A250F.9B29CE10@pingtel.com> <403A889F.4010601@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: snipped > > These 3 important concepts are intended to be supported in > > draft-ietf-sipping-config-framework-02. It is however difficult in > > practice to keep these three things separate. In many environments > > it is easier to keep two of the three separate. > > > > For example: > > In an enterprise with physical devices that do not move much, it becomes > > easier to combine the properties of 1 related to location with the properties > > of 3. > > I'd rather be more general; if the user configuration spans multiple > devices, it's a lot cleaner if I only have to update one server rather > than each device-based server. (Device-based servers may well be more > local than user-based servers.) I am not sure I follow this. Perhaps if I elaborate, you can help me realize my confusion. The three types of profile data are: local network, user and device data. In the above example I was suggesting that in many environments the UA is not mobile or at least not frequently moved. Hense the UA can be associated with a specific location. In these environments it is convenient to combine the local network data and the device specific data. I was not suggesting that the user data should be denormalized. A user may have many devices. The devices can all use the same user profile data. I am also questioning whether people think we really need three distinct types of profiles (local network, user and device). Is there a real life environment where we need all three or can it be accomlished with two by combining parts of the third with the other two. If people think we need all three then we need to have three different discovery models and ways to form three different AORs (for each profile type). This is not difficult, I just want to be sure the extra moving parts are necessary. > > > > > > When a user does not know their AOR or does not want to have to provide > > it to the UA (to provide a plug and play experience), the user's AOR can be > > associated with 3 (the device). 2 is may then be subscribe implicitly or explicitly. > > In my two-stage model, this is supported. > > > I think that this illustrates a very good point that the separation between > > user and device profile data cannot be made concrete. Data such as > > out bound proxy, or policy may be dictated by any or all of the 3 > > realms defined above. Only the application and local administrative > > policies can determine the realm to which data should be associated. > > In addition it may be desirable to override some of the user or device > > profile data based upon other local discovery data (e.g. DHCP options > > for out bound proxy, STUN for NAT traversal). > > There may well be information that could be considered both, but in my > book, user-based configuration is independent of where I plug in my > device and does not depend on the device itself. Thus, an outbound proxy > and related transport parameters are clearly device-related, while speed > dial functionality, media preferences, home dial plans and buddy lists > are probably not. > > Some parameters may be hierarchical, in that local network configuration > overrides my general configuration. If my visited network doesn't allow > video, that takes precedence over my user configuration that prefers > video calls. > > > > > At best we can define a precedence by which the device data > > can be overridden by user data (or the other way around) > > along with the ability for administrators to dictate policy (perhaps indicated > > in the profile data) over what can be overridden. > > I agree. I think we'll have both directions of override. For example, a > CIA agent user configuration may mandate use of TLS and AES encryption > and accept that a call will fail in some local environments that don't > allow this. > > Having a sample set of configuration parameters that we can work through > might test our assumptions. draft-stredicke-sipping-ep-config-00.txt > seems to be the last one on this topic, or is there something else? > There is nothing newer than this expired draft. I was hoping to shake the dust off and restructure this document once the framework was last called. I think the document identifies some good profile data requirements, but I think they should be sliced up a little differently. > > It unfortunately conflates local parameters (e.g., outbound proxy, > 3.1.4.3) with user-based parameters (registration period, 3.1.4.1). > > Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 01:10:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29675 for ; Wed, 25 Feb 2004 01:10:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsEn-0006b3-3a for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 01:09:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P69fO0025351 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 01:09:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsEm-0006ao-Vx for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 01:09:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29669 for ; Wed, 25 Feb 2004 01:09:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvsEk-0000vj-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 01:09:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvsDk-0000qG-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 01:08:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvsDE-0000lP-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 01:08:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsDC-0006Hd-Ug; Wed, 25 Feb 2004 01:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsCq-0006C1-PV for sipping@optimus.ietf.org; Wed, 25 Feb 2004 01:07:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29611 for ; Wed, 25 Feb 2004 01:07:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvsCn-0000kX-00 for sipping@ietf.org; Wed, 25 Feb 2004 01:07:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvsBw-0000fP-00 for sipping@ietf.org; Wed, 25 Feb 2004 01:06:45 -0500 Received: from ns1.research.bell-labs.com ([204.178.16.6] helo=dirty.research.bell-labs.com) by ietf-mx with esmtp (Exim 4.12) id 1AvsBS-0000ZM-00 for sipping@ietf.org; Wed, 25 Feb 2004 01:06:14 -0500 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i1P665cD083654; Wed, 25 Feb 2004 01:06:05 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i1P65wws088566; Wed, 25 Feb 2004 01:05:58 -0500 (EST) Received: from bell-labs.com ([135.104.20.101]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i1P65vi0001493; Wed, 25 Feb 2004 01:05:57 -0500 (EST) Message-ID: <403C3B47.4@bell-labs.com> Date: Wed, 25 Feb 2004 01:05:59 -0500 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: "Daniel G. Petrie" CC: Henning Schulzrinne , Gonzalo Camarillo , sipping , Jonathan Rosemberg Subject: Re: [Sipping] Config framework References: <4039FEAD.5070708@ericsson.com> <403A01BD.7080905@cs.columbia.edu> <403A250F.9B29CE10@pingtel.com> <403A335F.8090403@bell-labs.com> <403C265D.38884E9A@pingtel.com> In-Reply-To: <403C265D.38884E9A@pingtel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Daniel G. Petrie wrote: >>Is it safe to assume that policy information is always part of the >>device or user configuration or can it be an independent piece of >>information a UA wants to subscribe to? Thus, would it make sense to >>define a profile-name "session-policies"? This could be useful if a >>device is configured by other means and simply wants to keep track of >>the policies in a network. > > I can think of applications where policy information is useful by itself (e.g. in a > profile server UI which facilitates profile data input) as well as applications were > the profile data is needed in conjuntion with the policy data. I would suggest > using something like XML name spaces so that everyting may be contained > in the same or separate XML documents. > Yes, this would allow the UA to get the relevant information. I'm not sure if it would enable a UA to subscribe to a certain type of information (e.g. policies). Thus, the notifier might have to return all URIs it has available for the subscriber in the NOTIFY. Unless the UA can determine the exact content of a document (e.g. based on MIME type or URI structure) it would have to download all documents to find the relevant pieces of information. I'm not sure though if this poses a real problem. >>Is there information that applies to a device besides the device >>configuration? If not, would it make sense to differentiate into the >>device configuration (requiring a discovery process) and subscriptions > > It is an interesting thought that discover may only be needed for device > profiles. > >>to the local network using my AOR as well as subscriptions to my home >>network (also using my AOR)? > > I am not sure I follow how things get routed differently to the local or > home network. Are there two different AORs? > One possibility could be that the UA subscribes separately to the AOR and to a discovered local profile server (both times using the same AOR in the From header). Volker _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 01:52:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01114 for ; Wed, 25 Feb 2004 01:52:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avstb-0001gr-HB for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 01:51:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P6pp8i006490 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 01:51:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avstb-0001gb-Ct for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 01:51:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01106 for ; Wed, 25 Feb 2004 01:51:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvstY-0004jr-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 01:51:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvssU-0004d0-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 01:50:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avsru-0004Xw-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 01:50:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avsrr-0001S2-Ty; Wed, 25 Feb 2004 01:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsrQ-0001P4-8N for sipping@optimus.ietf.org; Wed, 25 Feb 2004 01:49:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01060 for ; Wed, 25 Feb 2004 01:49:33 -0500 (EST) From: Miguel.An.Garcia@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvsrM-0004Wo-00 for sipping@ietf.org; Wed, 25 Feb 2004 01:49:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvsqT-0004SG-00 for sipping@ietf.org; Wed, 25 Feb 2004 01:48:38 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Avsps-0004NL-00 for sipping@ietf.org; Wed, 25 Feb 2004 01:48:00 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1P6luH00372; Wed, 25 Feb 2004 08:47:56 +0200 (EET) X-Scanned: Wed, 25 Feb 2004 08:47:44 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i1P6li0l012956; Wed, 25 Feb 2004 08:47:44 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Qet0ZG; Wed, 25 Feb 2004 08:47:41 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1P6le723710; Wed, 25 Feb 2004 08:47:40 +0200 (EET) Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 25 Feb 2004 08:47:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: [Sipping] Conferencing for UAs Date: Wed, 25 Feb 2004 08:47:36 +0200 Message-ID: <357AEC66DB509A4EA46CB85D7968B6AF84E121@esebe006.ntc.nokia.com> Thread-Topic: [Sipping] Conferencing for UAs Thread-Index: AcP64lM8N73D6EKRSDq0gfUZ9OowjgAiGVGg To: , Cc: , , X-OriginalArrivalTime: 25 Feb 2004 06:47:37.0052 (UTC) FILETIME=[413439C0:01C3FB6B] Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Gonzalo: I see your idea as a future proof solution. Basically, with the current = framework, we are assuming that subscriptions and other state = information is kept in the same entity that has established the dialog, = and that probably is the common case today. I don't see any application = today that would need to split and send pointers to different entities, = perhaps in the future, but I haven't seen that one. Having said that, I still think that from the point of view of the = protocol design it is a clear solution to separate items, and avoid = assumptions. Perhaps one of the most frustrating things in protocol = design is to find out that "a couple of years ago we design feature foo = based on assupmption bar, which is not valid anymore; now we need to = patch the protocol". So I would support your proposal. /Miguel > -----Original Message----- > From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: 24 February, 2004 16:26 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: sipping@ietf.org; alan.johnston@mci.com;=20 > oritl@microsoft.com; Garcia > Miguel.An (Nokia-NRC/Helsinki) > Subject: Re: [Sipping] Conferencing for UAs >=20 >=20 > Hello, >=20 > > I don't see what the problem is here and why it is a problem? Why do > > they need to be separate. Both the INVITEs and SUBSCRIBEs are > > destined to the same resource. >=20 > You send an INVITE to a conference server that will INVITE=20 > the rest of=20 > the participants in the conference. This INVITE is creating: >=20 > 1) a dialog > 2) an INVITE explosion > 3) a conference >=20 > I find it cleaner to have three separate URIs instead of a single URI=20 > where the server figures out what the UAC is trying to do by=20 > looking at=20 > the contents of the request (in this case, the event header). >=20 > In addition, the application server handling the presence for the=20 > conference may not be co-located with the entity handling the SIP=20 > signalling for the conference. >=20 > Furthermore, when you deal with requests that do not=20 > establish a dialog=20 > (e.g., MESSAGE), the server needs to convey the URI of the=20 > resource to=20 > the UAC using a different mechanism (Contact is not allowed).=20 > It would=20 > be good to use the same mechanism for requests that create a=20 > dialog and=20 > for requests that do not create a dialog. This avoids overloading the=20 > Contact header field. >=20 > I believe that having something like this: >=20 > Associated-Resource: sip:abc@a.com;purpose=3Dconference-state > Associated-Resource: sip:def@a.com;purpose=3Dexplosion-state >=20 > makes it easier for the UAC to know what can be done; it is=20 > more explicit. >=20 > Gonzalo >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=20 >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 01:54:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01350 for ; Wed, 25 Feb 2004 01:54:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avsvs-00028D-UX for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 01:54:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P6sCCT008187 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 01:54:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avsvs-00027y-Nx for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 01:54:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01258 for ; Wed, 25 Feb 2004 01:54:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avsvp-00057F-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 01:54:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avsul-0004vP-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 01:53:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avstj-0004lJ-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 01:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avstl-0001hg-Gm; Wed, 25 Feb 2004 01:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvstS-0001g2-Tx for sipping@optimus.ietf.org; Wed, 25 Feb 2004 01:51:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01094 for ; Wed, 25 Feb 2004 01:51:40 -0500 (EST) From: Miguel.An.Garcia@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvstP-0004io-00 for sipping@ietf.org; Wed, 25 Feb 2004 01:51:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvssQ-0004cL-00 for sipping@ietf.org; Wed, 25 Feb 2004 01:50:38 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Avsre-0004Xp-00 for sipping@ietf.org; Wed, 25 Feb 2004 01:49:50 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1P6nhH02017; Wed, 25 Feb 2004 08:49:43 +0200 (EET) X-Scanned: Wed, 25 Feb 2004 08:49:22 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i1P6nM2f020329; Wed, 25 Feb 2004 08:49:22 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00ylOyQX; Wed, 25 Feb 2004 08:49:20 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1P6nJO27751; Wed, 25 Feb 2004 08:49:19 +0200 (EET) Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 25 Feb 2004 08:49:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: [Sipping] Conferencing for UAs Date: Wed, 25 Feb 2004 08:49:09 +0200 Message-ID: <357AEC66DB509A4EA46CB85D7968B6AF84E122@esebe006.ntc.nokia.com> Thread-Topic: [Sipping] Conferencing for UAs Thread-Index: AcP6/myqovRKR0f7Q6GUhJOlQoMQVAAbOTmQ To: , Cc: , , , X-OriginalArrivalTime: 25 Feb 2004 06:49:18.0177 (UTC) FILETIME=[7D7AAD10:01C3FB6B] Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 24 February, 2004 19:47 > To: Gonzalo Camarillo > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); sipping@ietf.org; > alan.johnston@mci.com; oritl@microsoft.com; Garcia Miguel.An > (Nokia-NRC/Helsinki) > Subject: Re: [Sipping] Conferencing for UAs [snap] > Taken to extreme, what you suggest would lead to a different=20 > address for=20 > OPTIONS, for MESSAGE, for PUBLISH, for REGISTER, etc. And maybe=20 > different addresses for each kind of subscription. >=20 > I don't want to go there. >=20 > Paul >=20 Aren't already there with Caller Preferences? /Miguel _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 02:52:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01711 for ; Wed, 25 Feb 2004 02:52:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtpX-0006pY-Rq for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 02:51:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P7ph8L026252 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 02:51:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtpX-0006pK-0c for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 02:51:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01703 for ; Wed, 25 Feb 2004 02:51:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvtpS-0003sy-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 02:51:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avtoc-0003o3-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 02:50:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avto5-0003iD-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 02:50:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avtnv-0006S1-0q; Wed, 25 Feb 2004 02:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtnS-0006Mj-JC for sipping@optimus.ietf.org; Wed, 25 Feb 2004 02:49:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01577 for ; Wed, 25 Feb 2004 02:49:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvtnO-0003ei-00 for sipping@ietf.org; Wed, 25 Feb 2004 02:49:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvtmQ-0003Xz-00 for sipping@ietf.org; Wed, 25 Feb 2004 02:48:30 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AvtlR-0003S5-00 for sipping@ietf.org; Wed, 25 Feb 2004 02:47:29 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1P7lTAh023706 for ; Wed, 25 Feb 2004 08:47:29 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 08:47:29 +0100 Received: from ericsson.com (rvi2-92-155.sw.ericsson.se [153.88.92.155]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSLD2FM5; Wed, 25 Feb 2004 08:47:29 +0100 Message-ID: <403C530E.1070204@ericsson.com> Date: Wed, 25 Feb 2004 09:47:26 +0200 X-Sybari-Trust: e8dc3ebb c77f3eb6 b2f8f052 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston CC: hisham.khartabil@nokia.com, sipping@ietf.org, oritl@microsoft.com, Miguel.An.Garcia@nokia.com Subject: Re: [Sipping] Conferencing for UAs References: <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <5.2.1.1.0.20040224084212.02819ef8@pop.mcit.com> In-Reply-To: <5.2.1.1.0.20040224084212.02819ef8@pop.mcit.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 07:47:29.0712 (UTC) FILETIME=[9E98A300:01C3FB73] Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Alan, I understand that my comments come late in the game and that it might be impossible to change the conferencing framework at this point. In any event, I do not agree with your statement below: > No - this is the problem. You are looking at your single narrow > application. I believe I am actually looking at a much wider range of applications than just conferencing. So, to me, the problem is that the conferencing framework is too focused on a "single narrow application"; conferencing. In a conferencing service, there is a single resource created by the initial INVITE; a conference. That's why the server can use the Contact header field to send it back to the UAC. If you think of services that create more than one resource (e.g., an explosion and a conference), the server may not want to use the same URI for both. Moreover, conceptually, is is not a good thing to use the same URI to identify both resources. So, my main concern is the semantics overload of the Contact header. (We abused this header when design REGISTER as well, by the way. That's why I do not want to do it again.) In my opinion, the Contact header is the URI where you send subsequent requests within the dialog. If the server wants to tell the client that a resource (e.g., a conference) has been created, it can use a different header to include the URI of such a resource. Note that, if you want both URIs to be the same (like in the conferencing case), you can do it. Contact: sip:1234@a.com;isfocus Resource: sip:1234@a.com;isfocus An entity receiving these headers would use the URI in the Contact header to send subsequent requests *within* the dialog, and the URI in the other header to send requests *outside* that dialog (e.g., SUBSCRIBE to the conference package). In brief, instead of sticking the conference URI in a Contact header and label that URI with an isfocus parameter so that the UAC figures what is going on, I find it more explicit to use a different header. Although, as I said, I understand that this comment comes late and that may not be useful at this point. Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 04:29:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05671 for ; Wed, 25 Feb 2004 04:29:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvLE-000569-0o for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 04:28:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P9SVFS019588 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 04:28:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvLB-00055U-Va for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 04:28:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05510 for ; Wed, 25 Feb 2004 04:28:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvvL8-0006H0-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 04:28:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvvJL-0005sW-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 04:26:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvvHQ-0005Ou-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 04:24:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvHE-00041H-OX; Wed, 25 Feb 2004 04:24:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avulq-0002CS-MV for sipping@optimus.ietf.org; Wed, 25 Feb 2004 03:51:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03791 for ; Wed, 25 Feb 2004 03:51:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avulo-0001eb-00 for sipping@ietf.org; Wed, 25 Feb 2004 03:51:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avukw-0001X1-00 for sipping@ietf.org; Wed, 25 Feb 2004 03:51:02 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AvukB-0001Pb-00 for sipping@ietf.org; Wed, 25 Feb 2004 03:50:15 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1P8oFYG016679 for ; Wed, 25 Feb 2004 09:50:16 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 09:50:15 +0100 Received: from ericsson.com (rvi2-92-155.sw.ericsson.se [153.88.92.155]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSMBL192; Wed, 25 Feb 2004 09:50:15 +0100 Message-ID: <403C61C1.80102@ericsson.com> Date: Wed, 25 Feb 2004 10:50:09 +0200 X-Sybari-Trust: cb266cdb c77f3eb6 b2f8f052 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping CC: jmpolk@cisco.com, Brian.rosen@marconi.com, ono.kumiko@lab.ntt.co.jp, tachimoto.shinya@lab.ntt.co.jp Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 08:50:15.0797 (UTC) FILETIME=[635B9A50:01C3FB7C] Content-Transfer-Encoding: 7bit Subject: [Sipping] E2M security and location conveyance Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, in case the authors of the folloing drafts are not in touch yet, I believe you should have a look at each other's work to make sure that the e2m security stuff is taking into account the location conveyance requirements. Specifically, Section 2 of the location conveyance draft directly talks about e2m security. http://www.ietf.org/internet-drafts/draft-ietf-sipping-e2m-sec-reqs-01.txt http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirements-00.txt Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 04:44:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06617 for ; Wed, 25 Feb 2004 04:44:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvZw-0006nb-SW for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 04:43:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P9hi2e026116 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 04:43:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvZt-0006n9-VB for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 04:43:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06434 for ; Wed, 25 Feb 2004 04:43:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvvZq-0000Tr-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 04:43:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvvXZ-0007m4-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 04:41:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvvWe-0007Xg-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 04:40:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvUQ-000613-S7; Wed, 25 Feb 2004 04:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvU1-0005w0-6Y for sipping@optimus.ietf.org; Wed, 25 Feb 2004 04:37:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06183 for ; Wed, 25 Feb 2004 04:37:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvvTy-0007IY-00 for sipping@ietf.org; Wed, 25 Feb 2004 04:37:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvvT4-0007Ej-00 for sipping@ietf.org; Wed, 25 Feb 2004 04:36:39 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AvvST-0007Ap-00 for sipping@ietf.org; Wed, 25 Feb 2004 04:36:01 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1P9Zrv9016265; Wed, 25 Feb 2004 18:35:53 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1P9Zqmt018982; Wed, 25 Feb 2004 18:35:52 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1P9ZqLm013359; Wed, 25 Feb 2004 18:35:52 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1P9Zqgi013356; Wed, 25 Feb 2004 18:35:52 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1P9ZpFX019302; Wed, 25 Feb 2004 18:35:51 +0900 (JST) Received: from img.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA12730; Wed, 25 Feb 2004 18:35:51 +0900 (JST) Received: from lab.ntt.co.jp by img.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with SMTP id SAA09120; Wed, 25 Feb 2004 18:35:50 +0900 (JST) Date: Wed, 25 Feb 2004 18:35:38 +0900 From: Kumiko Ono Subject: Re: [Sipping] Re: E2M security solution To: Gonzalo Camarillo , volkerh@bell-labs.com Cc: sipping , tachimoto.shinya@lab.ntt.co.jp MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 3.07beta6 (WinNT,501) In-Reply-To: <6AC3FA9A0545F4ono.kumiko@lab.ntt.co.jp> References: <6AC3FA9A0545F4ono.kumiko@lab.ntt.co.jp> Message-Id: <7EC3FB82BA6357ono.kumiko@lab.ntt.co.jp> Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Volker, I have a question about security of the MIO. Let's consider for firewall control located with a proxy. The MIO header that you propose contains parts of SDP information. When UAs encrypt SDP for end-to-end in order to conceal IP addresses and port numbers, does the MIO also contain the same information to need to use e2e encryption? Thanks, Kumiko >Hi, > >I agree with you about the e2m security solution could partly solve the >session-specific policies. > >In my understanding, the policy draft proposes new headers to disclose >only the information to *all* proxies in the path. Some mechanism are >needed in order to disclose the information to *specific* proxies. The >e2m security can be applied as one of the mechanisms. > >Regards, > >Kumiko > >>Hello, >> >>The e2m security solution, described in the draft below, >>http://www.ietf.org/internet-drafts/draft-ono-sipping-end2middle-security- >>01.txt >> >>attempts to resolve some of the problems that the session-specific >>policies draft addresses: >>http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-spec-policy- >>00.txt >> >>The need of a UA to obtain the policies that a particular proxy has is >>dealt with in both drafts. In addition, the e2m security draft talks >>about disclosing information to intermediaries. The policy draft >>addresses this issue and defines a means to disclose *only* the >>information needed by the proxy. >> >>My comments on the e2m requirements draft apply also to this one. We >>should try to align both efforts (session policies and e2m security). >> >>Thanks, >> >>Gonzalo >> >> >>This communication is confidential and intended solely for the addressee(s) >>. Any unauthorized review, use, disclosure or distribution is prohibited. >>If you believe this message has been sent to you in error, please notify >>the sender by replying to this transmission and delete the message without >>disclosing it. Thank you. >> >>E-mail including attachments is susceptible to data corruption, >>interruption, unauthorized amendment, tampering and viruses, and we only >>send and receive e-mails on the basis that we are not liable for any such >>corruption, interception, amendment, tampering or viruses or any >>consequences thereof. > >-- >Kumiko Ono >NTT Network Service Systems Labs. >Tel +81 422 59 4508/Fax +81 422 60 4012 > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP -- Kumiko Ono NTT Network Service Systems Labs. Tel +81 422 59 4508/Fax +81 422 60 4012 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 04:57:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07356 for ; Wed, 25 Feb 2004 04:57:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvmW-00087Q-O2 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 04:56:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P9uinx031209 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 04:56:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvmR-00087E-Fq for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 04:56:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07347 for ; Wed, 25 Feb 2004 04:56:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvvmN-00020m-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 04:56:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvvlU-0001wp-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 04:55:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avvkz-0001sZ-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 04:55:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avvkv-0007vH-8z; Wed, 25 Feb 2004 04:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvkT-0007uc-Ig for sipping@optimus.ietf.org; Wed, 25 Feb 2004 04:54:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07303 for ; Wed, 25 Feb 2004 04:54:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvvkQ-0001rI-00 for sipping@ietf.org; Wed, 25 Feb 2004 04:54:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvvjU-0001nK-00 for sipping@ietf.org; Wed, 25 Feb 2004 04:53:36 -0500 Received: from natsmtp00.rzone.de ([81.169.145.165] helo=natsmtp00.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 1Avvih-0001jF-00 for sipping@ietf.org; Wed, 25 Feb 2004 04:52:47 -0500 Received: from RocknRoll (pD9E0DBE2.dip.t-dialin.net [217.224.219.226]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i1P9qZUx018555; Wed, 25 Feb 2004 10:52:36 +0100 (MET) From: "Harry Behrens" To: "'Paul Kyzivat'" Cc: , Subject: AW: AW: [Sipping] Roaming Architecture for SIP Date: Wed, 25 Feb 2004 10:54:13 +0100 Message-ID: <001901c3fb85$54533ff0$2c00a8c0@RocknRoll> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <403B8ABC.8020602@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul, inline. > > The scenario is of a user based e.g. in Berlin/Germany on a > business > > trip in Beijing/China. The user will want to both be > reachable under > > his home AOR (for that he registers with his HN) > > I'm ok with that. > That's nice. > > as well as make use of the VN for local calls, > > especially local PSTN breakout (this is why he wants to > have a valid > > registration with the VN). > > Why? His billing relationship is with his HN. Why not let the > HN figure > out the best way to route this calls? If it is via the VN's gateways, > then it can route the calls to the VN. > In all practical experience: if you and your VN is in China and your HN is in Germany (or any similar setup), who would you want to route your calls within China? The HN has an important role to fulfil as the anchor of trust for the billing relationship, however we don't think it neither feasible nor realistic nor even desirable from an IETF point of view at this point in time to have the HN fulfil routing decisions at the HN. The OSP as defined by ETSI goes into this direction. However this seems a far too carrier-centric model to be of use in the somewhat more flexible world of the Internet and specifically ITSPs. Furthermore, even if my HN has my billing relationship, why should we be able to assume that this HN knows anything about the topography of VoIP connections in China? > > Furthermore, in a number of cases, one encounters > RTP-proxying, where > > around-the-world loops are to be avoided. > > Certainly that is likely to be a bad thing. But does it require a > signaling identity with the VN to achieve that? > If you put the question like that, no. However, in practice the RTP-Proxy is normally in the domain/realm of the carrier handling the PSTN break-out. How would you suggest for the signalling to happen at the HN and the media conversion at the VN if break-out is happening at the VN? Pls. note that we do not assume a VoIP peering agreement between the two networks (VN, HN). In fact the HN being a VoIP carrier is actually optional. The emphasis is on the HN to be an "authorized billing entity". > > Another issue which we foresee is that in the near future hotels, > > airports or other semi-closed (walled garden) Internet > access points, > > will force users through their own VoIP (SIP) proxy infrastructure, > > similar to what a lot of sites aleady do in the case of HTTP. > > Sure. But as long as those things are *proxies*, the UA > should still be > able to register with his HN. > > Dealing with that depends a bit on how users will be forced. The way > hotels do it today depends on details of http that won't necessarily > work for sip. > Either way, the "walled garden proxy" would probably/possibly want the user to be registered - even if further registrations such as with the HN are allowed. Again: there is nothing to be gained by putting routing and signalling decisions for the local domain (i.e. China, VN in the example) to the HN. Conversely a lot is to be gained in terms of flexibility in following the model. Harry > Paul > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 05:25:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09084 for ; Wed, 25 Feb 2004 05:25:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwDg-0002Gc-Qo for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 05:24:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PAOmFI008713 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 05:24:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwDg-0002GS-H4 for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 05:24:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09072 for ; Wed, 25 Feb 2004 05:24:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvwDd-0005F9-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 05:24:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvwCi-00059d-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 05:23:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvwC7-000541-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 05:23:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwBz-00024s-W4; Wed, 25 Feb 2004 05:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwB3-00022z-AO for sipping@optimus.ietf.org; Wed, 25 Feb 2004 05:22:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08922 for ; Wed, 25 Feb 2004 05:22:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvwB0-0004wV-00 for sipping@ietf.org; Wed, 25 Feb 2004 05:22:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avw9v-0004oj-00 for sipping@ietf.org; Wed, 25 Feb 2004 05:20:56 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Avw9F-0004i3-00 for sipping@ietf.org; Wed, 25 Feb 2004 05:20:14 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1PAKEqY024241 for ; Wed, 25 Feb 2004 11:20:14 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 11:20:14 +0100 Received: from ericsson.com (rvi2-92-155.sw.ericsson.se [153.88.92.155]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSMBMD76; Wed, 25 Feb 2004 11:20:13 +0100 Message-ID: <403C76D9.2010401@ericsson.com> Date: Wed, 25 Feb 2004 12:20:09 +0200 X-Sybari-Trust: 3bad6c45 c77f3eb6 b2f8f052 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston CC: hisham.khartabil@nokia.com, sipping@ietf.org, oritl@microsoft.com, Miguel.An.Garcia@nokia.com Subject: Re: [Sipping] Conferencing for UAs References: <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <5.2.1.1.0.20040224084212.02819ef8@pop.mcit.com> In-Reply-To: <5.2.1.1.0.20040224084212.02819ef8@pop.mcit.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 10:20:14.0788 (UTC) FILETIME=[F5684040:01C3FB88] Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, as an additional note, the following draft http://www.ietf.org/internet-drafts/draft-khartabil-sip-policy-uri-call-info-purpose-00 proposes to carry a policy URI for the conference in a Call-Info header... what I am proposing is a more general mechanism that can carry all the URIs of the resources created by a request. Otherwise, we would place the policy URI in the call-info header, the explosion URI in the associated-explosion header, the conference URI in the contact header, etc, etc... I want a cleaner way (e.g., a single header) to provide the URIs of the resources associated to a request. Associated-Resource: sip:abc@a.com;purpose=conference-state Associated-Resource: sip:def@a.com;purpose=explosion-state Associated-Resource: sip:def@a.com;purpose=conference-policy Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 09:33:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17976 for ; Wed, 25 Feb 2004 09:33:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw05m-0005aJ-QD for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 09:32:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PEWsop021461 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 09:32:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw05m-0005a4-Lt for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 09:32:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17946 for ; Wed, 25 Feb 2004 09:32:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw05k-0005ZA-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 09:32:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw04o-0005TM-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 09:31:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw04E-0005O9-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 09:31:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw03x-00054M-R3; Wed, 25 Feb 2004 09:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw03s-00053M-Ip for sipping@optimus.ietf.org; Wed, 25 Feb 2004 09:30:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17857 for ; Wed, 25 Feb 2004 09:30:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw03q-0005Mc-00 for sipping@ietf.org; Wed, 25 Feb 2004 09:30:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw02y-0005HH-00 for sipping@ietf.org; Wed, 25 Feb 2004 09:30:01 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Aw02M-0005BZ-00 for sipping@ietf.org; Wed, 25 Feb 2004 09:29:22 -0500 Received: from bear.cs.columbia.edu (IDENT:lP3ja4ciK8C21Gv9YzEfTHWbt9AhMzfA@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1PETJmS028174 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 25 Feb 2004 09:29:19 -0500 (EST) Received: from cs.columbia.edu (pool-138-89-104-237.mad.east.verizon.net [138.89.104.237]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1PETImi011448 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Feb 2004 09:29:18 -0500 Message-ID: <403CB137.1030808@cs.columbia.edu> Date: Wed, 25 Feb 2004 09:29:11 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: "Daniel G. Petrie" CC: Gonzalo Camarillo , sipping Subject: Re: [Sipping] Config framework References: <4039FEAD.5070708@ericsson.com> <403A01BD.7080905@cs.columbia.edu> <403A250F.9B29CE10@pingtel.com> <403A889F.4010601@cs.columbia.edu> <403C348D.21C43F72@pingtel.com> In-Reply-To: <403C348D.21C43F72@pingtel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I am not sure I follow this. Perhaps if I elaborate, you can help me realize > my confusion. The three types of profile data are: local network, user and > device data. In the above example I was suggesting that in many environments > the UA is not mobile or at least not frequently moved. Hense the UA can > be associated with a specific location. In these environments it is convenient > to combine the local network data and the device specific data. I was not > suggesting that the user data should be denormalized. A user may have > many devices. The devices can all use the same user profile data. I think we're in agreement. My suggestion is to simply logically separate the local network, user and device data and link those by pointers (URIs), rather than by inclusion. Thus, even if a stationary device is always associated a single user, it would reference rather than include the user information. > > I am also questioning whether people think we really need three distinct > types of profiles (local network, user and device). Is there a real life > environment where we need all three or can it be accomlished with > two by combining parts of the third with the other two. If people think > we need all three then we need to have three different discovery models > and ways to form three different AORs (for each profile type). This is not > difficult, I just want to be sure the extra moving parts are necessary. While many devices will have one device = one user = one location, even within these enterprises there may well be classes of SIP endpoints that don't. Variations of hoteling, both the Hilton kind and the intra-company desk loaning, come to mind. If I carry a device (laptop, PDA) with me from one branch to another, there will be device-based information that only depends on the device characteristics (media capabilities, user interface, network speed, etc.), some that depend on where I plug in the device (emergency call numbers, local dial plan, outbound proxy configuration, local media policy) and some that are the same for all my devices and only depend on my user identity (general media preferences, speed dial, buddy lists). Note, for example, that media policy appears in all three configurations. Since network, user and device are clearly distinguishable in practice, I'd argue that proponents of unifying two of them need to prove that they should *never* be treated separately, rather than the opposite. > > There is nothing newer than this expired draft. I was hoping to shake > the dust off and restructure this document once the framework was > last called. I think the document identifies some good profile data > requirements, but I think they should be sliced up a little differently. The discussion here illustrates that it would be useful to have at least a rough set of parameters that we can use as test cases to see if they are accommodated well within the framework. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 10:14:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20672 for ; Wed, 25 Feb 2004 10:14:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0je-0006Ym-Bu for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 10:14:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PFE6MK025210 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 10:14:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0je-0006YX-7Z for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 10:14:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20621 for ; Wed, 25 Feb 2004 10:14:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0jb-0002K0-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 10:14:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw0ig-0002DR-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 10:13:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0hr-00026h-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 10:12:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0hd-0005ji-CX; Wed, 25 Feb 2004 10:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0hR-0005cI-FI for sipping@optimus.ietf.org; Wed, 25 Feb 2004 10:11:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20365 for ; Wed, 25 Feb 2004 10:11:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0hP-00024H-00 for sipping@ietf.org; Wed, 25 Feb 2004 10:11:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw0gR-0001yE-00 for sipping@ietf.org; Wed, 25 Feb 2004 10:10:48 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw0fa-0001oN-00 for sipping@ietf.org; Wed, 25 Feb 2004 10:09:54 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1PF9L4U008752; Wed, 25 Feb 2004 07:09:21 -0800 (PST) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGH65357; Wed, 25 Feb 2004 10:09:20 -0500 (EST) Message-ID: <403CBA9F.4030809@cisco.com> Date: Wed, 25 Feb 2004 10:09:19 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Alan Johnston , hisham.khartabil@nokia.com, sipping@ietf.org, oritl@microsoft.com, Miguel.An.Garcia@nokia.com Subject: Re: [Sipping] Conferencing for UAs References: <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <5.2.1.1.0.20040224084212.02819ef8@pop.mcit.com> <403C76D9.2010401@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bonzalo, I am *slightly* warming to your point, but I am concerned that there is a slippery slope here and it will require a great deal of care to avoid heading down that slope. I agree that policy URI for conferences is an analogous kind of usage. I'm not yet convinced that such an approach should be used often, or that we need a more general way to return such things. For cases where it is appropriate, call-info may be a sufficient mechanism. I am definitely not convinced that we need separate URIs for requests within a dialog and outside of one. We are concurrently working on the GRUU proposal with the intent that we can use the same URI for both. Nor am I convinced that we need separate URIs for INVITE and SUBSCRIBE, when the logical resource is the same for both. (E.g. join a conference vs request info (via sip) for the same conference.) The key is determining when things are truly distinct resources. One hint is that they are addressed with different protocols. That is one justification for separating conference policy from conference focus. Operations that do too much at once (e.g. create multiple distinct resources) raise a red flag for me - they aren't necessarily wrong, but they require extra consideration because they are inclined to be complex to understand. So hopefully there won't be many requests that need to reference multiple "output" resources. Paul Gonzalo Camarillo wrote: > Hi, > > as an additional note, the following draft > http://www.ietf.org/internet-drafts/draft-khartabil-sip-policy-uri-call-info-purpose-00 > > > proposes to carry a policy URI for the conference in a Call-Info > header... what I am proposing is a more general mechanism that can carry > all the URIs of the resources created by a request. > > Otherwise, we would place the policy URI in the call-info header, the > explosion URI in the associated-explosion header, the conference URI in > the contact header, etc, etc... I want a cleaner way (e.g., a single > header) to provide the URIs of the resources associated to a request. > > Associated-Resource: sip:abc@a.com;purpose=conference-state > Associated-Resource: sip:def@a.com;purpose=explosion-state > Associated-Resource: sip:def@a.com;purpose=conference-policy > > > Thanks, > > Gonzalo > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any > such corruption, interception, amendment, tampering or viruses or any > consequences thereof. > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 10:37:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22346 for ; Wed, 25 Feb 2004 10:37:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw15x-00021M-32 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 10:37:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PFb8jU007762 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 10:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw15v-000217-Lq for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 10:37:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22309 for ; Wed, 25 Feb 2004 10:37:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw15t-0004gN-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 10:37:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw14u-0004YH-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 10:36:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw143-0004Rz-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 10:35:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw13w-0001OF-To; Wed, 25 Feb 2004 10:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw13p-0001NL-7S for sipping@optimus.ietf.org; Wed, 25 Feb 2004 10:34:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22155 for ; Wed, 25 Feb 2004 10:34:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw13m-0004Q7-00 for sipping@ietf.org; Wed, 25 Feb 2004 10:34:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw12s-0004LE-00 for sipping@ietf.org; Wed, 25 Feb 2004 10:34:00 -0500 Received: from firewall.citel.com ([62.190.107.60] helo=ivor.citel.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw12a-0004Fd-00 for sipping@ietf.org; Wed, 25 Feb 2004 10:33:40 -0500 Subject: RE: [Sipping] updated dialog package MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Wed, 25 Feb 2004 15:32:25 -0000 Message-ID: Thread-Topic: [Sipping] updated dialog package Thread-Index: AcP6hEXYW0pLvW7yQvKkm05CpYCTlQAOFaeQ From: "Paul Pepper" To: "Rohan Mahy" Cc: "sipping" Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Comments in-line. Thanks, Paul. > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com]=20 > Sent: Tuesday, February 24, 2004 3:14 AM > To: Paul Pepper > Cc: Rohan Mahy; sipping > Subject: Re: [Sipping] updated dialog package >=20 >=20 >=20 > On Feb 23, 2004, at 9:40 AM, Paul Pepper wrote: >=20 > > Hi, > > > > I work for a company that has developed handset gateway devices that > > enable legacy, digital, business-grade telephones to be driven using > > SIP. For example, this enables an existing legacy PBX user=20 > > to retain > > their telephones and cabling, but to replace the PBX by a=20 > > Softswitch or > > IP Centrex system. As most business-grade telephone=20 > > systems make use=20 > > of > > a shared line facility, the addition of a shared line example to the > > dialog event package ID is of great interest to us, and others who > > support these types of feature. > > > > Although incorporating a shared line example is a step=20 > > towards a common > > approach to shared line implementation, I don't believe it goes far > > enough. Our current implementation of shared lines has=20 > > shown that the > > following issues need to be addressed by the spec, and=20 > > should be shown > > in the examples: > > > > o Line seize, an essential part of any shared line=20 > > implementation, is > > not adequately described. When more than one user agent attempts to > > seize a line at approximately the same instant, a race condition=20 > > arises. > > No description of how to handle the race is given - an example > > application/dialog-info+xml NOTIFY payload is provided, but=20 > > this alone > > is inadequate, as message sequencing is an important part=20 > > of seizing a > > line. The Line Seize condition will be covered in the > > "anil-sipping-bla-draft" that Venkatesh refers to. >=20 > Line seizure is well beyond what would be appropriate to=20 > standardize in=20 > SIPPING because for many types of UAs that concept does not=20 > even exist.=20 > I was just trying to demonstrate a non-normative=20 > description of how it=20 > could be implemented. How you judge who "wins" a seizure race=20 > condition=20 > is an implementation specific issue. In fact, its quite likely that=20 > different behaviors will be desired by different customers. When=20 > talking about implementing this at Cisco, we concluded that a=20 > configuration knob was needed to satisfy essentially opposite=20 > requirements from two different customers. Each customer was equally=20 > adamant that he was "right" and the other was "wrong". As a=20 > result, I=20 > find it unlikely that SIPPING could come to come to consensus on what=20 > "proper seizing behavior" is even if we ignored the fact that=20 > the bulk=20 > of deployed SIP UAs are software UAs which have no lines to seize. > Yes, determining which user agents should win seize races is a matter of policy, and implementation specific. However, the mechanism used to convey whether a seize race has been won seems to be a matter for standardisation (e.g. a non-200 final response to the NOTIFY requesting the seize could indicate that the seize operation has failed). > > o Handling of multiple instances of a shared line has been=20 > > overlooked. > > On business-grade PBX systems a line will roughly=20 > > correspond to an AOR. > > However, many such systems permit multiple "instances" of a=20 > > shared line > > to appear on a single endpoint. For example, a number of=20 > > instances of a > > "product support" shared line might appear on all the=20 > > endpoints of the > > product support group, thereby allowing multiple calls to=20 > > be taken and > > passed around within the group. >=20 > This has not been overlooked at all. You can have multiple=20 > subscriptions (one per AOR), or you can subscribe to a list of AORs=20 > with the event list extension: >=20 > =09 > http://www.ietf.org/internet-drafts/draft-ietf-simple-event-li > st-04.txt >=20 I haven't been sufficiently clear on this point. As you point out, each shared AOR will have its own subscription. Take an example AOR of support@example. Although a single registration and two subscriptions (one in each direction, as subscriber and notifier, if a state agent is used) are used per AOR on each user agent, multiple calls to/from that AOR may be active at any time. If a user agent has the shared line capability then all calls to support@example will be presented on it by, say, illuminating one button per call. (Of course this is constrained to varying degrees by the user agent's display capabilities.) As each button shows a call to support@example the calls must be presented on those buttons in a consistent manner across all user agents on the network. This will allow Harry to put a call to support@example on hold and verbally tell Thelma which button to press in order to pick that call up. If all the calls to support@example are presented in an arbitrary manner on different user agents, then the coherency of call presentation is lost. This is a problem as coherent call presentation is a requirement of existing PBX users, and gives the only meaningful use for this feature. One way of achieving a consistent mapping of calls to buttons (if buttons are the user interface mechanism used) is to index buttons on all the user agents. That way, a call can be mapped to the specific button on all user agents of an installation. > > o The mechanism used to convey that a call has been placed on hold > > appears to rely upon implementation-specific parameters,=20 > > found in the > > xml's element. I can't see any reference to=20 > > definitions of the > > values used by this element's pname and pval attributes > > (pname=3D"+activity" pval=3D"noninteractive"), so I assume they're > > non-standard. >=20 > This was due to distraction on my part. I had intended to include a=20 > discussion of this in the current draft, but somehow left it=20 > out at 2am=20 > the day of the draft deadline. I'm terribly sorry about that. I'll=20 > send out more about the hold issue tomorrow. >=20 > thanks, > -rohan >=20 > > Thanks, > > > > Paul. > > > >> -----Original Message----- > >> From: Rohan Mahy [mailto:rohan@cisco.com] > >> Sent: Thursday, February 19, 2004 6:00 PM > >> To: sipping > >> Cc: rohan@cisco.com > >> Subject: [Sipping] updated dialog package > >> > >> > >> Hi Everyone, > >> > >> I've updated the dialog packages with the changes we agreed to in > >> Minneapolis (removing CSeq and the Route-Set). > >> > >> I've also provided a detailed example of using the dialog > >> package for a > >> "shared-line" application. I apologize for my tardiness=20 > >> here. I was > >> supposed to post something shortly after the meeting. I=20 > >> any case, I > >> believe this demonstrates that the current syntax is at least > >> sufficient for the use cases we've discussed. I would like to hear > >> from all of you if this does the trick. > >> > >> many thanks, > >> -rohan > >> > >> > >> _______________________________________________ > >> Sipping mailing list =20 > >> https://www1.ietf.org/mailman/listinfo/sipping > >> This list=20 > >> is for NEW development of the application of SIP > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sip@ietf.org for new developments of core SIP > >> >=20 >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 10:46:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23091 for ; Wed, 25 Feb 2004 10:46:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1EN-0002vY-NW for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 10:45:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PFjpOk011246 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 10:45:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1EN-0002vJ-K1 for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 10:45:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23064 for ; Wed, 25 Feb 2004 10:45:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw1EL-0005rg-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 10:45:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw1DP-0005m8-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 10:44:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw1Ca-0005gp-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 10:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1Cb-0002aZ-Ri; Wed, 25 Feb 2004 10:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1Bg-0002a2-J3 for sipping@optimus.ietf.org; Wed, 25 Feb 2004 10:43:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22895 for ; Wed, 25 Feb 2004 10:43:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw1Be-0005Zi-00 for sipping@ietf.org; Wed, 25 Feb 2004 10:43:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw1Al-0005T4-00 for sipping@ietf.org; Wed, 25 Feb 2004 10:42:08 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Aw1AA-0005MO-00 for sipping@ietf.org; Wed, 25 Feb 2004 10:41:30 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1PFfQYG027724 for ; Wed, 25 Feb 2004 16:41:30 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 16:41:25 +0100 Received: from ericsson.com (rvi2-92-155.sw.ericsson.se [153.88.92.155]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSMBP4B3; Wed, 25 Feb 2004 16:41:24 +0100 Message-ID: <403CC221.8070404@ericsson.com> Date: Wed, 25 Feb 2004 17:41:21 +0200 X-Sybari-Trust: 12e1584c c77f3eb6 0a449737 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Alan Johnston , hisham.khartabil@nokia.com, sipping@ietf.org, oritl@microsoft.com, Miguel.An.Garcia@nokia.com Subject: Re: [Sipping] Conferencing for UAs References: <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <5.2.1.1.0.20040224084212.02819ef8@pop.mcit.com> <403C76D9.2010401@ericsson.com> <403CBA9F.4030809@cisco.com> In-Reply-To: <403CBA9F.4030809@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 15:41:25.0218 (UTC) FILETIME=[D37A8420:01C3FBB5] Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul, I believe we are in agreement. You use different URIs for different resources. Additionally, it is not wise to overload too much a request so that it creates too many resources. We agree on these two points. In any event, an INVITE that creates a conference, an explosion, and a policy URI is not such a strange example. Another example that covers what you said about different protocols would be an INVITE that, in addition to creating a conference (identified by a SIP URI), creates a mailing list for the conference (indentified by a mailto: URI). In addition, the mechanism used to convery the URIs of these resources to the UAC should not be INVITE specific, because requests such as MESSAGE can also trigger the creation of new resources (e.g., a explosion of MESSAGEs). Thanks, Gonzalo Paul Kyzivat wrote: > Bonzalo, > > I am *slightly* warming to your point, but I am concerned that there is > a slippery slope here and it will require a great deal of care to avoid > heading down that slope. > > I agree that policy URI for conferences is an analogous kind of usage. > I'm not yet convinced that such an approach should be used often, or > that we need a more general way to return such things. For cases where > it is appropriate, call-info may be a sufficient mechanism. > > I am definitely not convinced that we need separate URIs for requests > within a dialog and outside of one. We are concurrently working on the > GRUU proposal with the intent that we can use the same URI for both. > > Nor am I convinced that we need separate URIs for INVITE and SUBSCRIBE, > when the logical resource is the same for both. (E.g. join a conference > vs request info (via sip) for the same conference.) > > The key is determining when things are truly distinct resources. One > hint is that they are addressed with different protocols. That is one > justification for separating conference policy from conference focus. > > Operations that do too much at once (e.g. create multiple distinct > resources) raise a red flag for me - they aren't necessarily wrong, but > they require extra consideration because they are inclined to be complex > to understand. So hopefully there won't be many requests that need to > reference multiple "output" resources. > > Paul > > Gonzalo Camarillo wrote: > >> Hi, >> >> as an additional note, the following draft >> http://www.ietf.org/internet-drafts/draft-khartabil-sip-policy-uri-call-info-purpose-00 >> >> >> proposes to carry a policy URI for the conference in a Call-Info >> header... what I am proposing is a more general mechanism that can >> carry all the URIs of the resources created by a request. >> >> Otherwise, we would place the policy URI in the call-info header, the >> explosion URI in the associated-explosion header, the conference URI >> in the contact header, etc, etc... I want a cleaner way (e.g., a >> single header) to provide the URIs of the resources associated to a >> request. >> >> Associated-Resource: sip:abc@a.com;purpose=conference-state >> Associated-Resource: sip:def@a.com;purpose=explosion-state >> Associated-Resource: sip:def@a.com;purpose=conference-policy >> >> >> Thanks, >> >> Gonzalo >> >> >> This communication is confidential and intended solely for the >> addressee(s). Any unauthorized review, use, disclosure or distribution >> is prohibited. If you believe this message has been sent to you in >> error, please notify the sender by replying to this transmission and >> delete the message without disclosing it. Thank you. >> >> E-mail including attachments is susceptible to data corruption, >> interruption, unauthorized amendment, tampering and viruses, and we >> only send and receive e-mails on the basis that we are not liable for >> any such corruption, interception, amendment, tampering or viruses or >> any consequences thereof. >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 10:49:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23357 for ; Wed, 25 Feb 2004 10:49:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1HM-0003Zt-GO for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 10:48:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PFmuXK013747 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 10:48:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1HM-0003Ze-9r for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 10:48:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23302 for ; Wed, 25 Feb 2004 10:48:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw1HJ-0006Er-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 10:48:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw1GL-00066l-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 10:47:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw1FY-00060W-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 10:47:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1FW-00030z-Eo; Wed, 25 Feb 2004 10:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1FL-00030b-Ay for sipping@optimus.ietf.org; Wed, 25 Feb 2004 10:46:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23121 for ; Wed, 25 Feb 2004 10:46:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw1FI-0005yY-00 for sipping@ietf.org; Wed, 25 Feb 2004 10:46:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw1EO-0005s9-00 for sipping@ietf.org; Wed, 25 Feb 2004 10:45:53 -0500 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx with esmtp (Exim 4.12) id 1Aw1DT-0005i2-00 for sipping@ietf.org; Wed, 25 Feb 2004 10:44:55 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTN00HLJD21RF@firewall.mci.com> for sipping@ietf.org; Wed, 25 Feb 2004 15:44:25 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTN00M01D20IF@pmismtp02.mcilink.com>; Wed, 25 Feb 2004 15:44:25 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.113.220]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTN00M8CD1U8N@pmismtp02.mcilink.com>; Wed, 25 Feb 2004 15:44:24 +0000 (GMT) Date: Wed, 25 Feb 2004 09:44:18 -0600 From: Alan Johnston Subject: Re: [Sipping] Conferencing for UAs In-reply-to: <403C530E.1070204@ericsson.com> X-Sender: Alan.Johnston@pop.mcit.com To: Gonzalo Camarillo Cc: hisham.khartabil@nokia.com, sipping@ietf.org, oritl@microsoft.com, Miguel.An.Garcia@nokia.com Message-id: <5.2.1.1.0.20040225092901.0288fdb0@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <5.2.1.1.0.20040224084212.02819ef8@pop.mcit.com> <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <5.2.1.1.0.20040224084212.02819ef8@pop.mcit.com> Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 09:47 AM 2/25/2004 +0200, Gonzalo Camarillo wrote: >Hi Alan, > >I understand that my comments come late in the game and that it might be >impossible to change the conferencing framework at this point. In any >event, I do not agree with your statement below: > >>No - this is the problem. You are looking at your single narrow application. > >I believe I am actually looking at a much wider range of applications than >just conferencing. So, to me, the problem is that the conferencing >framework is too focused on a "single narrow application"; conferencing. Gonzalo, If you are saying that some of your exploder services do not have a conferencing component, then I agree. Some of the exploder services seem to just be a "request to fork" to a set of URIs. Others definitely have conferencing semantics. The ones with conferencing semantics, I believe, can be, and should be modeled using the conferencing framework. The problem is that each method seems to have a different set of semantics as to what exploding that method means - INVITE is handled differently from SUBSCRIBE, from MESSAGE. From a high level, exploders may seem to be a consistent set of services. However, as I delve into the details and think about call flows (something absent from any of the exploder drafts), a different story emerges. I think we need to explore exactly the services and call flows that are being envisioned for exploders before proposing major changes to our conferencing framework, which I believe is well understood and documented. >In a conferencing service, there is a single resource created by the >initial INVITE; a conference. That's why the server can use the Contact >header field to send it back to the UAC. If you think of services that >create more than one resource (e.g., an explosion and a conference), the >server may not want to use the same URI for both. Moreover, conceptually, >is is not a good thing to use the same URI to identify both resources. As Paul has pointed out - they are the same resource. Additionally, it is a trivial SIP routing issue to fix this - many proxies do method-based request routing - that would completely solve your problem of sending SUBSCRIBEs to a different UA than the initial request. >So, my main concern is the semantics overload of the Contact header. (We >abused this header when design REGISTER as well, by the way. That's why I >do not want to do it again.) > >In my opinion, the Contact header is the URI where you send subsequent >requests within the dialog. If the server wants to tell the client that a >resource (e.g., a conference) has been created, it can use a different >header to include the URI of such a resource. Note that, if you want both >URIs to be the same (like in the conferencing case), you can do it. > >Contact: sip:1234@a.com;isfocus >Resource: sip:1234@a.com;isfocus > >An entity receiving these headers would use the URI in the Contact header >to send subsequent requests *within* the dialog, and the URI in the other >header to send requests *outside* that dialog (e.g., SUBSCRIBE to the >conference package). No. A GRUU should be used in the Contact, and its routing is valid outside the dialog. >In brief, instead of sticking the conference URI in a Contact header and >label that URI with an isfocus parameter so that the UAC figures what is >going on, I find it more explicit to use a different header. Although, as >I said, I understand that this comment comes late and that may not be >useful at this point. I think much more work is needed before the working group can evaluate the exploders work and see how and if it fits in with existing concepts and approaches. Thanks, Alan Johnston MCI sip:alan@sipstation.com >Thanks, > >Gonzalo > > >This communication is confidential and intended solely for the >addressee(s). Any unauthorized review, use, disclosure or distribution is >prohibited. If you believe this message has been sent to you in error, >please notify the sender by replying to this transmission and delete the >message without disclosing it. Thank you. > >E-mail including attachments is susceptible to data corruption, >interruption, unauthorized amendment, tampering and viruses, and we only >send and receive e-mails on the basis that we are not liable for any such >corruption, interception, amendment, tampering or viruses or any >consequences thereof. > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 11:31:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26915 for ; Wed, 25 Feb 2004 11:31:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1vm-0007E2-DI for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 11:30:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PGUgda027768 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 11:30:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1vm-0007Dn-8y for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 11:30:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26712 for ; Wed, 25 Feb 2004 11:30:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw1vl-0004Xc-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 11:30:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw1sJ-0003og-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 11:27:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw1qy-0003Xj-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 11:25:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aw1fk-0001Fe-3z for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 11:14:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1fc-0005RU-Tf; Wed, 25 Feb 2004 11:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1f2-0005Ny-6s for sipping@optimus.ietf.org; Wed, 25 Feb 2004 11:13:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25640 for ; Wed, 25 Feb 2004 11:13:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw1f1-0002CF-00 for sipping@ietf.org; Wed, 25 Feb 2004 11:13:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw1eB-00022K-00 for sipping@ietf.org; Wed, 25 Feb 2004 11:12:32 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw1cw-0001er-00 for sipping@ietf.org; Wed, 25 Feb 2004 11:11:15 -0500 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1PGAguA017918; Wed, 25 Feb 2004 08:10:42 -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 IAA19299; Wed, 25 Feb 2004 08:10:40 -0800 (PST) Message-Id: <4.3.2.7.2.20040225100120.02583860@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Feb 2004 10:10:43 -0600 To: Gonzalo Camarillo , sipping From: "James M. Polk" Cc: Brian.rosen@marconi.com, ono.kumiko@lab.ntt.co.jp, tachimoto.shinya@lab.ntt.co.jp In-Reply-To: <403C61C1.80102@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sipping] Re: E2M security and location conveyance Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 10:50 AM 2/25/2004 +0200, Gonzalo Camarillo wrote: >Hello, > >in case the authors of the folloing drafts are not in touch yet, I believe >you should have a look at each other's work to make sure that the e2m >security stuff is taking into account the location conveyance >requirements. Specifically, Section 2 of the location conveyance draft >directly talks about e2m security. yep - it appears that if the e2m security allows the hiding of the location information (LI) from a proxy that needs that information in order to properly route the call (to the ERC) - then this is a problem (and inconsistency between the goals of the 2 IDs/efforts). I can imagine a case in which the proxy inserts LI into the message body thinking it knows where the UA is - leaving two LIs in the body (perhaps not labelled with who inserted each) for the ERC to figure out which to trust for that call Do we suggests a special case where the UA trust all proxies in a scenario that the UA understands the new INVITE is to an ERC (via the sos@ indication or some other emergency number dialed on the (hard or soft) phone)? We did have this special case written into the Geopriv Requirements doc (RFC 3693, Section 8.3) with Location Conveyance in mind. comments >http://www.ietf.org/internet-drafts/draft-ietf-sipping-e2m-sec-reqs-01.txt > >http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirements-00.txt > >Thanks, > >Gonzalo > > >This communication is confidential and intended solely for the >addressee(s). Any unauthorized review, use, disclosure or distribution is >prohibited. If you believe this message has been sent to you in error, >please notify the sender by replying to this transmission and delete the >message without disclosing it. Thank you. > >E-mail including attachments is susceptible to data corruption, >interruption, unauthorized amendment, tampering and viruses, and we only >send and receive e-mails on the basis that we are not liable for any such >corruption, interception, amendment, tampering or viruses or any >consequences thereof. > cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 12:04:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29926 for ; Wed, 25 Feb 2004 12:04:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw2SQ-0002Ky-P4 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 12:04:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PH4Q2P008983 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 12:04:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw2SQ-0002Ko-GI for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 12:04:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29880 for ; Wed, 25 Feb 2004 12:04:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw2SP-0001SG-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 12:04:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw2RL-0001Hm-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 12:03:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw2QQ-00018E-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 12:02:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw2PR-0001kr-VD; Wed, 25 Feb 2004 12:01:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw2P1-0001Wt-KE for sipping@optimus.ietf.org; Wed, 25 Feb 2004 12:00:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29561 for ; Wed, 25 Feb 2004 12:00:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw2P0-0000uL-00 for sipping@ietf.org; Wed, 25 Feb 2004 12:00:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw2O2-0000mG-00 for sipping@ietf.org; Wed, 25 Feb 2004 11:59:55 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw2N5-0000WI-00 for sipping@ietf.org; Wed, 25 Feb 2004 11:58:55 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Feb 2004 09:08:43 +0000 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 i1PGwK4W025370; Wed, 25 Feb 2004 08:58:22 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQP92456; Wed, 25 Feb 2004 08:58:19 -0800 (PST) In-Reply-To: <403A889F.4010601@cs.columbia.edu> References: <4039FEAD.5070708@ericsson.com> <403A01BD.7080905@cs.columbia.edu> <403A250F.9B29CE10@pingtel.com> <403A889F.4010601@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3BC0604F-671F-11D8-8A69-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: Gonzalo Camarillo , sipping , Rohan Mahy , "Daniel G. Petrie" From: Rohan Mahy Subject: Re: [Sipping] Config framework Date: Tue, 24 Feb 2004 15:14:45 -0800 To: Henning Schulzrinne X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_06_12 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Feb 23, 2004, at 3:11 PM, Henning Schulzrinne wrote: > >> This is certainly not the intension. The draft specifies a way to >> separately >> subscribe for device or user profile data. I would be happy to >> clarify this >> where you think the draft is vague or implies this restriction. > >> Section 3.2 describes parameters that are device specific as even in >> the >> ideal world, purely user specific data may need to consider the UA >> implementation that it is to be applied to. Section 3.2 also >> specifies a >> means to indicate the desire for user or device data. >> Section 3.13 specifies how to form the SUBSCRIBE URI based upon >> the interest for either a device or user profile. > > 3.13 and 4.1 don't really spell out that user (as opposed to device) > data may need to go elsewhere. It only has a single set of steps that > aborts as soon as (say) DHCP-based discovery succeeds. > > I think the two modes, user and device, are somewhat dissimilar. For > device, I may need to combine local information (e.g., information > about outbound proxies and local dialplans) with home information > (local dialplan, device-specific UI configuration, etc.). Henning, You are presenting an extremely rigid and limited view of what constitutes local vs. home information. There is certainly a need for *specific implementations* to sort various parameters into what they will allow to be configured in each instance, but you will certainly not gain consensus on this list that the things listed above are one of the other. Case in point, there are valid reasons why outbound proxy should be set via discovery, device, and user. Likewise, in a thread on emergency services, we discussed why local dialplan (sos numbers) can be based on where you are OR who you are, but not both simultaneously. > For user configuration, I probably need to assume that the device has > an AOR, either initially or discovered via device configuration, which > is realistic for laptops and other personal devices. no, you don't need to assume that at all. If you have an AOR, feel free to use it. If you don't, but you can discover one, you should also feel free to do so. > 4.1 does not seem to spell out what to do if either the device or the > user knows the AOR, but wants to get the remainder of the device and > user configuration automatically. > > Thus, I'd suggest separating the two discovery models and possibly > logically separating user configuration as being derived (among other > sources of AORs) from the device configuration, as in: > > DHCP -> device configuration query -> AOR -> user-based query > > > >> These 3 important concepts are intended to be supported in >> draft-ietf-sipping-config-framework-02. It is however difficult in >> practice to keep these three things separate. In many environments >> it is easier to keep two of the three separate. >> For example: >> In an enterprise with physical devices that do not move much, it >> becomes >> easier to combine the properties of 1 related to location with the >> properties >> of 3. > > I'd rather be more general; if the user configuration spans multiple > devices, it's a lot cleaner if I only have to update one server rather > than each device-based server. (Device-based servers may well be more > local than user-based servers.) > > >> When a user does not know their AOR or does not want to have to >> provide >> it to the UA (to provide a plug and play experience), the user's AOR >> can be >> associated with 3 (the device). 2 is may then be subscribe >> implicitly or explicitly. > > In my two-stage model, this is supported. I don't think you have really articulated what constitutes your 2-stage model. Can you elaborate please? > >> I think that this illustrates a very good point that the separation >> between >> user and device profile data cannot be made concrete. Data such as >> out bound proxy, or policy may be dictated by any or all of the 3 >> realms defined above. Only the application and local administrative >> policies can determine the realm to which data should be associated. >> In addition it may be desirable to override some of the user or device >> profile data based upon other local discovery data (e.g. DHCP options >> for out bound proxy, STUN for NAT traversal). > > There may well be information that could be considered both, but in my > book, user-based configuration is independent of where I plug in my > device and does not depend on the device itself. Thus, an outbound > proxy and related transport parameters are clearly device-related, > while speed dial functionality, media preferences, home dial plans and > buddy lists are probably not. I can present a counter-example for each of your examples. For example, I can have an outbound proxy that records my call history independent of my device. Speed dial functionality is not completely device independent as I may render speed dials for example using soft buttons on some devices, and as sequences of digits on another. Finally media preferences depend intimately on the capabilities of my device. > Some parameters may be hierarchical, in that local network > configuration overrides my general configuration. If my visited > network doesn't allow video, that takes precedence over my user > configuration that prefers video calls. > > >> At best we can define a precedence by which the device data >> can be overridden by user data (or the other way around) >> along with the ability for administrators to dictate policy (perhaps >> indicated >> in the profile data) over what can be overridden. > > I agree. I think we'll have both directions of override. For example, > a CIA agent user configuration may mandate use of TLS and AES > encryption and accept that a call will fail in some local environments > that don't allow this. > > Having a sample set of configuration parameters that we can work > through might test our assumptions. > draft-stredicke-sipping-ep-config-00.txt seems to be the last one on > this topic, or is there something else? > > It unfortunately conflates local parameters (e.g., outbound proxy, > 3.1.4.3) with user-based parameters (registration period, 3.1.4.1). again, your case for local vs. user parameters is very thin. you may want to reconsider if your taxonomy if real or just an artifact of the fact that these things were divided in the past. thanks, -rohan > > Henning > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 12:33:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01734 for ; Wed, 25 Feb 2004 12:33:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw2u5-0004Sr-4e for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 12:33:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PHX1Kv017155 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 12:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw2u4-0004Sc-VQ for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 12:33:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01706 for ; Wed, 25 Feb 2004 12:32:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw2u3-0004Zn-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 12:32:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw2t5-0004UD-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 12:32:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw2sE-0004OS-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 12:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw2sA-0004FU-AX; Wed, 25 Feb 2004 12:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw2rH-0004Dq-Tc for sipping@optimus.ietf.org; Wed, 25 Feb 2004 12:30:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01538 for ; Wed, 25 Feb 2004 12:30:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw2rG-0004Ga-00 for sipping@ietf.org; Wed, 25 Feb 2004 12:30:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw2qC-0004AU-00 for sipping@ietf.org; Wed, 25 Feb 2004 12:29:01 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw2px-00045Y-00 for sipping@ietf.org; Wed, 25 Feb 2004 12:28:45 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 25 Feb 2004 09:39:16 +0000 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 i1PHSB4W000498; Wed, 25 Feb 2004 09:28:13 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQP95869; Wed, 25 Feb 2004 09:28:10 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <139BEDC7-67B8-11D8-B826-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , "sipping" From: Rohan Mahy Subject: Re: [Sipping] updated dialog package Date: Wed, 25 Feb 2004 09:28:50 -0800 To: "Paul Pepper" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Feb 25, 2004, at 7:32 AM, Paul Pepper wrote: > Hi, > > Comments in-line. > > Thanks, > > Paul. > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@cisco.com] >> Sent: Tuesday, February 24, 2004 3:14 AM >> To: Paul Pepper >> Cc: Rohan Mahy; sipping >> Subject: Re: [Sipping] updated dialog package >> >> >> >> On Feb 23, 2004, at 9:40 AM, Paul Pepper wrote: >> >>> Hi, >>> >>> I work for a company that has developed handset gateway devices that >>> enable legacy, digital, business-grade telephones to be driven using >>> SIP. For example, this enables an existing legacy PBX user >>> to retain >>> their telephones and cabling, but to replace the PBX by a >>> Softswitch or >>> IP Centrex system. As most business-grade telephone >>> systems make use >>> of >>> a shared line facility, the addition of a shared line example to the >>> dialog event package ID is of great interest to us, and others who >>> support these types of feature. >>> >>> Although incorporating a shared line example is a step >>> towards a common >>> approach to shared line implementation, I don't believe it goes far >>> enough. Our current implementation of shared lines has >>> shown that the >>> following issues need to be addressed by the spec, and >>> should be shown >>> in the examples: >>> >>> o Line seize, an essential part of any shared line >>> implementation, is >>> not adequately described. When more than one user agent attempts to >>> seize a line at approximately the same instant, a race condition >>> arises. >>> No description of how to handle the race is given - an example >>> application/dialog-info+xml NOTIFY payload is provided, but >>> this alone >>> is inadequate, as message sequencing is an important part >>> of seizing a >>> line. The Line Seize condition will be covered in the >>> "anil-sipping-bla-draft" that Venkatesh refers to. >> >> Line seizure is well beyond what would be appropriate to >> standardize in >> SIPPING because for many types of UAs that concept does not >> even exist. >> I was just trying to demonstrate a non-normative >> description of how it >> could be implemented. How you judge who "wins" a seizure race >> condition >> is an implementation specific issue. In fact, its quite likely that >> different behaviors will be desired by different customers. When >> talking about implementing this at Cisco, we concluded that a >> configuration knob was needed to satisfy essentially opposite >> requirements from two different customers. Each customer was equally >> adamant that he was "right" and the other was "wrong". As a >> result, I >> find it unlikely that SIPPING could come to come to consensus on what >> "proper seizing behavior" is even if we ignored the fact that >> the bulk >> of deployed SIP UAs are software UAs which have no lines to seize. >> > > > Yes, determining which user agents should win seize races is a matter > of > policy, and implementation specific. However, the mechanism used to > convey whether a seize race has been won seems to be a matter for > standardisation (e.g. a non-200 final response to the NOTIFY requesting > the seize could indicate that the seize operation has failed). Now I see what you are getting at. The particular mechanism that you mention is unlikely to go over favorably because it would have the side effect of terminating your subscription. However, I agree it would be useful to have a standard way to convey something like this. I'm not convinced that this belongs in the dialog package, but I'll think about this. >>> o Handling of multiple instances of a shared line has been >>> overlooked. >>> On business-grade PBX systems a line will roughly >>> correspond to an AOR. >>> However, many such systems permit multiple "instances" of a >>> shared line >>> to appear on a single endpoint. For example, a number of >>> instances of a >>> "product support" shared line might appear on all the >>> endpoints of the >>> product support group, thereby allowing multiple calls to >>> be taken and >>> passed around within the group. >> >> This has not been overlooked at all. You can have multiple >> subscriptions (one per AOR), or you can subscribe to a list of AORs >> with the event list extension: >> >> >> http://www.ietf.org/internet-drafts/draft-ietf-simple-event-li >> st-04.txt >> > > I haven't been sufficiently clear on this point. As you point out, each > shared AOR will have its own subscription. Take an example AOR of > support@example. Although a single registration and two subscriptions > (one in each direction, as subscriber and notifier, if a state agent is > used) are used per AOR on each user agent, multiple calls to/from that > AOR may be active at any time. If a user agent has the shared line > capability then all calls to support@example will be presented on it > by, > say, illuminating one button per call. (Of course this is constrained > to > varying degrees by the user agent's display capabilities.) As each > button shows a call to support@example the calls must be presented on > those buttons in a consistent manner across all user agents on the > network. This will allow Harry to put a call to support@example on hold > and verbally tell Thelma which button to press in order to pick that > call up. If all the calls to support@example are presented in an > arbitrary manner on different user agents, then the coherency of call > presentation is lost. This is a problem as coherent call presentation > is > a requirement of existing PBX users, and gives the only meaningful use > for this feature. > > One way of achieving a consistent mapping of calls to buttons (if > buttons are the user interface mechanism used) is to index buttons on > all the user agents. That way, a call can be mapped to the specific > button on all user agents of an installation. I expect that any such index would be conveyed as a target URI parameter using a device ID of some sort. There is agenda time scheduled in SIPPING to discuss Instance ID requirements with the following reading list: draft-stucker-sip-guid-00.txt draft-jennings-sipping-instance-id-00.txt draft-ietf-xmpp-core-22.txt (section 2.3) thanks, -rohan >>> o The mechanism used to convey that a call has been placed on hold >>> appears to rely upon implementation-specific parameters, >>> found in the >>> xml's element. I can't see any reference to >>> definitions of the >>> values used by this element's pname and pval attributes >>> (pname="+activity" pval="noninteractive"), so I assume they're >>> non-standard. >> >> This was due to distraction on my part. I had intended to include a >> discussion of this in the current draft, but somehow left it >> out at 2am >> the day of the draft deadline. I'm terribly sorry about that. I'll >> send out more about the hold issue tomorrow. >> >> thanks, >> -rohan >> >>> Thanks, >>> >>> Paul. >>> >>>> -----Original Message----- >>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>> Sent: Thursday, February 19, 2004 6:00 PM >>>> To: sipping >>>> Cc: rohan@cisco.com >>>> Subject: [Sipping] updated dialog package >>>> >>>> >>>> Hi Everyone, >>>> >>>> I've updated the dialog packages with the changes we agreed to in >>>> Minneapolis (removing CSeq and the Route-Set). >>>> >>>> I've also provided a detailed example of using the dialog >>>> package for a >>>> "shared-line" application. I apologize for my tardiness >>>> here. I was >>>> supposed to post something shortly after the meeting. I >>>> any case, I >>>> believe this demonstrates that the current syntax is at least >>>> sufficient for the use cases we've discussed. I would like to hear >>>> from all of you if this does the trick. >>>> >>>> many thanks, >>>> -rohan >>>> >>>> >>>> _______________________________________________ >>>> Sipping mailing list >>>> https://www1.ietf.org/mailman/listinfo/sipping >>>> This list >>>> is for NEW development of the application of SIP >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sip@ietf.org for new developments of core SIP >>>> >> >> _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 13:14:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03602 for ; Wed, 25 Feb 2004 13:14:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw3Xg-0008FZ-8B for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 13:13:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PIDuXF031707 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 13:13:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw3Xg-0008FK-4E for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 13:13:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03575 for ; Wed, 25 Feb 2004 13:13:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw3Xd-0001B6-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 13:13:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw3Wm-00015u-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 13:13:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw3Vu-000119-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 13:12:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw3Vp-00084j-Ef; Wed, 25 Feb 2004 13:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw3Vm-00084N-IF for sipping@optimus.ietf.org; Wed, 25 Feb 2004 13:11:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03525 for ; Wed, 25 Feb 2004 13:11:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw3Vk-000100-00 for sipping@ietf.org; Wed, 25 Feb 2004 13:11:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw3Ur-0000vg-00 for sipping@ietf.org; Wed, 25 Feb 2004 13:11:01 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw3U2-0000lr-00 for sipping@ietf.org; Wed, 25 Feb 2004 13:10:10 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1PI9auA006328; Wed, 25 Feb 2004 10:09:37 -0800 (PST) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGH83896; Wed, 25 Feb 2004 13:09:35 -0500 (EST) Message-ID: <403CE4DF.8030407@cisco.com> Date: Wed, 25 Feb 2004 13:09:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel.An.Garcia@nokia.com CC: Gonzalo.Camarillo@ericsson.com, hisham.khartabil@nokia.com, sipping@ietf.org, alan.johnston@mci.com, oritl@microsoft.com Subject: Re: [Sipping] Conferencing for UAs References: <357AEC66DB509A4EA46CB85D7968B6AF84E122@esebe006.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Miguel.An.Garcia@nokia.com wrote: >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: 24 February, 2004 19:47 >>To: Gonzalo Camarillo >>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); sipping@ietf.org; >>alan.johnston@mci.com; oritl@microsoft.com; Garcia Miguel.An >>(Nokia-NRC/Helsinki) >>Subject: Re: [Sipping] Conferencing for UAs > > [snap] > >>Taken to extreme, what you suggest would lead to a different >>address for >>OPTIONS, for MESSAGE, for PUBLISH, for REGISTER, etc. And maybe >>different addresses for each kind of subscription. >> >>I don't want to go there. >> >> Paul > > Aren't already there with Caller Preferences? No - I don't see the parallel at all. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 14:51:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08245 for ; Wed, 25 Feb 2004 14:51:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw53c-0008RH-Ng for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 14:51:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PJp0lg032433 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 14:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw53c-0008R2-HB for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 14:51:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08189 for ; Wed, 25 Feb 2004 14:50:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw53Z-0002vL-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 14:50:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw52b-0002oA-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 14:49:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw51i-0002hS-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 14:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw51h-0008B6-Eg; Wed, 25 Feb 2004 14:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw50q-00089w-Bt for sipping@optimus.ietf.org; Wed, 25 Feb 2004 14:48:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08013 for ; Wed, 25 Feb 2004 14:48:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw50n-0002ar-00 for sipping@ietf.org; Wed, 25 Feb 2004 14:48:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4zq-0002U2-00 for sipping@ietf.org; Wed, 25 Feb 2004 14:47:07 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw4z1-0002H4-00 for sipping@ietf.org; Wed, 25 Feb 2004 14:46:15 -0500 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1PJjsNr009289; Wed, 25 Feb 2004 14:45:54 -0500 (EST) Message-ID: <403CFB5C.2080704@dynamicsoft.com> Date: Wed, 25 Feb 2004 14:45:32 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" CC: "'eburger@snowshore.com'" , "'sipping@ietf.org'" Subject: Re: [Fwd: RE: [Sipping] I-D ACTION:draft-ietf-sipping-kpml-02.txt] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christer Holmberg (JO/LMF) wrote: > Hi, > > I guess this is a clarification question on kpml, as well as on gruu > (and functions where gruu is used) in general. > > If you have a node that doesn't register, but eg wants to use kpml (a > gateway, for example), could it generate the gruu on its own, or is > it "mandated" to use the register mechanism? If the register > mechanism is not used, are there any issues which could come up? Use of the registration mechanism is not mandated; the spec says that this is one way, but not the only possible way, to get a gruu. However, no other mechanisms are standardized at this time. Generating your own gruu is probably a bad idea, since it is extremely hard to guarantee that it is indeed globally routable. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 14:54:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08398 for ; Wed, 25 Feb 2004 14:54:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw56V-0000IU-9A for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 14:53:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PJrxg3001136 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 14:53:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw56V-0000IF-5f for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 14:53:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08357 for ; Wed, 25 Feb 2004 14:53:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw56S-0003EA-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 14:53:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw55V-000382-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 14:52:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw54a-00032f-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 14:52:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw54b-0008Vl-TR; Wed, 25 Feb 2004 14:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw53d-0008RM-21 for sipping@optimus.ietf.org; Wed, 25 Feb 2004 14:51:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08192 for ; Wed, 25 Feb 2004 14:50:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw53a-0002vQ-00 for sipping@ietf.org; Wed, 25 Feb 2004 14:50:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw52c-0002oI-00 for sipping@ietf.org; Wed, 25 Feb 2004 14:49:59 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw51j-0002d9-00 for sipping@ietf.org; Wed, 25 Feb 2004 14:49:03 -0500 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1PJmfNr009295; Wed, 25 Feb 2004 14:48:42 -0500 (EST) Message-ID: <403CFC03.4010500@dynamicsoft.com> Date: Wed, 25 Feb 2004 14:48:19 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Miguel.An.Garcia@nokia.com, sipping@ietf.org, alan.johnston@mci.com, oritl@microsoft.com Subject: Re: [Sipping] Re: Conferencing for UAs References: <357AEC66DB509A4EA46CB85D7968B6AF84E117@esebe006.ntc.nokia.com> <403B418A.8020004@ericsson.com> In-Reply-To: <403B418A.8020004@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think the same URI makes sense. At the core, there really is one resource here - the conference. All that differs is the methods that are invoked on it and how that resource behaves when users contact it. Subscribing to it and initiating a session to it are two different methods, but both against fundamentally the same resource. -Jonathan R. Gonzalo Camarillo wrote: > Hi, > >> Aren't we heading to defining a generic Associated-State header with >> a "role" parameter that contains a value "transaction", "conference", >> "xxx", etc... > > > I actually do not care how we encode this information; in a header with > several parameters or in multiple headers (in any case, you may be right > that using a single header could be cleaner). > > What I want to know is whether or not people think that it is worthwhile > keeping separate the URI used for the INVITE dialog and the one (or > ones) used for subscriptions to some piece of state that is associated > somehow with that dialog. My personal opinion is that we should keep > them separate. > > Gonzalo > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any > such corruption, interception, amendment, tampering or viruses or any > consequences thereof. > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 14:58:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08680 for ; Wed, 25 Feb 2004 14:58:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5AN-0001QH-8V for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 14:57:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PJvx6O005463 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 14:57:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5AN-0001Q2-3q for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 14:57:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08564 for ; Wed, 25 Feb 2004 14:57:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5AK-0003eB-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 14:57:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw59M-0003Wa-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 14:56:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw58U-0003Pk-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 14:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw58V-0000tf-Gr; Wed, 25 Feb 2004 14:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw57T-0000av-ND for sipping@optimus.ietf.org; Wed, 25 Feb 2004 14:55:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08418 for ; Wed, 25 Feb 2004 14:54:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw57Q-0003KL-00 for sipping@ietf.org; Wed, 25 Feb 2004 14:54:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw56T-0003ES-00 for sipping@ietf.org; Wed, 25 Feb 2004 14:53:59 -0500 Received: from smtp.sylantro.com ([65.200.90.207]) by ietf-mx with esmtp (Exim 4.12) id 1Aw55a-00034G-00 for sipping@ietf.org; Wed, 25 Feb 2004 14:53:02 -0500 Received: from 10.10.5.1 by smtp.sylantro.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v5.6.0)); Wed, 25 Feb 2004 11:51:09 -0800 X-Server-Uuid: A2273672-8896-48F6-829D-BBF711663783 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] updated dialog package Date: Wed, 25 Feb 2004 11:51:09 -0800 Message-ID: <22ACFCD87A5780449EEBDD6D78BB8DB50C37F7@sylmail1> Thread-Topic: [Sipping] updated dialog package Thread-Index: AcP7xS9OBnQu7fuTRNuzmbe4p8xDTgAEaE0w From: "Venkatesh Venkataramanan" To: "Rohan Mahy" , "Paul Pepper" cc: sipping X-WSS-ID: 6C2223271XC97049-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Also while we are at the topic of being able to reject NOTIFY's without = terminating subscriptions, another useful capability to have would be = for a UA to reject a NOTIFY with a specific response code so that any = NOTIFY's for that dialog alone can be supressed. For example with SLA = there may be UA's in the group that are of varying capabilities. For = example UA1 can have capabilities to display say 2 active dialogs at any = point, while UA2 can have capabilities that permit it to show upto 5 = active dialogs. When both the UA's are subscribed to dialog state, they = receive dialog states of all dialogs. Now, if UA1 had an ability to = respond to a NOTIFY for a third active dialog saying "Dont terminate my = subscriptions; I want to continue getting notifications for all dialogs, = but supress anything for this specific dialog as I have reached my = limits", then it would avoid un-necessary NOTIFY overheads being sent = towards UA1 and it having to accept it and throwing it away; keep track = of what dialogs it has accepted without UI, so that all new NOTIFY's = towards this dialog id are continued to be discarded silently ...... Venkatesh -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Rohan Mahy Sent: Wednesday, February 25, 2004 9:29 AM To: Paul Pepper Cc: Rohan Mahy; sipping Subject: Re: [Sipping] updated dialog package On Feb 25, 2004, at 7:32 AM, Paul Pepper wrote: > Hi, > > Comments in-line. > > Thanks, > > Paul. > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@cisco.com] >> Sent: Tuesday, February 24, 2004 3:14 AM >> To: Paul Pepper >> Cc: Rohan Mahy; sipping >> Subject: Re: [Sipping] updated dialog package >> >> >> >> On Feb 23, 2004, at 9:40 AM, Paul Pepper wrote: >> >>> Hi, >>> >>> I work for a company that has developed handset gateway devices that >>> enable legacy, digital, business-grade telephones to be driven using >>> SIP. For example, this enables an existing legacy PBX user >>> to retain >>> their telephones and cabling, but to replace the PBX by a >>> Softswitch or >>> IP Centrex system. As most business-grade telephone >>> systems make use >>> of >>> a shared line facility, the addition of a shared line example to the >>> dialog event package ID is of great interest to us, and others who >>> support these types of feature. >>> >>> Although incorporating a shared line example is a step >>> towards a common >>> approach to shared line implementation, I don't believe it goes far >>> enough. Our current implementation of shared lines has >>> shown that the >>> following issues need to be addressed by the spec, and >>> should be shown >>> in the examples: >>> >>> o Line seize, an essential part of any shared line >>> implementation, is >>> not adequately described. When more than one user agent attempts to >>> seize a line at approximately the same instant, a race condition >>> arises. >>> No description of how to handle the race is given - an example >>> application/dialog-info+xml NOTIFY payload is provided, but >>> this alone >>> is inadequate, as message sequencing is an important part >>> of seizing a >>> line. The Line Seize condition will be covered in the >>> "anil-sipping-bla-draft" that Venkatesh refers to. >> >> Line seizure is well beyond what would be appropriate to >> standardize in >> SIPPING because for many types of UAs that concept does not >> even exist. >> I was just trying to demonstrate a non-normative >> description of how it >> could be implemented. How you judge who "wins" a seizure race >> condition >> is an implementation specific issue. In fact, its quite likely that >> different behaviors will be desired by different customers. When >> talking about implementing this at Cisco, we concluded that a >> configuration knob was needed to satisfy essentially opposite >> requirements from two different customers. Each customer was equally >> adamant that he was "right" and the other was "wrong". As a >> result, I >> find it unlikely that SIPPING could come to come to consensus on what >> "proper seizing behavior" is even if we ignored the fact that >> the bulk >> of deployed SIP UAs are software UAs which have no lines to seize. >> > > > Yes, determining which user agents should win seize races is a matter=20 > of > policy, and implementation specific. However, the mechanism used to > convey whether a seize race has been won seems to be a matter for > standardisation (e.g. a non-200 final response to the NOTIFY = requesting > the seize could indicate that the seize operation has failed). Now I see what you are getting at. The particular mechanism that you=20 mention is unlikely to go over favorably because it would have the side=20 effect of terminating your subscription. However, I agree it would be=20 useful to have a standard way to convey something like this. I'm not=20 convinced that this belongs in the dialog package, but I'll think about=20 this. >>> o Handling of multiple instances of a shared line has been >>> overlooked. >>> On business-grade PBX systems a line will roughly >>> correspond to an AOR. >>> However, many such systems permit multiple "instances" of a >>> shared line >>> to appear on a single endpoint. For example, a number of >>> instances of a >>> "product support" shared line might appear on all the >>> endpoints of the >>> product support group, thereby allowing multiple calls to >>> be taken and >>> passed around within the group. >> >> This has not been overlooked at all. You can have multiple >> subscriptions (one per AOR), or you can subscribe to a list of AORs >> with the event list extension: >> >> =09 >> http://www.ietf.org/internet-drafts/draft-ietf-simple-event-li >> st-04.txt >> > > I haven't been sufficiently clear on this point. As you point out, = each > shared AOR will have its own subscription. Take an example AOR of > support@example. Although a single registration and two subscriptions > (one in each direction, as subscriber and notifier, if a state agent = is > used) are used per AOR on each user agent, multiple calls to/from that > AOR may be active at any time. If a user agent has the shared line > capability then all calls to support@example will be presented on it=20 > by, > say, illuminating one button per call. (Of course this is constrained=20 > to > varying degrees by the user agent's display capabilities.) As each > button shows a call to support@example the calls must be presented on > those buttons in a consistent manner across all user agents on the > network. This will allow Harry to put a call to support@example on = hold > and verbally tell Thelma which button to press in order to pick that > call up. If all the calls to support@example are presented in an > arbitrary manner on different user agents, then the coherency of call > presentation is lost. This is a problem as coherent call presentation=20 > is > a requirement of existing PBX users, and gives the only meaningful use > for this feature. > > One way of achieving a consistent mapping of calls to buttons (if > buttons are the user interface mechanism used) is to index buttons on > all the user agents. That way, a call can be mapped to the specific > button on all user agents of an installation. I expect that any such index would be conveyed as a target URI=20 parameter using a device ID of some sort. There is agenda time=20 scheduled in SIPPING to discuss Instance ID requirements with the=20 following reading list: draft-stucker-sip-guid-00.txt draft-jennings-sipping-instance-id-00.txt draft-ietf-xmpp-core-22.txt (section 2.3) thanks, -rohan >>> o The mechanism used to convey that a call has been placed on hold >>> appears to rely upon implementation-specific parameters, >>> found in the >>> xml's element. I can't see any reference to >>> definitions of the >>> values used by this element's pname and pval attributes >>> (pname=3D"+activity" pval=3D"noninteractive"), so I assume they're >>> non-standard. >> >> This was due to distraction on my part. I had intended to include a >> discussion of this in the current draft, but somehow left it >> out at 2am >> the day of the draft deadline. I'm terribly sorry about that. I'll >> send out more about the hold issue tomorrow. >> >> thanks, >> -rohan >> >>> Thanks, >>> >>> Paul. >>> >>>> -----Original Message----- >>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>> Sent: Thursday, February 19, 2004 6:00 PM >>>> To: sipping >>>> Cc: rohan@cisco.com >>>> Subject: [Sipping] updated dialog package >>>> >>>> >>>> Hi Everyone, >>>> >>>> I've updated the dialog packages with the changes we agreed to in >>>> Minneapolis (removing CSeq and the Route-Set). >>>> >>>> I've also provided a detailed example of using the dialog >>>> package for a >>>> "shared-line" application. I apologize for my tardiness >>>> here. I was >>>> supposed to post something shortly after the meeting. I >>>> any case, I >>>> believe this demonstrates that the current syntax is at least >>>> sufficient for the use cases we've discussed. I would like to hear >>>> from all of you if this does the trick. >>>> >>>> many thanks, >>>> -rohan >>>> >>>> >>>> _______________________________________________ >>>> Sipping mailing list >>>> https://www1.ietf.org/mailman/listinfo/sipping >>>> This list >>>> is for NEW development of the application of SIP >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sip@ietf.org for new developments of core SIP >>>> >> >> _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 15:07:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09514 for ; Wed, 25 Feb 2004 15:07:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5JM-0007iD-OJ for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 15:07:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PK7GBt029584 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 15:07:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5JL-0007h0-NM for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 15:07:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09463 for ; Wed, 25 Feb 2004 15:07:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5JI-0004ml-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 15:07:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5IF-0004ge-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 15:06:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5HP-0004aW-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 15:05:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5HC-0006cd-Ul; Wed, 25 Feb 2004 15:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5GD-0005pH-Vb for sipping@optimus.ietf.org; Wed, 25 Feb 2004 15:04:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09127 for ; Wed, 25 Feb 2004 15:03:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5GB-0004SK-00 for sipping@ietf.org; Wed, 25 Feb 2004 15:03:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5FG-0004N6-00 for sipping@ietf.org; Wed, 25 Feb 2004 15:03:02 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw5EW-0004BP-00 for sipping@ietf.org; Wed, 25 Feb 2004 15:02:16 -0500 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1PK1fNr009302; Wed, 25 Feb 2004 15:01:42 -0500 (EST) Message-ID: <403CFF0E.5070705@dynamicsoft.com> Date: Wed, 25 Feb 2004 15:01:18 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sipping , Cullen Jennings , bstucker@nortelnetworks.com Subject: Re: [Sipping] UA indentification and HIP References: <403B0C82.20407@ericsson.com> In-Reply-To: <403B0C82.20407@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for the brief intro, Gonzalo. I need to read more on HIP and its on my now-very-length reading list for the plane. Let me anyway ask the main question I have not understood, which is how address resolution is done. So, lets say I want to send a message to a host, and I have obtained its HIT somehow. Presumably I need to translate that to the IP for the host. How is that done? If its DNS, then what is the difference between HIP and just using dynamic DNS and assigning a hostname to each host? Or, is the proposal that a HIT is an address, not a name, in which case routes to it are injected into the IP routing infrastructure. I hope, and assume, that this is not the case, since thats equivalent to a host route for every host on the Internet... egads! -Jonathan R. Gonzalo Camarillo wrote: > Folks, > > the following two drafts describe how to indentify a particular UA using > globally unique identifiers: > > http://www.ietf.org/internet-drafts/draft-stucker-sip-guid-00.txt > http://www.ietf.org/internet-drafts/draft-jennings-sipping-instance-id-00.txt > > > Cullen pointed out that this work may be able to take advantage of the > work carried out in the HIP (Host Identity Protocol) WG, which > supplemental web page is: > > http://hip.piuha.net/ > > Here you have a *very* brief introduction to HIP. I will also be > providing a brief introduction to the drafts above to the HIP community. > Hopefully, we will have a useful exchange of ideas between both WGs. > > HIP consists of a layer between the network and the tranport layers > (e.g., between IP and TCP). It uses HIs (Host Identifiers) to identify > hosts. The idea is that, when a host changes its IP address, it keeps > its HI. This facilitates mobility, for instance. > > HIs (Host Identifiers) are public keys, which may have different lengths > and formats. To resolve this, HIP defines the HITs (Host Identity Tags), > which are hashes of the HI. That is, a HIT is a hash of a public key. > They are 128 bit long, and can be used instead of IPv6 addresses in > socket calls. HIP also defines LSIs (Local Scope Indetifiers), that are > 32 bit long and can be used instead of IPv4 addresses in socket calls. > > Regards, > > Gonzalo > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any > such corruption, interception, amendment, tampering or viruses or any > consequences thereof. > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 15:19:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11045 for ; Wed, 25 Feb 2004 15:19:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5Uj-0004zL-Cc for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 15:19:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PKJ1Bc019163 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 15:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5Uj-0004z0-1Q for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 15:19:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10968 for ; Wed, 25 Feb 2004 15:18:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5Uh-0006Rg-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 15:18:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5Tk-0006Hl-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 15:18:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5Sp-00067e-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 15:17:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5Sn-000433-Jc; Wed, 25 Feb 2004 15:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5Sl-000427-9A for sipping@optimus.ietf.org; Wed, 25 Feb 2004 15:16:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10656 for ; Wed, 25 Feb 2004 15:16:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5Sk-00066l-00 for sipping@ietf.org; Wed, 25 Feb 2004 15:16:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5Rk-0005xo-00 for sipping@ietf.org; Wed, 25 Feb 2004 15:15:57 -0500 Received: from smtp.sylantro.com ([65.200.90.207]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5Qn-0005gU-00 for sipping@ietf.org; Wed, 25 Feb 2004 15:14:57 -0500 Received: from 10.10.5.1 by smtp.sylantro.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v5.6.0)); Wed, 25 Feb 2004 12:13:14 -0800 X-Server-Uuid: A2273672-8896-48F6-829D-BBF711663783 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] updated dialog package Date: Wed, 25 Feb 2004 12:13:14 -0800 Message-ID: <22ACFCD87A5780449EEBDD6D78BB8DB50C37F8@sylmail1> Thread-Topic: [Sipping] updated dialog package Thread-Index: AcP6gWUBWO+pow0US0qFoRgQ3cb/aABV3OTQ From: "Venkatesh Venkataramanan" To: "Rohan Mahy" cc: sipping X-WSS-ID: 6C23DE501XC97204-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable What I was trying to say is as below: 1. UA1 and UA2 are part of an SLA group. 2. UA3 calls the group.=20 3. UA1 answers the call. 4. UA2 gets a NOTIFY with the payload only containing a dialog id, = version number and the state of the dialog as "confirmed" so that any = pickup can be prevented. 5. UA1 places the call on Hold. 6. UA2 receives a NOTIFY with payload that contains the dialog id; = updated version number, the call-id; local and remote-tags so that UA2 = is free to pick the dialog. 7. UA1 now retrieve the call. What does UA1 send in the new NOTIFY? Same = dialog-id, updated version number but no callid, remote-tag/local-tag? = If yes, does this mean UA2 upon receipt of this dialog state remove any = existing callids/localtag/remote tag values it got in step 6?=20 regards, Venkatesh -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Monday, February 23, 2004 6:55 PM To: Venkatesh Venkataramanan Cc: Rohan Mahy; sipping Subject: Re: [Sipping] updated dialog package Hi, On Feb 23, 2004, at 5:43 AM, Venkatesh Venkataramanan wrote: > Resending the same as my first posting somehow was empty in the=20 > mailing list ! > > From a shared line application perspective: > > There is a piece missing from a implementation perspective for shared=20 > line appearances. > > - Ability to signal Hold. I know there have been a few discussions=20 > in the SIPPING mailing list around this and it there was no conclusion = > about what "hold" actually is ! However, one of the important aspects=20 > of shared lines is the ability to communicate a held call to the other = > parties in the group. Currently the anil-sipping-bla draft uses the=20 > SDP information to help other UA's decide a dialog is transitioning to = > hold and off hold. It would be definitely useful to have the dialog=20 > state express this state to the far end rather than having to send out = > SDP information. I'm sorry. I dropped the ball on this. I was going to propose a new=20 callee-caps style "media feature parameter" called "interactive". I=20 think this satisfies the requirement for what folks are actually=20 interested in for "hold", but I need to send out the proposal tomorrow=20 to verify this with everyone on the list. > For the purpose of SLA, instead of going down defining what is Hold, I = > was wondering if we can create a state/or an attribute in the dialog=20 > state package say "pickable" dialog to indicate the same. I've heard=20 > comments saying a UA can block relevant fields of a dialog whenever it = > wants others to be able to pick or not to pick a dialog, however the=20 > same is not clean why isn't this clean? > and it breaks when say the same UA that put the dialog on Hold,=20 > retrieves the dialog. Nothing in the dialog identifiers have changed. I don't see why this is a problem. Also, if I'm already in a dialog,=20 the implicit filtering of the dialog package prevent me from receiving=20 notifications about state that I already know about directly. Not=20 exactly sure what you mean. In any case, lets take two cases, cooperating and non-cooperating UAs. =20 Cooperating UAs can use the presence or existence of dialog identifiers=20 in notifications that they receive to convey that a call is pickable by=20 them. Non-cooperating UAs that happen to learn the dialog identifiers=20 but aren't authorized, can try to pick calls all they want, but will=20 just get 403 Forbidden responses for their requests. thanks, -rohan > The anil-sipping-bla-draft covers other various aspects of SLA from an = > application implementation perspective with call flow examples. > > regards, > Venkatesh > > -----Original Message----- > From: sipping-admin@ietf.org on behalf of Rohan Mahy > Sent: Thu 2/19/2004 9:59 AM > To: sipping > Cc: rohan@cisco.com > Subject: [Sipping] updated dialog package > =09 > =09 > > Hi Everyone, > > I've updated the dialog packages with the changes we agreed to in > Minneapolis (removing CSeq and the Route-Set). > > I've also provided a detailed example of using the dialog package for = > a > "shared-line" application. I apologize for my tardiness here. I was > supposed to post something shortly after the meeting. I any case, I > believe this demonstrates that the current syntax is at least > sufficient for the use cases we've discussed. I would like to hear > from all of you if this does the trick. > > many thanks, > -rohan > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 15:49:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13567 for ; Wed, 25 Feb 2004 15:49:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5xl-000146-TB for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 15:49:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PKn1ol004091 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 15:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5xl-00013u-MX for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 15:49:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13420 for ; Wed, 25 Feb 2004 15:48:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5xk-0002GZ-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 15:49:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5wl-00028q-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 15:48:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5vv-00023N-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 15:47:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5vr-0000fQ-9q; Wed, 25 Feb 2004 15:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5ux-0000dz-W4 for sipping@optimus.ietf.org; Wed, 25 Feb 2004 15:46:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13146 for ; Wed, 25 Feb 2004 15:46:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5uw-0001v3-00 for sipping@ietf.org; Wed, 25 Feb 2004 15:46:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5ty-0001ms-00 for sipping@ietf.org; Wed, 25 Feb 2004 15:45:07 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw5t3-0001b3-00 for sipping@ietf.org; Wed, 25 Feb 2004 15:44:09 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Feb 2004 12:54:00 +0000 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 i1PKhb4U001723; Wed, 25 Feb 2004 12:43:37 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQQ23352; Wed, 25 Feb 2004 12:43:30 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5CE55010-67D3-11D8-B826-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: Rohan Mahy From: Rohan Mahy Date: Wed, 25 Feb 2004 12:44:10 -0800 To: sipping X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Subject: [Sipping] Attention SIPPING authors Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Folks, If you are writing a draft using the xml2rfc tool, please make sure that the following line appears just after the line which begins if you don't do this, the tool will generate each top-level section on its own page, so you end up wasting a whole page to print for example: 11. IANA Considerations This document requires no action by IANA. many thanks for saving trees, etc.. and making my reading list lighter (at least by weight). thanks, -rohan _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 16:07:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14590 for ; Wed, 25 Feb 2004 16:07:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw6FE-0002bd-Jm for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 16:07:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PL74ql010011 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 16:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw6FD-0002bO-Rc for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 16:07:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14531 for ; Wed, 25 Feb 2004 16:07:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw6FC-0004Oi-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 16:07:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw6EG-0004Ik-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 16:06:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw6DK-0004DH-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 16:05:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw6DH-0002JD-K7; Wed, 25 Feb 2004 16:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw6CS-0002Fq-DG for sipping@optimus.ietf.org; Wed, 25 Feb 2004 16:04:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14484 for ; Wed, 25 Feb 2004 16:04:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw6CQ-00047E-00 for sipping@ietf.org; Wed, 25 Feb 2004 16:04:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw6BU-00041V-00 for sipping@ietf.org; Wed, 25 Feb 2004 16:03:13 -0500 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by ietf-mx with esmtp (Exim 4.12) id 1Aw6Ah-0003vz-00 for sipping@ietf.org; Wed, 25 Feb 2004 16:02:23 -0500 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i1PL2McD096578; Wed, 25 Feb 2004 16:02:22 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i1PL2Gws098875; Wed, 25 Feb 2004 16:02:16 -0500 (EST) Received: from bell-labs.com (volker-hopc [135.180.240.186]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i1PL2Fi0029440; Wed, 25 Feb 2004 16:02:15 -0500 (EST) Message-ID: <403D0CFD.90007@bell-labs.com> Date: Wed, 25 Feb 2004 16:00:45 -0500 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Kumiko Ono CC: Gonzalo Camarillo , sipping , tachimoto.shinya@lab.ntt.co.jp Subject: Re: [Sipping] Re: E2M security solution References: <6AC3FA9A0545F4ono.kumiko@lab.ntt.co.jp> <7EC3FB82BA6357ono.kumiko@lab.ntt.co.jp> <403C6DA1.5020008@ericsson.com> In-Reply-To: <403C6DA1.5020008@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kumiko, > >> I have a question about security of the MIO. Let's consider for >> firewall control located with a proxy. The MIO header that you propose >> contains parts of SDP information. When UAs encrypt SDP for end-to-end >> in order to conceal IP addresses and port numbers, does the MIO also >> contain the same information to need to use e2e encryption? > > the idea is that you place in these headers only the information that > the proxy needs. That is, the information that the UAC wants to disclose > to the proxy. Right now, if the UAC chooses to disclose some information > to a particular proxy, it has to disclose it to every proxy in the > path... this may not always be desirable. This is where e2m security > comes into the scene. > Yes, I fully agree with Gonzalo. The two drafts should probably be aligned so that e2m security can be used in conjunction with session policies. A related question might be "m2e" security: in some scenarios, a proxy may not want to disclose policies to other proxies. I would assume that the proxy could use the keys of the recipient (UAS/UAC) to encrypt these policies. However, it might not have these keys handy. Would it make sense to use the e2m infrastructure to also *encrypt* information inserted by a proxy? This of course also raises the question whether a proxy may only insert headers, or if it can be enabled to add bodies to a SIP message (e.g. to a multipart/mime body). This would probably require the definition of a new mechanism for adding bodies. Thanks, Volker -- Volker Hilt Bell Labs / Lucent Technologies phone: +1 732 332 6432 101 Crawfords Corner Rd email: volkerh@bell-labs.com Holmdel, NJ 07733 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 16:11:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14748 for ; Wed, 25 Feb 2004 16:11:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw6J3-0003B0-Db for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 16:11:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PLB1w2012204 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 16:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw6J3-0003Aj-1h for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 16:11:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14711 for ; Wed, 25 Feb 2004 16:10:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw6J1-0004ms-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 16:10:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw6I4-0004gW-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 16:10:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw6H7-0004ap-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 16:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw6H7-0002vb-V5; Wed, 25 Feb 2004 16:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw6GG-0002rj-6Y for sipping@optimus.ietf.org; Wed, 25 Feb 2004 16:08:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14630 for ; Wed, 25 Feb 2004 16:08:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw6GE-0004Vr-00 for sipping@ietf.org; Wed, 25 Feb 2004 16:08:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw6FO-0004Qk-00 for sipping@ietf.org; Wed, 25 Feb 2004 16:07:15 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Aw6EY-0004KT-00 for sipping@ietf.org; Wed, 25 Feb 2004 16:06:22 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1PL6LqY000865 for ; Wed, 25 Feb 2004 22:06:21 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 22:06:21 +0100 Received: from ericsson.com (rvi2-92-155.sw.ericsson.se [153.88.92.155]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSMBS4JS; Wed, 25 Feb 2004 22:06:21 +0100 Message-ID: <403D0E4B.8000107@ericsson.com> Date: Wed, 25 Feb 2004 23:06:19 +0200 X-Sybari-Trust: d54dc7c3 c77f3eb6 7fbf6078 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sipping , Cullen Jennings , bstucker@nortelnetworks.com Subject: Re: [Sipping] UA indentification and HIP References: <403B0C82.20407@ericsson.com> <403CFF0E.5070705@dynamicsoft.com> In-Reply-To: <403CFF0E.5070705@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 21:06:21.0738 (UTC) FILETIME=[384F60A0:01C3FBE3] Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan, > Thanks for the brief intro, Gonzalo. I need to read more on HIP and its > on my now-very-length reading list for the plane. You can find the drafts at http://hip.piuha.net If you want some extra slideware, drop me a private note. > Let me anyway ask the main question I have not understood, which is how > address resolution is done. So, lets say I want to send a message to a > host, and I have obtained its HIT somehow. Presumably I need to > translate that to the IP for the host. How is that done? We have a working group and a research group. The working group focuses on short-term stuff, while the research group focuses on long-term stuff. In the WG, the idea is that you get the FQDN of the remote host and perform a DNS lookup. You will get a HIT and a bunch of IP addresses. The kernel stores the mapping between the HIT and the IP addresses and passes the HIT to the application. The application uses the HIT to perform socket calls. When a socket is created, the kernel uses the mapping it stored before to send IP packets to one of the IP addresses of the remote host. That is, standard IP routing is used. The first exchange between the host consists of a four-way handshake. which includes a DH key exchange. Afterwards, mobility is handled by HIP messages between the hosts, and traffic is protected using IPSec. So, once you perform the initial handshake, the only situation where you would need to map a HIT to a new IP address would be if both hosts move simultaneously and their connectivity is lost. > If its DNS, > then what is the difference between HIP and just using dynamic DNS and > assigning a hostname to each host? For the initial discovery and for the simultaneous move of both hosts, both mechanisms would be identical regarding remote IP address discovery. Still, HIP provides you additional features because host identifiers are cryptographycally generated. This is somehow similar to the SEND (secure neighbor discovery) approach to address ownership (i.e., CGAs; cryptographically generated addresses). HIP handles mobility as well. That much about the WG. The research group will be working on a more complex rendezvous mechanism which includes, for instance, HIP to non-HIP scenarios. Rendezvous servers will take care of mapping between HITs and IP addresses... but this is still research, rather than engineering. > Or, is the proposal that a HIT is an address, not a name, in which case > routes to it are injected into the IP routing infrastructure. I hope, > and assume, that this is not the case, since thats equivalent to a host > route for every host on the Internet... egads! No, HITs are not routable. HIP messages use IP addresses, and once the HIP exchange is finished, the IPSec packets carry IP addresses as well. Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 16:59:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17679 for ; Wed, 25 Feb 2004 16:59:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw73b-0006v7-DR for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 16:59:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PLx7pN026595 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 16:59:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw73b-0006us-8v for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 16:59:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17662 for ; Wed, 25 Feb 2004 16:59:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw73Y-0002Ry-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 16:59:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw72Z-0002L4-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 16:58:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw71d-0002B8-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 16:57:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw71a-0006hH-EG; Wed, 25 Feb 2004 16:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw70j-0006c8-Go for sipping@optimus.ietf.org; Wed, 25 Feb 2004 16:56:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17368 for ; Wed, 25 Feb 2004 16:56:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw70h-00022F-00 for sipping@ietf.org; Wed, 25 Feb 2004 16:56:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw6zl-0001v3-00 for sipping@ietf.org; Wed, 25 Feb 2004 16:55:10 -0500 Received: from mail3.pi.se ([195.7.64.137] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Aw6z3-0001pj-00 for sipping@ietf.org; Wed, 25 Feb 2004 16:54:25 -0500 Received: from vit (h161n2fls31o265.telia.com [217.208.189.161]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id i1PLqGUi017399; Wed, 25 Feb 2004 22:52:23 +0100 (CET) From: "Gunnar Hellstrom" To: "A vWijk" , , Cc: , , , , Subject: RE: Betr.: [Sipping] ToIP Requirements Date: Wed, 25 Feb 2004 22:54:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think PSTN textphone gateway invocation is one area where we either need protocol extensions, or need agreements on what current mechanisms to use. Another is invocation of various kinds of relay services or translation services. A third is calling emergency services and reach positions capable of handling the type of communication that the user prefers. Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of A vWijk Sent: Tuesday, February 24, 2004 1:22 PM To: Gonzalo.Camarillo@ericsson.com; sipping@ietf.org Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; henry.sinnreich@mci.com; gunnar.hellstrom@omnitor.se; paulej@packetizer.com; gv@trace.wisc.edu Subject: Betr.: [Sipping] ToIP Requirements Hello Gonzalo, While there are device requirements in the text. Those requirements and the explanation on the different analogue text telephone systems is included to give the reader an understanding what kind of devices will connect with ToIP. And the need for the text gateways. And what the different behaviour can/may be compared to end to end IP devices. The most important part will be the ToIP framwork and the text gateways and how such gateways will be used and work with the ToIP framework. There is a ToIP framework where a terminal uses streaming text as defined in RFC2793 to connect with any other Interactive texting/real-time streaming text device. This can be end-to-end IP, and a direct T140/RTP stream is established with SIP. But in other cases, a text gateway must be used to allow T.140/RTP to connect with a non IP text telephony device. It can be an analogue text telephone (TDD/TTY) that uses a text gateway to be able to understand RFC2793 text. (PSTN-IP) It can be a mobile phone running GPRS that uses the text gateway to understand RFC2793 text. (this exist right NOW using SIP! And those gateways will be used in mobile networks this year!) Or a mobile text telephone using CTM via the text gateway to communicate with RFC2793 text. Or even one analogue text telephone connecting to another analogue text telephone in a different country, and the PSTN's use IP to connect the call. The question is for example, how do we use that gateway from the IP side? Is it invisible for the IP side? Or do we need special extensions in SIP to that the IP terminal knows it is communicating with the end-device through the text gateway? There may be a slightly different call setup flow when a text gateway is included. Or additional SIP messages indicating gateway activity. When you connect for example to an analogue text telephone with an RFC2793 capable IP terminal the capabilities will be less then IP to IP terminal directly (different transmission speeds, half/full duplex etc). Or what to do with emergency calls that are in RFC 2793 text only? That are requirements that will be defined and worked out in this draft. Also, we want to make everybody in SIP and SIPPING aware about those text gateways. So that complicated matters like how to send analogue text telephone text through a PSTN and connect with a SIP telephone using RFC2793 interactive texting. When using the text gateway, there is then no need for RFC 2833 events at the PSTN for text telephones. So, yes. I believe that this should be in the SIPPING WG. And it will fit in the charter - support for hearing-/speech-impaired calling. greetz Arnoud Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 International text telephone: +31735588408 >>> Gonzalo Camarillo 24-02-04 10:21 >>> Hello, the draft below provides a set of requirements for real-time conversations using SIP. http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-toip-01.txt Nevertheless, I have found a lot of device requirements in the text, but I fail to understand which particular protocol requirements we need to fulfill with new protocol extensions. While SIPPING is the right place to handle requirements that will lead to new SIP protocol extensions, SIPPING may not be the right place to deal with device requirements (e.g., text phones MUST have a display of at least 100 characters). Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 17:13:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18435 for ; Wed, 25 Feb 2004 17:13:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7HE-00006a-KY for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 17:13:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PMDCgi000398 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 17:13:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7HE-00006L-Fu for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 17:13:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18400 for ; Wed, 25 Feb 2004 17:13:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7HB-0003vs-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 17:13:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7G7-0003oj-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 17:12:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7F9-0003jL-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 17:11:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7F8-00086S-BY; Wed, 25 Feb 2004 17:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7EA-000840-Ah for sipping@optimus.ietf.org; Wed, 25 Feb 2004 17:10:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18208 for ; Wed, 25 Feb 2004 17:09:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7E8-0003d6-00 for sipping@ietf.org; Wed, 25 Feb 2004 17:10:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7D9-0003Xo-00 for sipping@ietf.org; Wed, 25 Feb 2004 17:09:00 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7CH-0003PI-00 for sipping@ietf.org; Wed, 25 Feb 2004 17:08:05 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCVSDB>; Wed, 25 Feb 2004 17:07:35 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6465@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Gunnar Hellstrom'" , A vWijk , Gonzalo.Camarillo@ericsson.com, sipping@ietf.org Cc: rrroy@att.com, barry.dingle@bigfoot.com.au, henry.sinnreich@mci.com, paulej@packetizer.com, gv@trace.wisc.edu Subject: RE: Betr.: [Sipping] ToIP Requirements Date: Wed, 25 Feb 2004 17:07:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 I'm particularly interested in the last one, emergency calling. Given that you propose an appropriate SDP indicating support for text, do you think there is anything else we need to do to in SIP to make this happen? I don't see anything. I know that the problem of using a legacy TDD device on any kind of adapter is as problematic as current TDD; the call will answered as if it was a voice call, the baudot/whatever tones will be detected, and the operator will look for text. Can't think of any way to make that better. Do note that language preference headers should be set!!! Brian > -----Original Message----- > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > Sent: Wednesday, February 25, 2004 4:54 PM > To: A vWijk; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > paulej@packetizer.com; gv@trace.wisc.edu > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > I think PSTN textphone gateway invocation is one area where > we either need > protocol extensions, or need agreements on what current > mechanisms to use. > > Another is invocation of various kinds of relay services or > translation > services. > > A third is calling emergency services and reach positions capable of > handling the type of communication that the user prefers. > > > > Gunnar > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > -----Original Message----- > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org]On Behalf Of > A vWijk > Sent: Tuesday, February 24, 2004 1:22 PM > To: Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > gunnar.hellstrom@omnitor.se; paulej@packetizer.com; gv@trace.wisc.edu > Subject: Betr.: [Sipping] ToIP Requirements > > > Hello Gonzalo, > While there are device requirements in the text. Those > requirements and the > explanation on the different analogue text telephone systems > is included to > give the reader an understanding what kind of devices will > connect with > ToIP. And the need for the text gateways. And what the > different behaviour > can/may be compared to end to end IP devices. > The most important part will be the ToIP framwork and the > text gateways and > how such gateways will be used and work with the ToIP framework. > > There is a ToIP framework where a terminal uses streaming > text as defined in > RFC2793 to connect with any other Interactive > texting/real-time streaming > text device. > This can be end-to-end IP, and a direct T140/RTP stream is > established with > SIP. But in other cases, a text gateway must be used to allow > T.140/RTP to > connect with a non IP text telephony device. > It can be an analogue text telephone (TDD/TTY) that uses a > text gateway to > be able to understand RFC2793 text. (PSTN-IP) > It can be a mobile phone running GPRS that uses the text gateway to > understand RFC2793 text. (this exist right NOW using SIP! And > those gateways > will be used in mobile networks this year!) > Or a mobile text telephone using CTM via the text gateway to > communicate > with RFC2793 text. > Or even one analogue text telephone connecting to another > analogue text > telephone in a different country, and the PSTN's use IP to > connect the call. > > The question is for example, how do we use that gateway from > the IP side? Is > it invisible for the IP side? Or do we need special > extensions in SIP to > that the IP terminal knows it is communicating with the > end-device through > the text gateway? > There may be a slightly different call setup flow when a text > gateway is > included. > Or additional SIP messages indicating gateway activity. When > you connect for > example to an analogue text telephone with an RFC2793 capable > IP terminal > the capabilities will be less then IP to IP terminal directly > (different > transmission speeds, half/full duplex etc). > Or what to do with emergency calls that are in RFC 2793 text only? > > That are requirements that will be defined and worked out in > this draft. > Also, we want to make everybody in SIP and SIPPING aware > about those text > gateways. So that complicated matters like how to send analogue text > telephone text through a PSTN and connect with a SIP > telephone using RFC2793 > interactive texting. When using the text gateway, there is > then no need for > RFC 2833 events at the PSTN for text telephones. > > So, yes. I believe that this should be in the SIPPING WG. And > it will fit in > the charter - support for hearing-/speech-impaired calling. > > greetz > > Arnoud > > > > Drs. Arnoud A. T. van Wijk > Viataal > Research & Development > Afdeling RDS > Theerestraat 42 > 5271 GD Sint-Michielsgestel > The Netherlands. > Mobile: +31651921948 > International text telephone: +31735588408 > > >>> Gonzalo Camarillo > 24-02-04 10:21 >>> > Hello, > > the draft below provides a set of requirements for real-time > conversations using SIP. > http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-to ip-01.txt Nevertheless, I have found a lot of device requirements in the text, but I fail to understand which particular protocol requirements we need to fulfill with new protocol extensions. While SIPPING is the right place to handle requirements that will lead to new SIP protocol extensions, SIPPING may not be the right place to deal with device requirements (e.g., text phones MUST have a display of at least 100 characters). Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 17:44:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20074 for ; Wed, 25 Feb 2004 17:44:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7l5-0002yo-9J for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 17:44:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PMi3Eq011448 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 17:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7l5-0002yZ-5F for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 17:44:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20027 for ; Wed, 25 Feb 2004 17:43:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7l2-0007KA-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 17:44:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7k4-0007Dv-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 17:43:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7j8-00078O-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 17:42:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7j8-0002hV-8W; Wed, 25 Feb 2004 17:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7iD-0002g5-6d for sipping@optimus.ietf.org; Wed, 25 Feb 2004 17:41:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19871 for ; Wed, 25 Feb 2004 17:41:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7iA-00072W-00 for sipping@ietf.org; Wed, 25 Feb 2004 17:41:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7hG-0006y6-00 for sipping@ietf.org; Wed, 25 Feb 2004 17:40:07 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw7gs-0006tj-00 for sipping@ietf.org; Wed, 25 Feb 2004 17:39:43 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Feb 2004 14:49:34 +0000 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 i1PMcr4Y028799; Wed, 25 Feb 2004 14:39:11 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQQ37281; Wed, 25 Feb 2004 14:38:03 -0800 (PST) In-Reply-To: <22ACFCD87A5780449EEBDD6D78BB8DB50C37F7@sylmail1> References: <22ACFCD87A5780449EEBDD6D78BB8DB50C37F7@sylmail1> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5D883206-67E3-11D8-B826-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: "Paul Pepper" , Rohan Mahy , sipping From: Rohan Mahy Subject: Re: [Sipping] updated dialog package Date: Wed, 25 Feb 2004 14:38:43 -0800 To: "Venkatesh Venkataramanan" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, We can't just redefine the meaning of error responses to a NOTIFY. The behavior is very explicit in RFC3265 and its not package specific. It means "terminate my subscription immediately". What you seem to want to accomplish is a type of filtering. We have requirements for filtering and a proposed mechanism even. I think it would be useful to compare your requirements to that work. However, I am usually fairly skeptical about the value of asking for filtering when it is easy to throw away the information you don't want. Obviously in the case of filtering spam, you want someone upstream to be able to do that, but in many other cases, sending around the filtering rules themselves generates more traffic than the traffic the filter would have removed... thanks, -rohan On Feb 25, 2004, at 11:51 AM, Venkatesh Venkataramanan wrote: > Also while we are at the topic of being able to reject NOTIFY's > without terminating subscriptions, another useful capability to have > would be for a UA to reject a NOTIFY with a specific response code so > that any NOTIFY's for that dialog alone can be supressed. For example > with SLA there may be UA's in the group that are of varying > capabilities. For example UA1 can have capabilities to display say 2 > active dialogs at any point, while UA2 can have capabilities that > permit it to show upto 5 active dialogs. When both the UA's are > subscribed to dialog state, they receive dialog states of all dialogs. > Now, if UA1 had an ability to respond to a NOTIFY for a third active > dialog saying "Dont terminate my subscriptions; I want to continue > getting notifications for all dialogs, but supress anything for this > specific dialog as I have reached my limits", then it would avoid > un-necessary NOTIFY overheads being sent towards UA1 and it having to > accept it and throwing it away; keep track of what dialogs it has > accepted without UI, so that all new NOTIFY's towards this dialog id > are continued to be discarded silently ...... > > Venkatesh > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf > Of > Rohan Mahy > Sent: Wednesday, February 25, 2004 9:29 AM > To: Paul Pepper > Cc: Rohan Mahy; sipping > Subject: Re: [Sipping] updated dialog package > > > > On Feb 25, 2004, at 7:32 AM, Paul Pepper wrote: > >> Hi, >> >> Comments in-line. >> >> Thanks, >> >> Paul. >> >>> -----Original Message----- >>> From: Rohan Mahy [mailto:rohan@cisco.com] >>> Sent: Tuesday, February 24, 2004 3:14 AM >>> To: Paul Pepper >>> Cc: Rohan Mahy; sipping >>> Subject: Re: [Sipping] updated dialog package >>> >>> >>> >>> On Feb 23, 2004, at 9:40 AM, Paul Pepper wrote: >>> >>>> Hi, >>>> >>>> I work for a company that has developed handset gateway devices that >>>> enable legacy, digital, business-grade telephones to be driven using >>>> SIP. For example, this enables an existing legacy PBX user >>>> to retain >>>> their telephones and cabling, but to replace the PBX by a >>>> Softswitch or >>>> IP Centrex system. As most business-grade telephone >>>> systems make use >>>> of >>>> a shared line facility, the addition of a shared line example to the >>>> dialog event package ID is of great interest to us, and others who >>>> support these types of feature. >>>> >>>> Although incorporating a shared line example is a step >>>> towards a common >>>> approach to shared line implementation, I don't believe it goes far >>>> enough. Our current implementation of shared lines has >>>> shown that the >>>> following issues need to be addressed by the spec, and >>>> should be shown >>>> in the examples: >>>> >>>> o Line seize, an essential part of any shared line >>>> implementation, is >>>> not adequately described. When more than one user agent attempts to >>>> seize a line at approximately the same instant, a race condition >>>> arises. >>>> No description of how to handle the race is given - an example >>>> application/dialog-info+xml NOTIFY payload is provided, but >>>> this alone >>>> is inadequate, as message sequencing is an important part >>>> of seizing a >>>> line. The Line Seize condition will be covered in the >>>> "anil-sipping-bla-draft" that Venkatesh refers to. >>> >>> Line seizure is well beyond what would be appropriate to >>> standardize in >>> SIPPING because for many types of UAs that concept does not >>> even exist. >>> I was just trying to demonstrate a non-normative >>> description of how it >>> could be implemented. How you judge who "wins" a seizure race >>> condition >>> is an implementation specific issue. In fact, its quite likely that >>> different behaviors will be desired by different customers. When >>> talking about implementing this at Cisco, we concluded that a >>> configuration knob was needed to satisfy essentially opposite >>> requirements from two different customers. Each customer was equally >>> adamant that he was "right" and the other was "wrong". As a >>> result, I >>> find it unlikely that SIPPING could come to come to consensus on what >>> "proper seizing behavior" is even if we ignored the fact that >>> the bulk >>> of deployed SIP UAs are software UAs which have no lines to seize. >>> >> >> >> Yes, determining which user agents should win seize races is a matter >> of >> policy, and implementation specific. However, the mechanism used to >> convey whether a seize race has been won seems to be a matter for >> standardisation (e.g. a non-200 final response to the NOTIFY >> requesting >> the seize could indicate that the seize operation has failed). > > Now I see what you are getting at. The particular mechanism that you > mention is unlikely to go over favorably because it would have the side > effect of terminating your subscription. However, I agree it would be > useful to have a standard way to convey something like this. I'm not > convinced that this belongs in the dialog package, but I'll think about > this. > > >>>> o Handling of multiple instances of a shared line has been >>>> overlooked. >>>> On business-grade PBX systems a line will roughly >>>> correspond to an AOR. >>>> However, many such systems permit multiple "instances" of a >>>> shared line >>>> to appear on a single endpoint. For example, a number of >>>> instances of a >>>> "product support" shared line might appear on all the >>>> endpoints of the >>>> product support group, thereby allowing multiple calls to >>>> be taken and >>>> passed around within the group. >>> >>> This has not been overlooked at all. You can have multiple >>> subscriptions (one per AOR), or you can subscribe to a list of AORs >>> with the event list extension: >>> >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-simple-event-li >>> st-04.txt >>> >> >> I haven't been sufficiently clear on this point. As you point out, >> each >> shared AOR will have its own subscription. Take an example AOR of >> support@example. Although a single registration and two subscriptions >> (one in each direction, as subscriber and notifier, if a state agent >> is >> used) are used per AOR on each user agent, multiple calls to/from that >> AOR may be active at any time. If a user agent has the shared line >> capability then all calls to support@example will be presented on it >> by, >> say, illuminating one button per call. (Of course this is constrained >> to >> varying degrees by the user agent's display capabilities.) As each >> button shows a call to support@example the calls must be presented on >> those buttons in a consistent manner across all user agents on the >> network. This will allow Harry to put a call to support@example on >> hold >> and verbally tell Thelma which button to press in order to pick that >> call up. If all the calls to support@example are presented in an >> arbitrary manner on different user agents, then the coherency of call >> presentation is lost. This is a problem as coherent call presentation >> is >> a requirement of existing PBX users, and gives the only meaningful use >> for this feature. >> >> One way of achieving a consistent mapping of calls to buttons (if >> buttons are the user interface mechanism used) is to index buttons on >> all the user agents. That way, a call can be mapped to the specific >> button on all user agents of an installation. > > I expect that any such index would be conveyed as a target URI > parameter using a device ID of some sort. There is agenda time > scheduled in SIPPING to discuss Instance ID requirements with the > following reading list: > > draft-stucker-sip-guid-00.txt > draft-jennings-sipping-instance-id-00.txt > draft-ietf-xmpp-core-22.txt (section 2.3) > > thanks, > -rohan > > >>>> o The mechanism used to convey that a call has been placed on hold >>>> appears to rely upon implementation-specific parameters, >>>> found in the >>>> xml's element. I can't see any reference to >>>> definitions of the >>>> values used by this element's pname and pval attributes >>>> (pname="+activity" pval="noninteractive"), so I assume they're >>>> non-standard. >>> >>> This was due to distraction on my part. I had intended to include a >>> discussion of this in the current draft, but somehow left it >>> out at 2am >>> the day of the draft deadline. I'm terribly sorry about that. I'll >>> send out more about the hold issue tomorrow. >>> >>> thanks, >>> -rohan >>> >>>> Thanks, >>>> >>>> Paul. >>>> >>>>> -----Original Message----- >>>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>>> Sent: Thursday, February 19, 2004 6:00 PM >>>>> To: sipping >>>>> Cc: rohan@cisco.com >>>>> Subject: [Sipping] updated dialog package >>>>> >>>>> >>>>> Hi Everyone, >>>>> >>>>> I've updated the dialog packages with the changes we agreed to in >>>>> Minneapolis (removing CSeq and the Route-Set). >>>>> >>>>> I've also provided a detailed example of using the dialog >>>>> package for a >>>>> "shared-line" application. I apologize for my tardiness >>>>> here. I was >>>>> supposed to post something shortly after the meeting. I >>>>> any case, I >>>>> believe this demonstrates that the current syntax is at least >>>>> sufficient for the use cases we've discussed. I would like to hear >>>>> from all of you if this does the trick. >>>>> >>>>> many thanks, >>>>> -rohan >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sipping mailing list >>>>> https://www1.ietf.org/mailman/listinfo/sipping >>>>> This list >>>>> is for NEW development of the application of SIP >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sip@ietf.org for new developments of core SIP >>>>> >>> >>> > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 17:58:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20799 for ; Wed, 25 Feb 2004 17:58:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7ye-0004iv-SJ for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 17:58:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PMw4DG018151 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 17:58:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7ye-0004ig-Nz for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 17:58:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20764 for ; Wed, 25 Feb 2004 17:58:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7yb-00019R-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 17:58:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7xe-00012E-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 17:57:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7wg-0000uj-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 17:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7wg-0004MQ-Hh; Wed, 25 Feb 2004 17:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7vt-0004Ku-DW for sipping@optimus.ietf.org; Wed, 25 Feb 2004 17:55:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20645 for ; Wed, 25 Feb 2004 17:55:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7vq-0000pe-00 for sipping@ietf.org; Wed, 25 Feb 2004 17:55:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7uz-0000kd-00 for sipping@ietf.org; Wed, 25 Feb 2004 17:54:17 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw7uP-0000cv-00 for sipping@ietf.org; Wed, 25 Feb 2004 17:53:41 -0500 Received: from softarmor.com (dhcp195.dfw.dynamicsoft.com [63.110.3.195]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i1PMr0sb029436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2004 16:53:01 -0600 Message-ID: <403D2738.3050105@softarmor.com> Date: Wed, 25 Feb 2004 16:52:40 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Jonathan Rosenberg , sipping , Cullen Jennings , bstucker@nortelnetworks.com Subject: Re: [Sipping] UA indentification and HIP References: <403B0C82.20407@ericsson.com> <403CFF0E.5070705@dynamicsoft.com> <403D0E4B.8000107@ericsson.com> In-Reply-To: <403D0E4B.8000107@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > No, HITs are not routable. HIP messages use IP addresses, and once the > HIP exchange is finished, the IPSec packets carry IP addresses as well The Nifty Thing about this, as I understand it, is that it provides to the application an assurance of identity-binding under IPSEC that can today be provided only by implementing TLS in the application istelf. That's way cool. -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 17:59:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20855 for ; Wed, 25 Feb 2004 17:59:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7zb-0004kl-OO for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 17:59:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PMx35u018265 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 17:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7zb-0004kW-K7 for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 17:59:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20817 for ; Wed, 25 Feb 2004 17:58:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7zY-0001Fl-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 17:59:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7yZ-00019B-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 17:58:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7xc-00011v-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 17:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7xe-0004XN-Jm; Wed, 25 Feb 2004 17:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7wv-0004Vh-WB for sipping@optimus.ietf.org; Wed, 25 Feb 2004 17:56:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20675 for ; Wed, 25 Feb 2004 17:56:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7wt-0000wl-00 for sipping@ietf.org; Wed, 25 Feb 2004 17:56:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7vt-0000qQ-00 for sipping@ietf.org; Wed, 25 Feb 2004 17:55:14 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw7vC-0000hx-00 for sipping@ietf.org; Wed, 25 Feb 2004 17:54:30 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1PMrwuA001466; Wed, 25 Feb 2004 14:53:58 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQQ39336; Wed, 25 Feb 2004 14:53:45 -0800 (PST) In-Reply-To: <22ACFCD87A5780449EEBDD6D78BB8DB50C37F8@sylmail1> References: <22ACFCD87A5780449EEBDD6D78BB8DB50C37F8@sylmail1> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8F27A774-67E5-11D8-B826-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , sipping From: Rohan Mahy Subject: Re: [Sipping] updated dialog package Date: Wed, 25 Feb 2004 14:54:25 -0800 To: "Venkatesh Venkataramanan" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Feb 25, 2004, at 12:13 PM, Venkatesh Venkataramanan wrote: > What I was trying to say is as below: > > 1. UA1 and UA2 are part of an SLA group. > 2. UA3 calls the group. > 3. UA1 answers the call. > 4. UA2 gets a NOTIFY with the payload only containing a dialog id, > version number and the state of the dialog as "confirmed" so that any > pickup can be prevented. it doesn't even have to contain the dialog information. UA2 will also get a CANCEL for the call it receives. > 5. UA1 places the call on Hold. > 6. UA2 receives a NOTIFY with payload that contains the dialog id; > updated version number, the call-id; local and remote-tags so that UA2 > is free to pick the dialog. > 7. UA1 now retrieve the call. What does UA1 send in the new NOTIFY? > Same dialog-id, updated version number but no callid, > remote-tag/local-tag? If yes, does this mean UA2 upon receipt of this > dialog state remove any existing callids/localtag/remote tag values it > got in step 6? sure, if you'd like to filter this information from cooperating UAs. thanks, -rohan > > regards, > Venkatesh > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Monday, February 23, 2004 6:55 PM > To: Venkatesh Venkataramanan > Cc: Rohan Mahy; sipping > Subject: Re: [Sipping] updated dialog package > > > Hi, > > On Feb 23, 2004, at 5:43 AM, Venkatesh Venkataramanan wrote: > >> Resending the same as my first posting somehow was empty in the >> mailing list ! >> >> From a shared line application perspective: >> >> There is a piece missing from a implementation perspective for shared >> line appearances. >> >> - Ability to signal Hold. I know there have been a few discussions >> in the SIPPING mailing list around this and it there was no conclusion >> about what "hold" actually is ! However, one of the important aspects >> of shared lines is the ability to communicate a held call to the other >> parties in the group. Currently the anil-sipping-bla draft uses the >> SDP information to help other UA's decide a dialog is transitioning to >> hold and off hold. It would be definitely useful to have the dialog >> state express this state to the far end rather than having to send out >> SDP information. > > I'm sorry. I dropped the ball on this. I was going to propose a new > callee-caps style "media feature parameter" called "interactive". I > think this satisfies the requirement for what folks are actually > interested in for "hold", but I need to send out the proposal tomorrow > to verify this with everyone on the list. > >> For the purpose of SLA, instead of going down defining what is Hold, I >> was wondering if we can create a state/or an attribute in the dialog >> state package say "pickable" dialog to indicate the same. I've heard >> comments saying a UA can block relevant fields of a dialog whenever it >> wants others to be able to pick or not to pick a dialog, however the >> same is not clean > > why isn't this clean? > >> and it breaks when say the same UA that put the dialog on Hold, >> retrieves the dialog. Nothing in the dialog identifiers have changed. > > I don't see why this is a problem. Also, if I'm already in a dialog, > the implicit filtering of the dialog package prevent me from receiving > notifications about state that I already know about directly. Not > exactly sure what you mean. > > In any case, lets take two cases, cooperating and non-cooperating UAs. > Cooperating UAs can use the presence or existence of dialog identifiers > in notifications that they receive to convey that a call is pickable by > them. Non-cooperating UAs that happen to learn the dialog identifiers > but aren't authorized, can try to pick calls all they want, but will > just get 403 Forbidden responses for their requests. > > thanks, > -rohan > > >> The anil-sipping-bla-draft covers other various aspects of SLA from an >> application implementation perspective with call flow examples. >> >> regards, >> Venkatesh >> >> -----Original Message----- >> From: sipping-admin@ietf.org on behalf of Rohan Mahy >> Sent: Thu 2/19/2004 9:59 AM >> To: sipping >> Cc: rohan@cisco.com >> Subject: [Sipping] updated dialog package >> >> >> >> Hi Everyone, >> >> I've updated the dialog packages with the changes we agreed to in >> Minneapolis (removing CSeq and the Route-Set). >> >> I've also provided a detailed example of using the dialog package for >> a >> "shared-line" application. I apologize for my tardiness here. I was >> supposed to post something shortly after the meeting. I any case, I >> believe this demonstrates that the current syntax is at least >> sufficient for the use cases we've discussed. I would like to hear >> from all of you if this does the trick. >> >> many thanks, >> -rohan >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 18:44:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24030 for ; Wed, 25 Feb 2004 18:44:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw8hJ-0007B1-Mm for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 18:44:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PNiDQ7027584 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 18:44:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw8hJ-0007Ap-GL for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 18:44:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23985 for ; Wed, 25 Feb 2004 18:44:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw8hG-000665-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 18:44:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw8gF-00060L-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 18:43:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw8fK-0005vA-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 18:42:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw8fB-0006vK-F5; Wed, 25 Feb 2004 18:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw8eI-0006tr-JB for sipping@optimus.ietf.org; Wed, 25 Feb 2004 18:41:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23881 for ; Wed, 25 Feb 2004 18:41:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw8eF-0005p1-00 for sipping@ietf.org; Wed, 25 Feb 2004 18:41:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw8dJ-0005ji-00 for sipping@ietf.org; Wed, 25 Feb 2004 18:40:07 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw8cO-0005Zt-00 for sipping@ietf.org; Wed, 25 Feb 2004 18:39:08 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1PNcFq01279; Wed, 25 Feb 2004 15:38:15 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Feb 2004 17:38:14 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF579081@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Volker Hilt'" , Kumiko Ono Cc: Gonzalo Camarillo , sipping , tachimoto.shinya@lab.ntt.co.jp Subject: RE: [Sipping] Re: E2M security solution Date: Wed, 25 Feb 2004 17:38:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FBF8.6FF3C536" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 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. ------_=_NextPart_001_01C3FBF8.6FF3C536 Content-Type: text/plain Volker, Yes, there is also a related m2e (and m2m) security problem that must be solved for the History-Info header and is intended to apply to any information inserted by intermediaries; right now basic requirements are identified in: http://www.ietf.org/internet-drafts/draft-barnes-sipping-sec-inserted-info-0 1.txt (Note, the draft was not revved for IETF-59 as there's been little discussion and I've not had a chance to make much progress). And, yes, this does introduce the need for a mechanism for intermediaries to add message bodies and to secure that information. I does seem that similar security mechanisms could be used for both e2m and m2e. But, this is where we need to dig through some more details. Also, with regards to policy, the document currently leaves whether or not the intermediary is authorized to secure the information as something implicitly associated with providing the service whereby it is adding the information, but we need to decide if we want to explicitly define how Session Policy might be used here, as well. Mary. -----Original Message----- From: Volker Hilt [mailto:volkerh@bell-labs.com] Sent: Wednesday, February 25, 2004 3:01 PM To: Kumiko Ono Cc: Gonzalo Camarillo; sipping; tachimoto.shinya@lab.ntt.co.jp Subject: Re: [Sipping] Re: E2M security solution Kumiko, > >> I have a question about security of the MIO. Let's consider for >> firewall control located with a proxy. The MIO header that you >> propose contains parts of SDP information. When UAs encrypt SDP for >> end-to-end in order to conceal IP addresses and port numbers, does >> the MIO also contain the same information to need to use e2e >> encryption? > > the idea is that you place in these headers only the information that > the proxy needs. That is, the information that the UAC wants to > disclose to the proxy. Right now, if the UAC chooses to disclose some > information to a particular proxy, it has to disclose it to every > proxy in the path... this may not always be desirable. This is where > e2m security comes into the scene. > Yes, I fully agree with Gonzalo. The two drafts should probably be aligned so that e2m security can be used in conjunction with session policies. A related question might be "m2e" security: in some scenarios, a proxy may not want to disclose policies to other proxies. I would assume that the proxy could use the keys of the recipient (UAS/UAC) to encrypt these policies. However, it might not have these keys handy. Would it make sense to use the e2m infrastructure to also *encrypt* information inserted by a proxy? This of course also raises the question whether a proxy may only insert headers, or if it can be enabled to add bodies to a SIP message (e.g. to a multipart/mime body). This would probably require the definition of a new mechanism for adding bodies. Thanks, Volker -- Volker Hilt Bell Labs / Lucent Technologies phone: +1 732 332 6432 101 Crawfords Corner Rd email: volkerh@bell-labs.com Holmdel, NJ 07733 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=_NextPart_001_01C3FBF8.6FF3C536 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] Re: E2M security solution

Volker,

Yes, there is also a related m2e (and m2m) security = problem that must be solved for the History-Info header and is intended = to apply to any information inserted by intermediaries; right now basic = requirements are identified in:

http://www.ietf.org/internet-drafts/draft-barnes-sippi= ng-sec-inserted-info-01.txt
(Note, the draft was not revved for IETF-59 as = there's been little discussion and I've not had a chance to make much = progress).

And, yes, this does introduce the need for a = mechanism for intermediaries to add message bodies and to secure that = information. I does seem that similar security mechanisms could be used = for both e2m and m2e. But, this is where we need to dig through some = more details.

Also, with regards to policy, the document currently = leaves whether or not the intermediary is authorized to secure the = information as something implicitly associated with providing the = service whereby it is adding the information, but we need to decide if = we want to explicitly define how Session Policy might be used here, as = well.

Mary.

-----Original Message-----
From: Volker Hilt [mailto:volkerh@bell-labs.com] =
Sent: Wednesday, February 25, 2004 3:01 PM
To: Kumiko Ono
Cc: Gonzalo Camarillo; sipping; = tachimoto.shinya@lab.ntt.co.jp
Subject: Re: [Sipping] Re: E2M security = solution


Kumiko,
>
>> I have a question about security of the = MIO. Let's consider for
>> firewall control located with a proxy. The = MIO header that you
>> propose contains parts of SDP information. = When UAs encrypt SDP for
>> end-to-end in order to conceal IP addresses = and port numbers, does
>> the MIO also contain the same information = to need to use e2e
>> encryption?
 >
> the idea is that you place in these headers = only the information that
> the proxy needs. That is, the information that = the UAC wants to
> disclose to the proxy. Right now, if the UAC = chooses to disclose some
> information to a particular proxy, it has to = disclose it to every
> proxy in the path... this may not always be = desirable. This is where
> e2m security comes into the scene.
>
Yes, I fully agree with Gonzalo. The two drafts = should probably be
aligned so that e2m security can be used in = conjunction with session
policies.

A related question might be "m2e" security: = in some scenarios, a proxy
may not want to disclose policies to other proxies. = I would assume that
the proxy could use the keys of the recipient = (UAS/UAC) to encrypt these
policies. However, it might not have these keys = handy. Would it make
sense to use the e2m infrastructure to also = *encrypt* information
inserted by a proxy?

This of course also raises the question whether a = proxy may only insert
headers, or if it can be enabled to add bodies to a = SIP message (e.g. to
a multipart/mime body). This would probably require = the definition of a
new mechanism for adding bodies.

Thanks,

Volker

--
Volker = Hilt           &n= bsp;          Bell Labs / = Lucent Technologies
phone: +1 732 332 = 6432           101 = Crawfords Corner Rd
email: volkerh@bell-labs.com     = Holmdel, NJ 07733

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

------_=_NextPart_001_01C3FBF8.6FF3C536-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Feb 25 20:33:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28767 for ; Wed, 25 Feb 2004 20:33:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwAOl-0007tD-Ax for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 20:33:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q1XB2m030321 for sipping-archive@odin.ietf.org; Wed, 25 Feb 2004 20:33:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwAOl-0007sy-6A for sipping-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 20:33:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28727 for ; Wed, 25 Feb 2004 20:33:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwAOi-0001PZ-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 20:33:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwANk-0001J4-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 20:32:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwAMk-0001DI-00 for sipping-web-archive@ietf.org; Wed, 25 Feb 2004 20:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwAMi-0007R4-2T; Wed, 25 Feb 2004 20:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwALu-0007PS-7k for sipping@optimus.ietf.org; Wed, 25 Feb 2004 20:30:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28598 for ; Wed, 25 Feb 2004 20:30:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwALs-00019F-00 for sipping@ietf.org; Wed, 25 Feb 2004 20:30:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwAKw-00014e-00 for sipping@ietf.org; Wed, 25 Feb 2004 20:29:14 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AwAKU-0000zY-00 for sipping@ietf.org; Wed, 25 Feb 2004 20:28:47 -0500 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 i1Q1S91o002014; Wed, 25 Feb 2004 17:28:15 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQQ56312; Wed, 25 Feb 2004 17:28:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0B5DC4F7-67FB-11D8-B826-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Dean Willis , "'Gonzalo Camarillo'" From: Rohan Mahy Date: Wed, 25 Feb 2004 17:28:13 -0800 To: sipping X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Subject: [Sipping] SIPPING WG Reading List PDF now available Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Folks, A single, properly-paginated, suitable for double-sided printing, PDF file of the entire reading list for the SIPPING WGs upcoming meeting is now available on the supplemental website. Links are available from the agenda page: http://www.softarmor.com/sipping/meets/ietf59/agenda.html There are actually 4 PDFs available. You can select from PDFs for A4 or US-Letter paper, and one-page per side or two-pages per side layouts. Enjoy and see many of you in Korea. thanks, -rohan _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 26 02:09:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20489 for ; Thu, 26 Feb 2004 02:09:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFdE-0003H8-Kt for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 02:08:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q78R7i012549 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 02:08:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFdC-0003GB-2Y for sipping-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 02:08:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19671 for ; Thu, 26 Feb 2004 02:08:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwFd8-0000C0-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 02:08:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwFcD-00007T-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 02:07:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwFbp-00002N-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 02:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFbp-0002R8-Bb; Thu, 26 Feb 2004 02:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFbC-00023m-PZ for sipping@optimus.ietf.org; Thu, 26 Feb 2004 02:06:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17151 for ; Thu, 26 Feb 2004 02:06:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwFb9-00000b-00 for sipping@ietf.org; Thu, 26 Feb 2004 02:06:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwFaJ-0007jw-00 for sipping@ietf.org; Thu, 26 Feb 2004 02:05:28 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AwFZR-0007ad-00 for sipping@ietf.org; Thu, 26 Feb 2004 02:04:33 -0500 Received: from dynamicsoft.com ([63.113.46.35]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1Q743Nr009637; Thu, 26 Feb 2004 02:04:03 -0500 (EST) Message-ID: <403D9A4A.4040606@dynamicsoft.com> Date: Thu, 26 Feb 2004 02:03:38 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy CC: sipping , Dean Willis , "'Gonzalo Camarillo'" Subject: Re: [Sipping] SIPPING WG Reading List PDF now available References: <0B5DC4F7-67FB-11D8-B826-0003938AF740@cisco.com> In-Reply-To: <0B5DC4F7-67FB-11D8-B826-0003938AF740@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rohan - Thanks for putting this together! This will prove quite invaluable for the long plane ride. -Jonathan R. Rohan Mahy wrote: > Hi Folks, > > A single, properly-paginated, suitable for double-sided printing, PDF > file of the entire reading list for the SIPPING WGs upcoming meeting is > now available on the supplemental website. Links are available from the > agenda page: > > http://www.softarmor.com/sipping/meets/ietf59/agenda.html > > There are actually 4 PDFs available. You can select from PDFs for A4 or > US-Letter paper, and one-page per side or two-pages per side layouts. > > Enjoy and see many of you in Korea. > thanks, > -rohan > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 26 05:38:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03187 for ; Thu, 26 Feb 2004 05:38:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwItd-0001zC-1S for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 05:37:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QAba5Q007623 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 05:37:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwItc-0001yn-0H for sipping-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 05:37:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03179 for ; Thu, 26 Feb 2004 05:37:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwItY-0004nn-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 05:37:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwIsg-0004io-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 05:36:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwIsA-0004dJ-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 05:36:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIs8-0001h5-TL; Thu, 26 Feb 2004 05:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIrZ-0001er-F4 for sipping@optimus.ietf.org; Thu, 26 Feb 2004 05:35:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03094 for ; Thu, 26 Feb 2004 05:35:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwIrW-0004bC-00 for sipping@ietf.org; Thu, 26 Feb 2004 05:35:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwIqb-0004WU-00 for sipping@ietf.org; Thu, 26 Feb 2004 05:34:29 -0500 Received: from natsmtp00.rzone.de ([81.169.145.165] helo=natsmtp00.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 1AwIq6-0004S1-00 for sipping@ietf.org; Thu, 26 Feb 2004 05:33:58 -0500 Received: from RocknRoll (pD9516312.dip.t-dialin.net [217.81.99.18]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i1QAXg29019645; Thu, 26 Feb 2004 11:33:43 +0100 (MET) From: "Harry Behrens" To: "'Henning Schulzrinne'" , "'Dean Willis'" Cc: "'James M. Polk'" , , "'Rohan Mahy'" , "'Gonzalo Camarillo'" , Subject: AW: [Sipping] SIPPING Agenda, IETF 59 Date: Thu, 26 Feb 2004 11:35:22 +0100 Message-ID: <002001c3fc54$3d81e040$2c00a8c0@RocknRoll> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <403BBDC6.1000004@cs.columbia.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable May I suggest a SIP, AAA and Billing Track? I would assume this to be of interest as we are seeing tremendous growth in the number of companies entering the ITSP market these days. Regards, Harry > -----Urspr=FCngliche Nachricht----- > Von: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]=20 > Im Auftrag von Henning Schulzrinne > Gesendet: Dienstag, 24. Februar 2004 22:11 > An: Dean Willis > Cc: James M. Polk; sipping@ietf.org; Rohan Mahy; Gonzalo=20 > Camarillo; hgxs@cs.columbia.edu > Betreff: Re: [Sipping] SIPPING Agenda, IETF 59 >=20 >=20 > Reversal is fine with me. >=20 > Dean Willis wrote: >=20 > > James M. Polk wrote: > >=20 > >> At 01:02 PM 2/24/2004 -0600, Dean Willis wrote: > >> > >>> Hyperlinked version at:=20 > >>> http://www.softarmor.com/sipping/meets/ietf59/agenda.html > >>> > >>> WEDNESDAY, March 3, 2004, 1300-1500, Crystal 3 > >>> > >>> 1335 SIP Emergency > >>> Henning Schulzrinne > >>> draft-ietf-sipping-sos-00.txt > >>> draft-schulzrinne-sipping-emergency-arch-00.txt > >>> 1345 Location Conveyance Requirements > >>> James Polk > >>> draft-ietf-sipping-location-requirements-00.txt > >> > >> > >> > >> > >> I believe these presentations should be reversed in order=20 > because the > >> main points of discussion in the Location Requirements ID are for=20 > >> Emergency location dealing with call routing by proxies, adding LI=20 > >> (location information) by the proxy (whether or not the UA=20 > inserted it=20 > >> already) and the security of the LI in transit. Discussing these=20 > >> points after the Emer-Arch doc doesn't seem to make much=20 > sense due to=20 > >> potential rehash while the appropriate presenter is not at=20 > the podium=20 > >> (in either direction). > >> > >> comments? > >=20 > >=20 > > Works for me. Henning? > >=20 > > -- > > Dean > >=20 > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sip@ietf.org for new developments of core SIP >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 26 06:11:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04335 for ; Thu, 26 Feb 2004 06:11:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJPd-0005Ay-C1 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 06:10:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QBAfHH019893 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 06:10:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJPd-0005Am-47 for sipping-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 06:10:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04326 for ; Thu, 26 Feb 2004 06:10:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwJPZ-00004V-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 06:10:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwJOh-0007k5-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 06:09:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwJO3-0007cM-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 06:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJO2-0004bv-AN; Thu, 26 Feb 2004 06:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJNh-0004bR-1e for sipping@optimus.ietf.org; Thu, 26 Feb 2004 06:08:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04196 for ; Thu, 26 Feb 2004 06:08:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwJNd-0007YY-00 for sipping@ietf.org; Thu, 26 Feb 2004 06:08:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwJMi-0007R7-00 for sipping@ietf.org; Thu, 26 Feb 2004 06:07:41 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AwJLp-0007L6-00 for sipping@ietf.org; Thu, 26 Feb 2004 06:06:45 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1QB6jqY024816 for ; Thu, 26 Feb 2004 12:06:45 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 12:06:45 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.124]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSLDV8T9; Thu, 26 Feb 2004 12:06:45 +0100 Message-ID: <403DD345.8010607@ericsson.com> Date: Thu, 26 Feb 2004 13:06:45 +0200 X-Sybari-Trust: 6e8f3a90 c77f3eb6 6298249a 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harry Behrens CC: "'Henning Schulzrinne'" , "'Dean Willis'" , "'James M. Polk'" , sipping@ietf.org, "'Rohan Mahy'" , hgxs@cs.columbia.edu Subject: Re: AW: [Sipping] SIPPING Agenda, IETF 59 References: <002001c3fc54$3d81e040$2c00a8c0@RocknRoll> In-Reply-To: <002001c3fc54$3d81e040$2c00a8c0@RocknRoll> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 26 Feb 2004 11:06:45.0925 (UTC) FILETIME=[9F77B550:01C3FC58] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross-ext.wise.edt.ericsson.se id i1QB6jqY024816 Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Harry, do you mean that you would like to request a time slot to present your=20 draft in SIPPING? Gonzalo Harry Behrens wrote: > May I suggest a SIP, AAA and Billing Track? > I would assume this to be of interest as we are seeing tremendous growt= h > in the number of companies entering the ITSP market these days. >=20 > Regards, >=20 > Harry >=20 >=20 >=20 >>-----Urspr=FCngliche Nachricht----- >>Von: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]=20 >>Im Auftrag von Henning Schulzrinne >>Gesendet: Dienstag, 24. Februar 2004 22:11 >>An: Dean Willis >>Cc: James M. Polk; sipping@ietf.org; Rohan Mahy; Gonzalo=20 >>Camarillo; hgxs@cs.columbia.edu >>Betreff: Re: [Sipping] SIPPING Agenda, IETF 59 >> >> >>Reversal is fine with me. >> >>Dean Willis wrote: >> >> >>>James M. Polk wrote: >>> >>> >>>>At 01:02 PM 2/24/2004 -0600, Dean Willis wrote: >>>> >>>> >>>>>Hyperlinked version at:=20 >>>>>http://www.softarmor.com/sipping/meets/ietf59/agenda.html >>>>> >>>>>WEDNESDAY, March 3, 2004, 1300-1500, Crystal 3 >>>>> >>>>>1335 SIP Emergency >>>>> Henning Schulzrinne >>>>> draft-ietf-sipping-sos-00.txt >>>>> draft-schulzrinne-sipping-emergency-arch-00.txt >>>>>1345 Location Conveyance Requirements >>>>> James Polk >>>>> draft-ietf-sipping-location-requirements-00.txt >>>> >>>> >>>> >>>> >>>>I believe these presentations should be reversed in order=20 >> >>because the >> >>>>main points of discussion in the Location Requirements ID are for=20 >>>>Emergency location dealing with call routing by proxies, adding LI=20 >>>>(location information) by the proxy (whether or not the UA=20 >> >>inserted it=20 >> >>>>already) and the security of the LI in transit. Discussing these=20 >>>>points after the Emer-Arch doc doesn't seem to make much=20 >> >>sense due to=20 >> >>>>potential rehash while the appropriate presenter is not at=20 >> >>the podium=20 >> >>>>(in either direction). >>>> >>>>comments? >>> >>> >>>Works for me. Henning? >>> >>>-- >>>Dean >>> >>>_______________________________________________ >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the application of SIP Use=20 >>>sip-implementors@cs.columbia.edu for questions on current sip Use=20 >>>sip@ietf.org for new developments of core SIP >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current=20 >>sip Use sip@ietf.org for new developments of core SIP >=20 >=20 --=20 Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 26 06:12:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04436 for ; Thu, 26 Feb 2004 06:12:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJQs-0005aj-7f for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 06:11:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QBBwPi021487 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 06:11:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJQs-0005aU-3y for sipping-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 06:11:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04408 for ; Thu, 26 Feb 2004 06:11:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwJQo-0000Gl-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 06:11:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwJPn-00007B-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 06:10:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwJOy-0007m5-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 06:10:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJP0-0004zc-Ma; Thu, 26 Feb 2004 06:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJOZ-0004jl-Jb for sipping@optimus.ietf.org; Thu, 26 Feb 2004 06:09:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04259 for ; Thu, 26 Feb 2004 06:09:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwJOV-0007iJ-00 for sipping@ietf.org; Thu, 26 Feb 2004 06:09:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwJNo-0007a5-00 for sipping@ietf.org; Thu, 26 Feb 2004 06:08:49 -0500 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1AwJMt-0007SI-00 for sipping@ietf.org; Thu, 26 Feb 2004 06:07:51 -0500 Received: from solstice (ew-dsl-81-171-14-60.eweka.nl [81.171.14.60]) by smtp.eweka.nl (8.12.9/8.12.9) with ESMTP id i1QBHFrb010078; Thu, 26 Feb 2004 11:17:34 GMT (envelope-from a.vwijk@viataal.nl) Message-Id: <200402261117.i1QBHFrb010078@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Rosen, Brian'" , "'Gunnar Hellstrom'" , , Cc: , , , , Subject: RE: Betr.: [Sipping] ToIP Requirements Date: Thu, 26 Feb 2004 12:07:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <313680C9A886D511A06000204840E1CF070B6465@whq-msgusr-02.pit.comms.marconi.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-index: AcP77IF/S5VQB3npRMOa47M0iAWJfQAaqWWg Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Actually, When using the text gateway, there is no need to detect the TDD/Analogue text telephone tones/signals. That is the job of the text gateway. And for the emergency calling. We have to look closely at this in combination with a text gateway. Possible behaviour/action. And possible action in SIP. Right now I cannot say what has to happen, I must study the emergency calls in depth. But as I see it, using the text gateway, all SIP originating and receiving emergency calls will be possible for any textphone user. Cheers Arnoud Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 International text telephone: +31735588408 -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Rosen, Brian Sent: woensdag 25 februari 2004 23:08 To: 'Gunnar Hellstrom'; A vWijk; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; henry.sinnreich@mci.com; paulej@packetizer.com; gv@trace.wisc.edu Subject: RE: Betr.: [Sipping] ToIP Requirements I'm particularly interested in the last one, emergency calling. Given that you propose an appropriate SDP indicating support for text, do you think there is anything else we need to do to in SIP to make this happen? I don't see anything. I know that the problem of using a legacy TDD device on any kind of adapter is as problematic as current TDD; the call will answered as if it was a voice call, the baudot/whatever tones will be detected, and the operator will look for text. Can't think of any way to make that better. Do note that language preference headers should be set!!! Brian > -----Original Message----- > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > Sent: Wednesday, February 25, 2004 4:54 PM > To: A vWijk; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > paulej@packetizer.com; gv@trace.wisc.edu > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > I think PSTN textphone gateway invocation is one area where > we either need > protocol extensions, or need agreements on what current > mechanisms to use. > > Another is invocation of various kinds of relay services or > translation > services. > > A third is calling emergency services and reach positions capable of > handling the type of communication that the user prefers. > > > > Gunnar > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > -----Original Message----- > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org]On Behalf Of > A vWijk > Sent: Tuesday, February 24, 2004 1:22 PM > To: Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > gunnar.hellstrom@omnitor.se; paulej@packetizer.com; gv@trace.wisc.edu > Subject: Betr.: [Sipping] ToIP Requirements > > > Hello Gonzalo, > While there are device requirements in the text. Those > requirements and the > explanation on the different analogue text telephone systems > is included to > give the reader an understanding what kind of devices will > connect with > ToIP. And the need for the text gateways. And what the > different behaviour > can/may be compared to end to end IP devices. > The most important part will be the ToIP framwork and the > text gateways and > how such gateways will be used and work with the ToIP framework. > > There is a ToIP framework where a terminal uses streaming > text as defined in > RFC2793 to connect with any other Interactive > texting/real-time streaming > text device. > This can be end-to-end IP, and a direct T140/RTP stream is > established with > SIP. But in other cases, a text gateway must be used to allow > T.140/RTP to > connect with a non IP text telephony device. > It can be an analogue text telephone (TDD/TTY) that uses a > text gateway to > be able to understand RFC2793 text. (PSTN-IP) > It can be a mobile phone running GPRS that uses the text gateway to > understand RFC2793 text. (this exist right NOW using SIP! And > those gateways > will be used in mobile networks this year!) > Or a mobile text telephone using CTM via the text gateway to > communicate > with RFC2793 text. > Or even one analogue text telephone connecting to another > analogue text > telephone in a different country, and the PSTN's use IP to > connect the call. > > The question is for example, how do we use that gateway from > the IP side? Is > it invisible for the IP side? Or do we need special > extensions in SIP to > that the IP terminal knows it is communicating with the > end-device through > the text gateway? > There may be a slightly different call setup flow when a text > gateway is > included. > Or additional SIP messages indicating gateway activity. When > you connect for > example to an analogue text telephone with an RFC2793 capable > IP terminal > the capabilities will be less then IP to IP terminal directly > (different > transmission speeds, half/full duplex etc). > Or what to do with emergency calls that are in RFC 2793 text only? > > That are requirements that will be defined and worked out in > this draft. > Also, we want to make everybody in SIP and SIPPING aware > about those text > gateways. So that complicated matters like how to send analogue text > telephone text through a PSTN and connect with a SIP > telephone using RFC2793 > interactive texting. When using the text gateway, there is > then no need for > RFC 2833 events at the PSTN for text telephones. > > So, yes. I believe that this should be in the SIPPING WG. And > it will fit in > the charter - support for hearing-/speech-impaired calling. > > greetz > > Arnoud > > > > Drs. Arnoud A. T. van Wijk > Viataal > Research & Development > Afdeling RDS > Theerestraat 42 > 5271 GD Sint-Michielsgestel > The Netherlands. > Mobile: +31651921948 > International text telephone: +31735588408 > > >>> Gonzalo Camarillo > 24-02-04 10:21 >>> > Hello, > > the draft below provides a set of requirements for real-time > conversations using SIP. > http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-to ip-01.txt Nevertheless, I have found a lot of device requirements in the text, but I fail to understand which particular protocol requirements we need to fulfill with new protocol extensions. While SIPPING is the right place to handle requirements that will lead to new SIP protocol extensions, SIPPING may not be the right place to deal with device requirements (e.g., text phones MUST have a display of at least 100 characters). Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 26 06:26:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05319 for ; Thu, 26 Feb 2004 06:26:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJe7-0006ir-VQ for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 06:25:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QBPdPS025835 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 06:25:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJe7-0006ic-MW for sipping-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 06:25:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05309 for ; Thu, 26 Feb 2004 06:25:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwJe3-000242-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 06:25:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwJdS-0001yk-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 06:24:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwJcV-0001qy-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 06:23:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJcX-0006XW-AQ; Thu, 26 Feb 2004 06:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJcM-0006X2-5O for sipping@optimus.ietf.org; Thu, 26 Feb 2004 06:23:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05143 for ; Thu, 26 Feb 2004 06:23:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwJcI-0001oC-00 for sipping@ietf.org; Thu, 26 Feb 2004 06:23:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwJbW-0001gP-00 for sipping@ietf.org; Thu, 26 Feb 2004 06:22:59 -0500 Received: from natsmtp00.rzone.de ([81.169.145.165] helo=natsmtp00.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 1AwJau-0001YO-00 for sipping@ietf.org; Thu, 26 Feb 2004 06:22:20 -0500 Received: from RocknRoll (pD9516312.dip.t-dialin.net [217.81.99.18]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i1QBLfD1021300; Thu, 26 Feb 2004 12:21:50 +0100 (MET) From: "Harry Behrens" To: "'Gonzalo Camarillo'" Cc: "'Henning Schulzrinne'" , "'Dean Willis'" , "'James M. Polk'" , , "'Rohan Mahy'" , Subject: AW: AW: [Sipping] SIPPING Agenda, IETF 59 Date: Thu, 26 Feb 2004 12:23:14 +0100 Message-ID: <002901c3fc5a$ffabef20$2c00a8c0@RocknRoll> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <403DD345.8010607@ericsson.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable That too. However presenting the latest relevant AAA and Billing related drafts seemed like a good idea in general. It appears to me to be a topic of interest and I am not presumptuous enough to assume that my draft is the only document worthy of attention in that field ;-) So: if such a "track" would exist I would like to reqeust to have one slot allocated to my draft. If however, the notion of such a track is not agreeable I would probably just like to request a slot. Harry > -----Urspr=FCngliche Nachricht----- > Von: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Gesendet: Donnerstag, 26. Februar 2004 12:07 > An: Harry Behrens > Cc: 'Henning Schulzrinne'; 'Dean Willis'; 'James M. Polk';=20 > sipping@ietf.org; 'Rohan Mahy'; hgxs@cs.columbia.edu > Betreff: Re: AW: [Sipping] SIPPING Agenda, IETF 59 >=20 >=20 > Harry, >=20 > do you mean that you would like to request a time slot to=20 > present your=20 > draft in SIPPING? >=20 > Gonzalo >=20 > Harry Behrens wrote: >=20 > > May I suggest a SIP, AAA and Billing Track? > > I would assume this to be of interest as we are seeing tremendous=20 > > growth in the number of companies entering the ITSP market=20 > these days. > >=20 > > Regards, > >=20 > > Harry > >=20 > >=20 > >=20 > >>-----Urspr=FCngliche Nachricht----- > >>Von: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > >>Im Auftrag von Henning Schulzrinne > >>Gesendet: Dienstag, 24. Februar 2004 22:11 > >>An: Dean Willis > >>Cc: James M. Polk; sipping@ietf.org; Rohan Mahy; Gonzalo=20 > >>Camarillo; hgxs@cs.columbia.edu > >>Betreff: Re: [Sipping] SIPPING Agenda, IETF 59 > >> > >> > >>Reversal is fine with me. > >> > >>Dean Willis wrote: > >> > >> > >>>James M. Polk wrote: > >>> > >>> > >>>>At 01:02 PM 2/24/2004 -0600, Dean Willis wrote: > >>>> > >>>> > >>>>>Hyperlinked version at: > >>>>>http://www.softarmor.com/sipping/meets/ietf59/agenda.html > >>>>> > >>>>>WEDNESDAY, March 3, 2004, 1300-1500, Crystal 3 > >>>>> > >>>>>1335 SIP Emergency > >>>>> Henning Schulzrinne > >>>>> draft-ietf-sipping-sos-00.txt > >>>>> draft-schulzrinne-sipping-emergency-arch-00.txt > >>>>>1345 Location Conveyance Requirements > >>>>> James Polk > >>>>> draft-ietf-sipping-location-requirements-00.txt > >>>> > >>>> > >>>> > >>>> > >>>>I believe these presentations should be reversed in order > >> > >>because the > >> > >>>>main points of discussion in the Location Requirements ID are for > >>>>Emergency location dealing with call routing by proxies,=20 > adding LI=20 > >>>>(location information) by the proxy (whether or not the UA=20 > >> > >>inserted it > >> > >>>>already) and the security of the LI in transit. Discussing these > >>>>points after the Emer-Arch doc doesn't seem to make much=20 > >> > >>sense due to > >> > >>>>potential rehash while the appropriate presenter is not at > >> > >>the podium > >> > >>>>(in either direction). > >>>> > >>>>comments? > >>> > >>> > >>>Works for me. Henning? > >>> > >>>-- > >>>Dean > >>> > >>>_______________________________________________ > >>>Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > >>>This list=20 > is for NEW development of the application of SIP Use > >>>sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>>sip@ietf.org for new developments of core SIP > >> > >>_______________________________________________ > >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >>This list is for NEW development of the application of SIP Use=20 > >>sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>sip@ietf.org for new developments of core SIP > >=20 > >=20 >=20 > --=20 > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 26 06:57:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06309 for ; Thu, 26 Feb 2004 06:57:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwK87-00016i-0W for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 06:56:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QBuc0j004254 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 06:56:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwK86-00016X-Qp for sipping-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 06:56:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06299 for ; Thu, 26 Feb 2004 06:56:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwK82-0004o1-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 06:56:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwK79-0004j9-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 06:55:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwK6c-0004eD-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 06:55:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwK6a-0000s3-2U; Thu, 26 Feb 2004 06:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwK6B-0000rO-Qz for sipping@optimus.ietf.org; Thu, 26 Feb 2004 06:54:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06248 for ; Thu, 26 Feb 2004 06:54:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwK67-0004dR-00 for sipping@ietf.org; Thu, 26 Feb 2004 06:54:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwK5C-0004YM-00 for sipping@ietf.org; Thu, 26 Feb 2004 06:53:39 -0500 Received: from www.ctbikersguide.com ([216.37.47.168] helo=seaside.we-host.com) by ietf-mx with esmtp (Exim 4.12) id 1AwK4d-0004RR-00 for sipping@ietf.org; Thu, 26 Feb 2004 06:53:03 -0500 Received: (qmail 6501 invoked from network); 26 Feb 2004 11:52:27 -0000 Received: from ip67-153-22-178.z22-153-67.customer.algx.net (HELO stephenajames) (67.153.22.178) by seaside.we-host.com with SMTP; 26 Feb 2004 11:52:27 -0000 From: "Stephen James" To: "'Dean Willis'" , "'Gonzalo Camarillo'" Cc: "'Jonathan Rosenberg'" , "'sipping'" , "'Cullen Jennings'" , Subject: RE: [Sipping] UA indentification and HIP Date: Thu, 26 Feb 2004 05:52:19 -0600 Message-ID: <000f01c3fc5e$fda6fa90$0500a8c0@internal.voiceramp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <403D2738.3050105@softarmor.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We are kind of drifing off the SIP topic, but what is the prognosis for realizing HIP in the real network? Are we looking at something in terms of months, years, etc. -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Dean Willis Sent: Wednesday, February 25, 2004 4:53 PM To: Gonzalo Camarillo Cc: Jonathan Rosenberg; sipping; Cullen Jennings; bstucker@nortelnetworks.com Subject: Re: [Sipping] UA indentification and HIP Gonzalo Camarillo wrote: > No, HITs are not routable. HIP messages use IP addresses, and once the > HIP exchange is finished, the IPSec packets carry IP addresses as well The Nifty Thing about this, as I understand it, is that it provides to the application an assurance of identity-binding under IPSEC that can today be provided only by implementing TLS in the application istelf. That's way cool. -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 26 07:10:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06982 for ; Thu, 26 Feb 2004 07:10:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKKa-0003JS-Qp for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 07:09:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QC9WiE012728 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 07:09:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKKa-0003JD-N1 for sipping-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 07:09:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06957 for ; Thu, 26 Feb 2004 07:09:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwKKW-00066s-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 07:09:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwKJf-00062M-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 07:08:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwKJ7-0005xb-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 07:08:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKJ8-0002u6-Kc; Thu, 26 Feb 2004 07:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKIb-0002lF-UA for sipping@optimus.ietf.org; Thu, 26 Feb 2004 07:07:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06901 for ; Thu, 26 Feb 2004 07:07:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwKIX-0005uv-00 for sipping@ietf.org; Thu, 26 Feb 2004 07:07:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwKHc-0005pW-00 for sipping@ietf.org; Thu, 26 Feb 2004 07:06:29 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AwKGk-0005in-00 for sipping@ietf.org; Thu, 26 Feb 2004 07:05:34 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1QC5YYG019968 for ; Thu, 26 Feb 2004 13:05:34 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 13:05:33 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.124]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSMBYCQ9; Thu, 26 Feb 2004 13:05:33 +0100 Message-ID: <403DE10D.7060406@ericsson.com> Date: Thu, 26 Feb 2004 14:05:33 +0200 X-Sybari-Trust: 798d1b63 c77f3eb6 6298249a 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen James CC: "'Dean Willis'" , "'Jonathan Rosenberg'" , "'sipping'" , "'Cullen Jennings'" , bstucker@nortelnetworks.com Subject: Re: [Sipping] UA indentification and HIP References: <000f01c3fc5e$fda6fa90$0500a8c0@internal.voiceramp.com> In-Reply-To: <000f01c3fc5e$fda6fa90$0500a8c0@internal.voiceramp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2004 12:05:33.0986 (UTC) FILETIME=[D65B1820:01C3FC60] Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > We are kind of drifing off the SIP topic, but what is the prognosis for > realizing HIP in the real network? Are we looking at something in terms > of months, years, etc. I would like to finish the standardization of the base protocol, the basic redezvous mechanism, the mobility and multi-homing stuff, and some other issues by the end of this year. Regarding deployment, we will probably have early adopters in the following months... we may get a critical mass in around two years... and then, it may become something like SSH, or it may be completely abandoned, or it may be so successful that the whole Internet starts migrating to HIP... The thing with HIP is that it makes a lot of things easier, but we still have not found the killer application that will make HIP a great success. Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 26 07:17:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07239 for ; Thu, 26 Feb 2004 07:17:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKRN-0003zs-45 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 07:16:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QCGXY8015362 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 07:16:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKRM-0003zh-Td for sipping-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 07:16:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07231 for ; Thu, 26 Feb 2004 07:16:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwKRM-0006i5-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 07:16:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwKQN-0006dK-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 07:15:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwKPy-0006ZD-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 07:15:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKPv-0003m4-IQ; Thu, 26 Feb 2004 07:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwKPM-0003lN-9v for sipping@optimus.ietf.org; Thu, 26 Feb 2004 07:14:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07213 for ; Thu, 26 Feb 2004 07:14:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwKPL-0006YW-00 for sipping@ietf.org; Thu, 26 Feb 2004 07:14:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwKOU-0006V0-00 for sipping@ietf.org; Thu, 26 Feb 2004 07:13:35 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AwKNz-0006Qr-00 for sipping@ietf.org; Thu, 26 Feb 2004 07:13:03 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1QCD1YG021760 for ; Thu, 26 Feb 2004 13:13:02 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 13:13:01 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.124]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSLDWP05; Thu, 26 Feb 2004 13:13:01 +0100 Message-ID: <403DE2CD.1060708@ericsson.com> Date: Thu, 26 Feb 2004 14:13:01 +0200 X-Sybari-Trust: 6e1005df c77f3eb6 6298249a 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston CC: hisham.khartabil@nokia.com, sipping@ietf.org, oritl@microsoft.com, Miguel.An.Garcia@nokia.com Subject: Re: [Sipping] Conferencing for UAs References: <5.2.1.1.0.20040224084212.02819ef8@pop.mcit.com> <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <5.2.1.1.0.20040224084212.02819ef8@pop.mcit.com> <5.2.1.1.0.20040225092901.0288fdb0@pop.mcit.com> In-Reply-To: <5.2.1.1.0.20040225092901.0288fdb0@pop.mcit.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2004 12:13:01.0976 (UTC) FILETIME=[E160F180:01C3FC61] Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alan, I agree with you that we do not want to change the conferencing framework at this point in time (I already said in my previous mail that I understood that my comments related to this came too late). Still, I found the discussion useful to understand your point of view. In any event, the topic I am interested in is the creation of different resources (identified by URIs) by a single request. In particular, how to communicate those URIs to the UAC. (I sent separate comments on Hisham's draft.) I hope we can discuss these issues in Korea. Thanks, Gonzalo Alan Johnston wrote: > At 09:47 AM 2/25/2004 +0200, Gonzalo Camarillo wrote: > >> Hi Alan, >> >> I understand that my comments come late in the game and that it might >> be impossible to change the conferencing framework at this point. In >> any event, I do not agree with your statement below: >> >>> No - this is the problem. You are looking at your single narrow >>> application. >> >> >> I believe I am actually looking at a much wider range of applications >> than just conferencing. So, to me, the problem is that the >> conferencing framework is too focused on a "single narrow >> application"; conferencing. > > > Gonzalo, > > If you are saying that some of your exploder services do not have a > conferencing component, then I agree. Some of the exploder services > seem to just be a "request to fork" to a set of URIs. Others definitely > have conferencing semantics. The ones with conferencing semantics, I > believe, can be, and should be modeled using the conferencing framework. > > The problem is that each method seems to have a different set of > semantics as to what exploding that method means - INVITE is handled > differently from SUBSCRIBE, from MESSAGE. From a high level, exploders > may seem to be a consistent set of services. However, as I delve into > the details and think about call flows (something absent from any of > the exploder drafts), a different story emerges. > > I think we need to explore exactly the services and call flows that are > being envisioned for exploders before proposing major changes to our > conferencing framework, which I believe is well understood and documented. > >> In a conferencing service, there is a single resource created by the >> initial INVITE; a conference. That's why the server can use the >> Contact header field to send it back to the UAC. If you think of >> services that create more than one resource (e.g., an explosion and a >> conference), the server may not want to use the same URI for both. >> Moreover, conceptually, is is not a good thing to use the same URI to >> identify both resources. > > > As Paul has pointed out - they are the same resource. Additionally, it > is a trivial SIP routing issue to fix this - many proxies do > method-based request routing - that would completely solve your problem > of sending SUBSCRIBEs to a different UA than the initial request. > >> So, my main concern is the semantics overload of the Contact header. >> (We abused this header when design REGISTER as well, by the way. >> That's why I do not want to do it again.) >> >> In my opinion, the Contact header is the URI where you send subsequent >> requests within the dialog. If the server wants to tell the client >> that a resource (e.g., a conference) has been created, it can use a >> different header to include the URI of such a resource. Note that, if >> you want both URIs to be the same (like in the conferencing case), you >> can do it. >> >> Contact: sip:1234@a.com;isfocus >> Resource: sip:1234@a.com;isfocus >> >> An entity receiving these headers would use the URI in the Contact >> header to send subsequent requests *within* the dialog, and the URI in >> the other header to send requests *outside* that dialog (e.g., >> SUBSCRIBE to the conference package). > > > No. A GRUU should be used in the Contact, and its routing is valid > outside the dialog. > > >> In brief, instead of sticking the conference URI in a Contact header >> and label that URI with an isfocus parameter so that the UAC figures >> what is going on, I find it more explicit to use a different header. >> Although, as I said, I understand that this comment comes late and >> that may not be useful at this point. > > > I think much more work is needed before the working group can evaluate > the exploders work and see how and if it fits in with existing concepts > and approaches. > > Thanks, > Alan Johnston > MCI > sip:alan@sipstation.com > >> Thanks, >> >> Gonzalo >> >> >> This communication is confidential and intended solely for the >> addressee(s). Any unauthorized review, use, disclosure or distribution >> is prohibited. If you believe this message has been sent to you in >> error, please notify the sender by replying to this transmission and >> delete the message without disclosing it. Thank you. >> >> E-mail including attachments is susceptible to data corruption, >> interruption, unauthorized amendment, tampering and viruses, and we >> only send and receive e-mails on the basis that we are not liable for >> any such corruption, interception, amendment, tampering or viruses or >> any consequences thereof. >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 26 09:21:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14427 for ; Thu, 26 Feb 2004 09:21:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMNe-00085c-Kb for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 09:20:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QEKoeo031095 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 09:20:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMNe-00085S-Da for sipping-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 09:20:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14355 for ; Thu, 26 Feb 2004 09:20:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMNc-00066x-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 09:20:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMMQ-0005sB-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 09:19:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwMLu-0005np-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 09:19:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMLu-0007ib-8l; Thu, 26 Feb 2004 09:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMLV-0007hz-4Q for sipping@optimus.ietf.org; Thu, 26 Feb 2004 09:18:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14300 for ; Thu, 26 Feb 2004 09:18:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMLT-0005nJ-00 for sipping@ietf.org; Thu, 26 Feb 2004 09:18:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMKZ-0005jI-00 for sipping@ietf.org; Thu, 26 Feb 2004 09:17:40 -0500 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1AwMJz-0005fF-00 for sipping@ietf.org; Thu, 26 Feb 2004 09:17:03 -0500 Received: from solstice (ew-dsl-81-171-14-60.eweka.nl [81.171.14.60]) by smtp.eweka.nl (8.12.9/8.12.9) with ESMTP id i1QEQlrb011737; Thu, 26 Feb 2004 14:26:53 GMT (envelope-from a.vwijk@viataal.nl) Message-Id: <200402261426.i1QEQlrb011737@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Rosen, Brian'" , "'Gunnar Hellstrom'" , , Cc: , , , , Subject: RE: Betr.: [Sipping] ToIP Requirements Date: Thu, 26 Feb 2004 15:16:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <313680C9A886D511A06000204840E1CF070B6467@whq-msgusr-02.pit.comms.marconi.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-index: AcP8cXuA1W7IsbjCSbeF8JqVosr8HQAAH6Kg Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Brian, That is also why we need to look at the emergency call system. This text gateway is only at the PSTN side, thus another requirement for a T140/RTP gateway for the PSTN is that when a local emergency number is dialled (112, or 911 etc). That the gateway must be able to receive that call (even dropping existing calls if necessary). Such a call is easy to recognize as an emergency call. (PSTN side). From that gateway on, it is all IP with RFC2793 interactive text. And then it is just all existing SIP as if it was from an IP end-point. This gives emergency centers an advantage, all calls will be T.140/RTP, so integration in their computer systems will be easy instead being forced to have analog textphones available for a textphone call. (or a separate text telephone emergency center). /Arnoud Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 International text telephone: +31735588408 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: donderdag 26 februari 2004 15:04 To: 'Arnoud van Wijk'; 'Gunnar Hellstrom'; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; henry.sinnreich@mci.com; paulej@packetizer.com; gv@trace.wisc.edu Subject: RE: Betr.: [Sipping] ToIP Requirements Arnoud Generally, you don't want to rely on very many SIP elements to complete an emergency call. Present systems accept TDD at all answering points because they don't know before the calls is answered that it is a TDD call. I certainly don't want the user to have to do anything other than dial his local emergency number, or complete a device specific key sequence to complete an emergency call, and I don't want a gateway busy to prevent an emergency call. Brian > -----Original Message----- > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > Sent: Thursday, February 26, 2004 6:07 AM > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > Gonzalo.Camarillo@ericsson.com; > sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > paulej@packetizer.com; gv@trace.wisc.edu > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > Actually, > When using the text gateway, there is no need to detect the > TDD/Analogue > text telephone tones/signals. That is the job of the text gateway. > > And for the emergency calling. We have to look closely at this in > combination with a text gateway. Possible behaviour/action. > And possible > action in SIP. > > Right now I cannot say what has to happen, I must study the > emergency calls > in depth. But as I see it, using the text gateway, all SIP > originating and > receiving emergency calls will be possible for any textphone user. > > Cheers > > Arnoud > > > Drs. Arnoud A. T. van Wijk > Viataal > Research & Development > Afdeling RDS > Theerestraat 42 > 5271 GD Sint-Michielsgestel > The Netherlands. > Mobile: +31651921948 > International text telephone: +31735588408 > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of > Rosen, Brian > Sent: woensdag 25 februari 2004 23:08 > To: 'Gunnar Hellstrom'; A vWijk; Gonzalo.Camarillo@ericsson.com; > sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > paulej@packetizer.com; gv@trace.wisc.edu > Subject: RE: Betr.: [Sipping] ToIP Requirements > > I'm particularly interested in the last one, emergency calling. > > Given that you propose an appropriate SDP indicating support for text, > do you think there is anything else we need to do to in SIP > to make this > happen? I don't see anything. > > I know that the problem of using a legacy TDD device on any kind of > adapter is as problematic as current TDD; the call will answered > as if it was a voice call, the baudot/whatever tones will be > detected, > and the operator will look for text. > Can't think of any way to make that better. > > Do note that language preference headers should be set!!! > > Brian > > > -----Original Message----- > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > Sent: Wednesday, February 25, 2004 4:54 PM > > To: A vWijk; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > henry.sinnreich@mci.com; > > paulej@packetizer.com; gv@trace.wisc.edu > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > I think PSTN textphone gateway invocation is one area where > > we either need > > protocol extensions, or need agreements on what current > > mechanisms to use. > > > > Another is invocation of various kinds of relay services or > > translation > > services. > > > > A third is calling emergency services and reach positions capable of > > handling the type of communication that the user prefers. > > > > > > > > Gunnar > > ------------------------------------------- > > Gunnar Hellstrom > > Omnitor AB > > Renathvagen 2 > > SE 121 37 Johanneshov > > SWEDEN > > +46 8 556 002 03 > > Mob: +46 708 204 288 > > www.omnitor.se > > Gunnar.Hellstrom@Omnitor.se > > -------------------------------------------- > > > > > > -----Original Message----- > > From: sipping-admin@ietf.org > > [mailto:sipping-admin@ietf.org]On Behalf Of > > A vWijk > > Sent: Tuesday, February 24, 2004 1:22 PM > > To: Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > henry.sinnreich@mci.com; > > gunnar.hellstrom@omnitor.se; paulej@packetizer.com; > gv@trace.wisc.edu > > Subject: Betr.: [Sipping] ToIP Requirements > > > > > > Hello Gonzalo, > > While there are device requirements in the text. Those > > requirements and the > > explanation on the different analogue text telephone systems > > is included to > > give the reader an understanding what kind of devices will > > connect with > > ToIP. And the need for the text gateways. And what the > > different behaviour > > can/may be compared to end to end IP devices. > > The most important part will be the ToIP framwork and the > > text gateways and > > how such gateways will be used and work with the ToIP framework. > > > > There is a ToIP framework where a terminal uses streaming > > text as defined in > > RFC2793 to connect with any other Interactive > > texting/real-time streaming > > text device. > > This can be end-to-end IP, and a direct T140/RTP stream is > > established with > > SIP. But in other cases, a text gateway must be used to allow > > T.140/RTP to > > connect with a non IP text telephony device. > > It can be an analogue text telephone (TDD/TTY) that uses a > > text gateway to > > be able to understand RFC2793 text. (PSTN-IP) > > It can be a mobile phone running GPRS that uses the text gateway to > > understand RFC2793 text. (this exist right NOW using SIP! And > > those gateways > > will be used in mobile networks this year!) > > Or a mobile text telephone using CTM via the text gateway to > > communicate > > with RFC2793 text. > > Or even one analogue text telephone connecting to another > > analogue text > > telephone in a different country, and the PSTN's use IP to > > connect the call. > > > > The question is for example, how do we use that gateway from > > the IP side? Is > > it invisible for the IP side? Or do we need special > > extensions in SIP to > > that the IP terminal knows it is communicating with the > > end-device through > > the text gateway? > > There may be a slightly different call setup flow when a text > > gateway is > > included. > > Or additional SIP messages indicating gateway activity. When > > you connect for > > example to an analogue text telephone with an RFC2793 capable > > IP terminal > > the capabilities will be less then IP to IP terminal directly > > (different > > transmission speeds, half/full duplex etc). > > Or what to do with emergency calls that are in RFC 2793 text only? > > > > That are requirements that will be defined and worked out in > > this draft. > > Also, we want to make everybody in SIP and SIPPING aware > > about those text > > gateways. So that complicated matters like how to send analogue text > > telephone text through a PSTN and connect with a SIP > > telephone using RFC2793 > > interactive texting. When using the text gateway, there is > > then no need for > > RFC 2833 events at the PSTN for text telephones. > > > > So, yes. I believe that this should be in the SIPPING WG. And > > it will fit in > > the charter - support for hearing-/speech-impaired calling. > > > > greetz > > > > Arnoud > > > > > > > > Drs. Arnoud A. T. van Wijk > > Viataal > > Research & Development > > Afdeling RDS > > Theerestraat 42 > > 5271 GD Sint-Michielsgestel > > The Netherlands. > > Mobile: +31651921948 > > International text telephone: +31735588408 > > > > >>> Gonzalo Camarillo > > 24-02-04 10:21 >>> > > Hello, > > > > the draft below provides a set of requirements for real-time > > conversations using SIP. > > http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-to > ip-01.txt > > Nevertheless, I have found a lot of device requirements in > the text, but > I fail to understand which particular protocol requirements we need to > fulfill with new protocol extensions. > > While SIPPING is the right place to handle requirements that will lead > to new SIP protocol extensions, SIPPING may not be the right place to > deal with device requirements (e.g., text phones MUST have a > display of > at least 100 characters). > > Thanks, > > Gonzalo > > > This communication is confidential and intended solely for > the addressee(s). > Any unauthorized review, use, disclosure or distribution is > prohibited. If > you believe this message has been sent to you in error, > please notify the > sender by replying to this transmission and delete the message without > disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, > and we only > send and receive e-mails on the basis that we are not liable > for any such > corruption, interception, amendment, tampering or viruses or any > consequences thereof. > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 26 09:22:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14596 for ; Thu, 26 Feb 2004 09:22:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMON-0008GA-MS for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 09:21:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QELZ4T031744 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 09:21:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMON-0008Fv-HO for sipping-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 09:21:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14473 for ; Thu, 26 Feb 2004 09:21:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMOL-0006Fl-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 09:21:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMN4-0005yA-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 09:20:15 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AwMM6-0005nt-04 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 09:19:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AwMAd-0005il-Rc for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 09:07:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMAI-0006be-Pm; Thu, 26 Feb 2004 09:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwM9p-0006a7-Fn for sipping@optimus.ietf.org; Thu, 26 Feb 2004 09:06:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13874 for ; Thu, 26 Feb 2004 09:06:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwM9n-0004pE-00 for sipping@ietf.org; Thu, 26 Feb 2004 09:06:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwM8s-0004iT-00 for sipping@ietf.org; Thu, 26 Feb 2004 09:05:35 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AwM7t-0004V6-00 for sipping@ietf.org; Thu, 26 Feb 2004 09:04:34 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCWCRG>; Thu, 26 Feb 2004 09:03:53 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6467@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Arnoud van Wijk'" , "'Gunnar Hellstrom'" , Gonzalo.Camarillo@ericsson.com, sipping@ietf.org Cc: rrroy@att.com, barry.dingle@bigfoot.com.au, henry.sinnreich@mci.com, paulej@packetizer.com, gv@trace.wisc.edu Subject: RE: Betr.: [Sipping] ToIP Requirements Date: Thu, 26 Feb 2004 09:03:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Arnoud Generally, you don't want to rely on very many SIP elements to complete an emergency call. Present systems accept TDD at all answering points because they don't know before the calls is answered that it is a TDD call. I certainly don't want the user to have to do anything other than dial his local emergency number, or complete a device specific key sequence to complete an emergency call, and I don't want a gateway busy to prevent an emergency call. Brian > -----Original Message----- > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > Sent: Thursday, February 26, 2004 6:07 AM > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > Gonzalo.Camarillo@ericsson.com; > sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > paulej@packetizer.com; gv@trace.wisc.edu > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > Actually, > When using the text gateway, there is no need to detect the > TDD/Analogue > text telephone tones/signals. That is the job of the text gateway. > > And for the emergency calling. We have to look closely at this in > combination with a text gateway. Possible behaviour/action. > And possible > action in SIP. > > Right now I cannot say what has to happen, I must study the > emergency calls > in depth. But as I see it, using the text gateway, all SIP > originating and > receiving emergency calls will be possible for any textphone user. > > Cheers > > Arnoud > > > Drs. Arnoud A. T. van Wijk > Viataal > Research & Development > Afdeling RDS > Theerestraat 42 > 5271 GD Sint-Michielsgestel > The Netherlands. > Mobile: +31651921948 > International text telephone: +31735588408 > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of > Rosen, Brian > Sent: woensdag 25 februari 2004 23:08 > To: 'Gunnar Hellstrom'; A vWijk; Gonzalo.Camarillo@ericsson.com; > sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > paulej@packetizer.com; gv@trace.wisc.edu > Subject: RE: Betr.: [Sipping] ToIP Requirements > > I'm particularly interested in the last one, emergency calling. > > Given that you propose an appropriate SDP indicating support for text, > do you think there is anything else we need to do to in SIP > to make this > happen? I don't see anything. > > I know that the problem of using a legacy TDD device on any kind of > adapter is as problematic as current TDD; the call will answered > as if it was a voice call, the baudot/whatever tones will be > detected, > and the operator will look for text. > Can't think of any way to make that better. > > Do note that language preference headers should be set!!! > > Brian > > > -----Original Message----- > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > Sent: Wednesday, February 25, 2004 4:54 PM > > To: A vWijk; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > henry.sinnreich@mci.com; > > paulej@packetizer.com; gv@trace.wisc.edu > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > I think PSTN textphone gateway invocation is one area where > > we either need > > protocol extensions, or need agreements on what current > > mechanisms to use. > > > > Another is invocation of various kinds of relay services or > > translation > > services. > > > > A third is calling emergency services and reach positions capable of > > handling the type of communication that the user prefers. > > > > > > > > Gunnar > > ------------------------------------------- > > Gunnar Hellstrom > > Omnitor AB > > Renathvagen 2 > > SE 121 37 Johanneshov > > SWEDEN > > +46 8 556 002 03 > > Mob: +46 708 204 288 > > www.omnitor.se > > Gunnar.Hellstrom@Omnitor.se > > -------------------------------------------- > > > > > > -----Original Message----- > > From: sipping-admin@ietf.org > > [mailto:sipping-admin@ietf.org]On Behalf Of > > A vWijk > > Sent: Tuesday, February 24, 2004 1:22 PM > > To: Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > henry.sinnreich@mci.com; > > gunnar.hellstrom@omnitor.se; paulej@packetizer.com; > gv@trace.wisc.edu > > Subject: Betr.: [Sipping] ToIP Requirements > > > > > > Hello Gonzalo, > > While there are device requirements in the text. Those > > requirements and the > > explanation on the different analogue text telephone systems > > is included to > > give the reader an understanding what kind of devices will > > connect with > > ToIP. And the need for the text gateways. And what the > > different behaviour > > can/may be compared to end to end IP devices. > > The most important part will be the ToIP framwork and the > > text gateways and > > how such gateways will be used and work with the ToIP framework. > > > > There is a ToIP framework where a terminal uses streaming > > text as defined in > > RFC2793 to connect with any other Interactive > > texting/real-time streaming > > text device. > > This can be end-to-end IP, and a direct T140/RTP stream is > > established with > > SIP. But in other cases, a text gateway must be used to allow > > T.140/RTP to > > connect with a non IP text telephony device. > > It can be an analogue text telephone (TDD/TTY) that uses a > > text gateway to > > be able to understand RFC2793 text. (PSTN-IP) > > It can be a mobile phone running GPRS that uses the text gateway to > > understand RFC2793 text. (this exist right NOW using SIP! And > > those gateways > > will be used in mobile networks this year!) > > Or a mobile text telephone using CTM via the text gateway to > > communicate > > with RFC2793 text. > > Or even one analogue text telephone connecting to another > > analogue text > > telephone in a different country, and the PSTN's use IP to > > connect the call. > > > > The question is for example, how do we use that gateway from > > the IP side? Is > > it invisible for the IP side? Or do we need special > > extensions in SIP to > > that the IP terminal knows it is communicating with the > > end-device through > > the text gateway? > > There may be a slightly different call setup flow when a text > > gateway is > > included. > > Or additional SIP messages indicating gateway activity. When > > you connect for > > example to an analogue text telephone with an RFC2793 capable > > IP terminal > > the capabilities will be less then IP to IP terminal directly > > (different > > transmission speeds, half/full duplex etc). > > Or what to do with emergency calls that are in RFC 2793 text only? > > > > That are requirements that will be defined and worked out in > > this draft. > > Also, we want to make everybody in SIP and SIPPING aware > > about those text > > gateways. So that complicated matters like how to send analogue text > > telephone text through a PSTN and connect with a SIP > > telephone using RFC2793 > > interactive texting. When using the text gateway, there is > > then no need for > > RFC 2833 events at the PSTN for text telephones. > > > > So, yes. I believe that this should be in the SIPPING WG. And > > it will fit in > > the charter - support for hearing-/speech-impaired calling. > > > > greetz > > > > Arnoud > > > > > > > > Drs. Arnoud A. T. van Wijk > > Viataal > > Research & Development > > Afdeling RDS > > Theerestraat 42 > > 5271 GD Sint-Michielsgestel > > The Netherlands. > > Mobile: +31651921948 > > International text telephone: +31735588408 > > > > >>> Gonzalo Camarillo > > 24-02-04 10:21 >>> > > Hello, > > > > the draft below provides a set of requirements for real-time > > conversations using SIP. > > http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-to > ip-01.txt > > Nevertheless, I have found a lot of device requirements in > the text, but > I fail to understand which particular protocol requirements we need to > fulfill with new protocol extensions. > > While SIPPING is the right place to handle requirements that will lead > to new SIP protocol extensions, SIPPING may not be the right place to > deal with device requirements (e.g., text phones MUST have a > display of > at least 100 characters). > > Thanks, > > Gonzalo > > > This communication is confidential and intended solely for > the addressee(s). > Any unauthorized review, use, disclosure or distribution is > prohibited. If > you believe this message has been sent to you in error, > please notify the > sender by replying to this transmission and delete the message without > disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, > and we only > send and receive e-mails on the basis that we are not liable > for any such > corruption, interception, amendment, tampering or viruses or any > consequences thereof. > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 26 09:41:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15827 for ; Thu, 26 Feb 2004 09:41:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMgu-0001nk-Ml for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 09:40:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QEeiID006918 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 09:40:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMgs-0001nN-1i for sipping-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 09:40:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15796 for ; Thu, 26 Feb 2004 09:40:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMgp-0000YG-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 09:40:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMft-0000TN-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 09:39:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwMfK-0000OR-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 09:39:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMfF-0001Zp-MH; Thu, 26 Feb 2004 09:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMeq-0001YN-MN for sipping@optimus.ietf.org; Thu, 26 Feb 2004 09:38:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15718 for ; Thu, 26 Feb 2004 09:38:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMeo-0000N7-00 for sipping@ietf.org; Thu, 26 Feb 2004 09:38:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMdv-0000Ie-00 for sipping@ietf.org; Thu, 26 Feb 2004 09:37:40 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AwMdK-0000Bw-00 for sipping@ietf.org; Thu, 26 Feb 2004 09:37:03 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCWDV4>; Thu, 26 Feb 2004 09:36:32 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B646A@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Arnoud van Wijk'" , "'Gunnar Hellstrom'" , Gonzalo.Camarillo@ericsson.com, sipping@ietf.org Cc: rrroy@att.com, barry.dingle@bigfoot.com.au, henry.sinnreich@mci.com, paulej@packetizer.com, gv@trace.wisc.edu Subject: RE: Betr.: [Sipping] ToIP Requirements Date: Thu, 26 Feb 2004 09:36:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Arnoud I do not believe this can work. A TDD user dials 112 or 911. Today, this will be routed directly to a "selective router" (a TDM switch) which sends the call to the correct Emergency Response Center. You can't insert a gateway, because you don't know that it's a TDD call until it is answered. To make it work, you would have to establish a special PSTN number for emergency TDD, which would route to the gateway, which would then call the ERC. I don't believe that is practical. Brian > -----Original Message----- > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > Sent: Thursday, February 26, 2004 9:17 AM > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > Gonzalo.Camarillo@ericsson.com; > sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > paulej@packetizer.com; gv@trace.wisc.edu > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > Hello Brian, > That is also why we need to look at the emergency call system. > This text gateway is only at the PSTN side, thus another > requirement for a > T140/RTP gateway for the PSTN is that when a local emergency number is > dialled (112, or 911 etc). That the gateway must be able to > receive that > call (even dropping existing calls if necessary). Such a call > is easy to > recognize as an emergency call. (PSTN side). > From that gateway on, it is all IP with RFC2793 interactive > text. And then > it is just all existing SIP as if it was from an IP end-point. > > This gives emergency centers an advantage, all calls will be > T.140/RTP, so > integration in their computer systems will be easy instead > being forced to > have analog textphones available for a textphone call. (or a > separate text > telephone emergency center). > > /Arnoud > > Drs. Arnoud A. T. van Wijk > Viataal > Research & Development > Afdeling RDS > Theerestraat 42 > 5271 GD Sint-Michielsgestel > The Netherlands. > Mobile: +31651921948 > International text telephone: +31735588408 > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: donderdag 26 februari 2004 15:04 > To: 'Arnoud van Wijk'; 'Gunnar Hellstrom'; > Gonzalo.Camarillo@ericsson.com; > sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > paulej@packetizer.com; gv@trace.wisc.edu > Subject: RE: Betr.: [Sipping] ToIP Requirements > > Arnoud > > Generally, you don't want to rely on very many SIP elements > to complete > an emergency call. Present systems accept TDD at all answering > points because they don't know before the calls is answered that it > is a TDD call. I certainly don't want the user to have to do anything > other than dial his local emergency number, or complete a device > specific key sequence to complete an emergency call, and I don't > want a gateway busy to prevent an emergency call. > > Brian > > > -----Original Message----- > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > Sent: Thursday, February 26, 2004 6:07 AM > > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > > Gonzalo.Camarillo@ericsson.com; > > sipping@ietf.org > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > henry.sinnreich@mci.com; > > paulej@packetizer.com; gv@trace.wisc.edu > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > Actually, > > When using the text gateway, there is no need to detect the > > TDD/Analogue > > text telephone tones/signals. That is the job of the text gateway. > > > > And for the emergency calling. We have to look closely at this in > > combination with a text gateway. Possible behaviour/action. > > And possible > > action in SIP. > > > > Right now I cannot say what has to happen, I must study the > > emergency calls > > in depth. But as I see it, using the text gateway, all SIP > > originating and > > receiving emergency calls will be possible for any textphone user. > > > > Cheers > > > > Arnoud > > > > > > Drs. Arnoud A. T. van Wijk > > Viataal > > Research & Development > > Afdeling RDS > > Theerestraat 42 > > 5271 GD Sint-Michielsgestel > > The Netherlands. > > Mobile: +31651921948 > > International text telephone: +31735588408 > > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of > > Rosen, Brian > > Sent: woensdag 25 februari 2004 23:08 > > To: 'Gunnar Hellstrom'; A vWijk; Gonzalo.Camarillo@ericsson.com; > > sipping@ietf.org > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > henry.sinnreich@mci.com; > > paulej@packetizer.com; gv@trace.wisc.edu > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > I'm particularly interested in the last one, emergency calling. > > > > Given that you propose an appropriate SDP indicating > support for text, > > do you think there is anything else we need to do to in SIP > > to make this > > happen? I don't see anything. > > > > I know that the problem of using a legacy TDD device on any kind of > > adapter is as problematic as current TDD; the call will answered > > as if it was a voice call, the baudot/whatever tones will be > > detected, > > and the operator will look for text. > > Can't think of any way to make that better. > > > > Do note that language preference headers should be set!!! > > > > Brian > > > > > -----Original Message----- > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > Sent: Wednesday, February 25, 2004 4:54 PM > > > To: A vWijk; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > henry.sinnreich@mci.com; > > > paulej@packetizer.com; gv@trace.wisc.edu > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > I think PSTN textphone gateway invocation is one area where > > > we either need > > > protocol extensions, or need agreements on what current > > > mechanisms to use. > > > > > > Another is invocation of various kinds of relay services or > > > translation > > > services. > > > > > > A third is calling emergency services and reach positions > capable of > > > handling the type of communication that the user prefers. > > > > > > > > > > > > Gunnar > > > ------------------------------------------- > > > Gunnar Hellstrom > > > Omnitor AB > > > Renathvagen 2 > > > SE 121 37 Johanneshov > > > SWEDEN > > > +46 8 556 002 03 > > > Mob: +46 708 204 288 > > > www.omnitor.se > > > Gunnar.Hellstrom@Omnitor.se > > > -------------------------------------------- > > > > > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org > > > [mailto:sipping-admin@ietf.org]On Behalf Of > > > A vWijk > > > Sent: Tuesday, February 24, 2004 1:22 PM > > > To: Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > henry.sinnreich@mci.com; > > > gunnar.hellstrom@omnitor.se; paulej@packetizer.com; > > gv@trace.wisc.edu > > > Subject: Betr.: [Sipping] ToIP Requirements > > > > > > > > > Hello Gonzalo, > > > While there are device requirements in the text. Those > > > requirements and the > > > explanation on the different analogue text telephone systems > > > is included to > > > give the reader an understanding what kind of devices will > > > connect with > > > ToIP. And the need for the text gateways. And what the > > > different behaviour > > > can/may be compared to end to end IP devices. > > > The most important part will be the ToIP framwork and the > > > text gateways and > > > how such gateways will be used and work with the ToIP framework. > > > > > > There is a ToIP framework where a terminal uses streaming > > > text as defined in > > > RFC2793 to connect with any other Interactive > > > texting/real-time streaming > > > text device. > > > This can be end-to-end IP, and a direct T140/RTP stream is > > > established with > > > SIP. But in other cases, a text gateway must be used to allow > > > T.140/RTP to > > > connect with a non IP text telephony device. > > > It can be an analogue text telephone (TDD/TTY) that uses a > > > text gateway to > > > be able to understand RFC2793 text. (PSTN-IP) > > > It can be a mobile phone running GPRS that uses the text > gateway to > > > understand RFC2793 text. (this exist right NOW using SIP! And > > > those gateways > > > will be used in mobile networks this year!) > > > Or a mobile text telephone using CTM via the text gateway to > > > communicate > > > with RFC2793 text. > > > Or even one analogue text telephone connecting to another > > > analogue text > > > telephone in a different country, and the PSTN's use IP to > > > connect the call. > > > > > > The question is for example, how do we use that gateway from > > > the IP side? Is > > > it invisible for the IP side? Or do we need special > > > extensions in SIP to > > > that the IP terminal knows it is communicating with the > > > end-device through > > > the text gateway? > > > There may be a slightly different call setup flow when a text > > > gateway is > > > included. > > > Or additional SIP messages indicating gateway activity. When > > > you connect for > > > example to an analogue text telephone with an RFC2793 capable > > > IP terminal > > > the capabilities will be less then IP to IP terminal directly > > > (different > > > transmission speeds, half/full duplex etc). > > > Or what to do with emergency calls that are in RFC 2793 text only? > > > > > > That are requirements that will be defined and worked out in > > > this draft. > > > Also, we want to make everybody in SIP and SIPPING aware > > > about those text > > > gateways. So that complicated matters like how to send > analogue text > > > telephone text through a PSTN and connect with a SIP > > > telephone using RFC2793 > > > interactive texting. When using the text gateway, there is > > > then no need for > > > RFC 2833 events at the PSTN for text telephones. > > > > > > So, yes. I believe that this should be in the SIPPING WG. And > > > it will fit in > > > the charter - support for hearing-/speech-impaired calling. > > > > > > greetz > > > > > > Arnoud > > > > > > > > > > > > Drs. Arnoud A. T. van Wijk > > > Viataal > > > Research & Development > > > Afdeling RDS > > > Theerestraat 42 > > > 5271 GD Sint-Michielsgestel > > > The Netherlands. > > > Mobile: +31651921948 > > > International text telephone: +31735588408 > > > > > > >>> Gonzalo Camarillo > > > 24-02-04 10:21 >>> > > > Hello, > > > > > > the draft below provides a set of requirements for real-time > > > conversations using SIP. > > > http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-to > > ip-01.txt > > > > Nevertheless, I have found a lot of device requirements in > > the text, but > > I fail to understand which particular protocol requirements > we need to > > fulfill with new protocol extensions. > > > > While SIPPING is the right place to handle requirements > that will lead > > to new SIP protocol extensions, SIPPING may not be the > right place to > > deal with device requirements (e.g., text phones MUST have a > > display of > > at least 100 characters). > > > > Thanks, > > > > Gonzalo > > > > > > This communication is confidential and intended solely for > > the addressee(s). > > Any unauthorized review, use, disclosure or distribution is > > prohibited. If > > you believe this message has been sent to you in error, > > please notify the > > sender by replying to this transmission and delete the > message without > > disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data corruption, > > interruption, unauthorized amendment, tampering and viruses, > > and we only > > send and receive e-mails on the basis that we are not liable > > for any such > > corruption, interception, amendment, tampering or viruses or any > > consequences thereof. > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 26 11:01:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21779 for ; Thu, 26 Feb 2004 11:01:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNwP-0008TA-2y for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 11:00:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QG0mCh032548 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 11:00:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNwM-0008Sp-5t for sipping-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 11:00:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21763 for ; Thu, 26 Feb 2004 11:00:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwNwJ-0002mP-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 11:00:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwNvV-0002hF-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 10:59:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwNuo-0002bA-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 10:59:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNuf-00085Q-I5; Thu, 26 Feb 2004 10:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNuL-00080a-29 for sipping@optimus.ietf.org; Thu, 26 Feb 2004 10:58:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21621 for ; Thu, 26 Feb 2004 10:58:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwNuI-0002YP-00 for sipping@ietf.org; Thu, 26 Feb 2004 10:58:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwNtN-0002T8-00 for sipping@ietf.org; Thu, 26 Feb 2004 10:57:42 -0500 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1AwNsb-0002OD-00 for sipping@ietf.org; Thu, 26 Feb 2004 10:56:53 -0500 Received: from solstice (ew-dsl-81-171-14-60.eweka.nl [81.171.14.60]) by smtp.eweka.nl (8.12.9/8.12.9) with ESMTP id i1QG72rb012677; Thu, 26 Feb 2004 16:07:07 GMT (envelope-from a.vwijk@viataal.nl) Message-Id: <200402261607.i1QG72rb012677@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Rosen, Brian'" , "'Gunnar Hellstrom'" , , Cc: , , , , Subject: RE: Betr.: [Sipping] ToIP Requirements Date: Thu, 26 Feb 2004 16:56:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <313680C9A886D511A06000204840E1CF070B646A@whq-msgusr-02.pit.comms.marconi.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-index: AcP8df4K7xKT4vhvQoKwZ4oKVIzK3QABbskw Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Brian, Yes you are right about that the PSTN cannot detect if it is a voice call or TDD/Textphone call. They are both audio. The PSTN would if it can detect it is a textphone call, route it to the text gateway. And transcode the call into T.140 over RTP as decribed in RFC 2793. This is for PSTNs which use IP to interconnect with other PSTNs or with any SIP telephones. So it is for analoge telephony into SIP telephony here. In the ToIP draft: http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-toip-01.txt A possible solution is a prefix for textphone users before dialling the selected number. It indeed would mean that you dial e.g. 600-112 instead 112 directly. Is that bad? I believe it is not. Most textphones have the emergency number pre programmed. And when textphone users have to use a pre-fix for any textphone call, then the same prefix before 112 or 911 will be fine. In the Netherlands, we have for emergency calls 800-112 instead of 112. It works fine, only almost no deaf users call 112, since they are then mostly in a situation where they do not have a textphone nearby! Maybe there are other solutions that allow the PSTN to detect that the incoming call is a textphone user and acts on it. For example it is possible to create a database where the PSTN can check if the incoming number is registered as a textphone. But using a text gateway to connect PSTN textphones/TDDs to ToIP is still the best solution, even the only solution in my opinion. There should be no attempts to transport the text telephone tones (e.g. Baudot) over the IP voice channel! I believe that will open Pandora's box. I am not a PSTN expert, and we can surely look into this matter to find a solution. Let it be prefix or any other solution that lets the PSTN immediately route the call to the text gateway. What do you PSTN people think? How would you tackle this problem? Your input will be very welcome. Greetz Arnoud Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 International text telephone: +31735588408 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: donderdag 26 februari 2004 15:36 To: 'Arnoud van Wijk'; 'Gunnar Hellstrom'; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; henry.sinnreich@mci.com; paulej@packetizer.com; gv@trace.wisc.edu Subject: RE: Betr.: [Sipping] ToIP Requirements Arnoud I do not believe this can work. A TDD user dials 112 or 911. Today, this will be routed directly to a "selective router" (a TDM switch) which sends the call to the correct Emergency Response Center. You can't insert a gateway, because you don't know that it's a TDD call until it is answered. To make it work, you would have to establish a special PSTN number for emergency TDD, which would route to the gateway, which would then call the ERC. I don't believe that is practical. Brian > -----Original Message----- > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > Sent: Thursday, February 26, 2004 9:17 AM > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > Gonzalo.Camarillo@ericsson.com; > sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > paulej@packetizer.com; gv@trace.wisc.edu > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > Hello Brian, > That is also why we need to look at the emergency call system. > This text gateway is only at the PSTN side, thus another > requirement for a > T140/RTP gateway for the PSTN is that when a local emergency number is > dialled (112, or 911 etc). That the gateway must be able to > receive that > call (even dropping existing calls if necessary). Such a call > is easy to > recognize as an emergency call. (PSTN side). > From that gateway on, it is all IP with RFC2793 interactive > text. And then > it is just all existing SIP as if it was from an IP end-point. > > This gives emergency centers an advantage, all calls will be > T.140/RTP, so > integration in their computer systems will be easy instead > being forced to > have analog textphones available for a textphone call. (or a > separate text > telephone emergency center). > > /Arnoud > > Drs. Arnoud A. T. van Wijk > Viataal > Research & Development > Afdeling RDS > Theerestraat 42 > 5271 GD Sint-Michielsgestel > The Netherlands. > Mobile: +31651921948 > International text telephone: +31735588408 > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: donderdag 26 februari 2004 15:04 > To: 'Arnoud van Wijk'; 'Gunnar Hellstrom'; > Gonzalo.Camarillo@ericsson.com; > sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > paulej@packetizer.com; gv@trace.wisc.edu > Subject: RE: Betr.: [Sipping] ToIP Requirements > > Arnoud > > Generally, you don't want to rely on very many SIP elements > to complete > an emergency call. Present systems accept TDD at all answering > points because they don't know before the calls is answered that it > is a TDD call. I certainly don't want the user to have to do anything > other than dial his local emergency number, or complete a device > specific key sequence to complete an emergency call, and I don't > want a gateway busy to prevent an emergency call. > > Brian > > > -----Original Message----- > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > Sent: Thursday, February 26, 2004 6:07 AM > > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > > Gonzalo.Camarillo@ericsson.com; > > sipping@ietf.org > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > henry.sinnreich@mci.com; > > paulej@packetizer.com; gv@trace.wisc.edu > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > Actually, > > When using the text gateway, there is no need to detect the > > TDD/Analogue > > text telephone tones/signals. That is the job of the text gateway. > > > > And for the emergency calling. We have to look closely at this in > > combination with a text gateway. Possible behaviour/action. > > And possible > > action in SIP. > > > > Right now I cannot say what has to happen, I must study the > > emergency calls > > in depth. But as I see it, using the text gateway, all SIP > > originating and > > receiving emergency calls will be possible for any textphone user. > > > > Cheers > > > > Arnoud > > > > > > Drs. Arnoud A. T. van Wijk > > Viataal > > Research & Development > > Afdeling RDS > > Theerestraat 42 > > 5271 GD Sint-Michielsgestel > > The Netherlands. > > Mobile: +31651921948 > > International text telephone: +31735588408 > > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of > > Rosen, Brian > > Sent: woensdag 25 februari 2004 23:08 > > To: 'Gunnar Hellstrom'; A vWijk; Gonzalo.Camarillo@ericsson.com; > > sipping@ietf.org > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > henry.sinnreich@mci.com; > > paulej@packetizer.com; gv@trace.wisc.edu > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > I'm particularly interested in the last one, emergency calling. > > > > Given that you propose an appropriate SDP indicating > support for text, > > do you think there is anything else we need to do to in SIP > > to make this > > happen? I don't see anything. > > > > I know that the problem of using a legacy TDD device on any kind of > > adapter is as problematic as current TDD; the call will answered > > as if it was a voice call, the baudot/whatever tones will be > > detected, > > and the operator will look for text. > > Can't think of any way to make that better. > > > > Do note that language preference headers should be set!!! > > > > Brian > > > > > -----Original Message----- > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > Sent: Wednesday, February 25, 2004 4:54 PM > > > To: A vWijk; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > henry.sinnreich@mci.com; > > > paulej@packetizer.com; gv@trace.wisc.edu > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > I think PSTN textphone gateway invocation is one area where > > > we either need > > > protocol extensions, or need agreements on what current > > > mechanisms to use. > > > > > > Another is invocation of various kinds of relay services or > > > translation > > > services. > > > > > > A third is calling emergency services and reach positions > capable of > > > handling the type of communication that the user prefers. > > > > > > > > > > > > Gunnar > > > ------------------------------------------- > > > Gunnar Hellstrom > > > Omnitor AB > > > Renathvagen 2 > > > SE 121 37 Johanneshov > > > SWEDEN > > > +46 8 556 002 03 > > > Mob: +46 708 204 288 > > > www.omnitor.se > > > Gunnar.Hellstrom@Omnitor.se > > > -------------------------------------------- > > > > > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org > > > [mailto:sipping-admin@ietf.org]On Behalf Of > > > A vWijk > > > Sent: Tuesday, February 24, 2004 1:22 PM > > > To: Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > henry.sinnreich@mci.com; > > > gunnar.hellstrom@omnitor.se; paulej@packetizer.com; > > gv@trace.wisc.edu > > > Subject: Betr.: [Sipping] ToIP Requirements > > > > > > > > > Hello Gonzalo, > > > While there are device requirements in the text. Those > > > requirements and the > > > explanation on the different analogue text telephone systems > > > is included to > > > give the reader an understanding what kind of devices will > > > connect with > > > ToIP. And the need for the text gateways. And what the > > > different behaviour > > > can/may be compared to end to end IP devices. > > > The most important part will be the ToIP framwork and the > > > text gateways and > > > how such gateways will be used and work with the ToIP framework. > > > > > > There is a ToIP framework where a terminal uses streaming > > > text as defined in > > > RFC2793 to connect with any other Interactive > > > texting/real-time streaming > > > text device. > > > This can be end-to-end IP, and a direct T140/RTP stream is > > > established with > > > SIP. But in other cases, a text gateway must be used to allow > > > T.140/RTP to > > > connect with a non IP text telephony device. > > > It can be an analogue text telephone (TDD/TTY) that uses a > > > text gateway to > > > be able to understand RFC2793 text. (PSTN-IP) > > > It can be a mobile phone running GPRS that uses the text > gateway to > > > understand RFC2793 text. (this exist right NOW using SIP! And > > > those gateways > > > will be used in mobile networks this year!) > > > Or a mobile text telephone using CTM via the text gateway to > > > communicate > > > with RFC2793 text. > > > Or even one analogue text telephone connecting to another > > > analogue text > > > telephone in a different country, and the PSTN's use IP to > > > connect the call. > > > > > > The question is for example, how do we use that gateway from > > > the IP side? Is > > > it invisible for the IP side? Or do we need special > > > extensions in SIP to > > > that the IP terminal knows it is communicating with the > > > end-device through > > > the text gateway? > > > There may be a slightly different call setup flow when a text > > > gateway is > > > included. > > > Or additional SIP messages indicating gateway activity. When > > > you connect for > > > example to an analogue text telephone with an RFC2793 capable > > > IP terminal > > > the capabilities will be less then IP to IP terminal directly > > > (different > > > transmission speeds, half/full duplex etc). > > > Or what to do with emergency calls that are in RFC 2793 text only? > > > > > > That are requirements that will be defined and worked out in > > > this draft. > > > Also, we want to make everybody in SIP and SIPPING aware > > > about those text > > > gateways. So that complicated matters like how to send > analogue text > > > telephone text through a PSTN and connect with a SIP > > > telephone using RFC2793 > > > interactive texting. When using the text gateway, there is > > > then no need for > > > RFC 2833 events at the PSTN for text telephones. > > > > > > So, yes. I believe that this should be in the SIPPING WG. And > > > it will fit in > > > the charter - support for hearing-/speech-impaired calling. > > > > > > greetz > > > > > > Arnoud > > > > > > > > > > > > Drs. Arnoud A. T. van Wijk > > > Viataal > > > Research & Development > > > Afdeling RDS > > > Theerestraat 42 > > > 5271 GD Sint-Michielsgestel > > > The Netherlands. > > > Mobile: +31651921948 > > > International text telephone: +31735588408 > > > > > > >>> Gonzalo Camarillo > > > 24-02-04 10:21 >>> > > > Hello, > > > > > > the draft below provides a set of requirements for real-time > > > conversations using SIP. > > > http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-to > > ip-01.txt > > > > Nevertheless, I have found a lot of device requirements in > > the text, but > > I fail to understand which particular protocol requirements > we need to > > fulfill with new protocol extensions. > > > > While SIPPING is the right place to handle requirements > that will lead > > to new SIP protocol extensions, SIPPING may not be the > right place to > > deal with device requirements (e.g., text phones MUST have a > > display of > > at least 100 characters). > > > > Thanks, > > > > Gonzalo > > > > > > This communication is confidential and intended solely for > > the addressee(s). > > Any unauthorized review, use, disclosure or distribution is > > prohibited. If > > you believe this message has been sent to you in error, > > please notify the > > sender by replying to this transmission and delete the > message without > > disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data corruption, > > interruption, unauthorized amendment, tampering and viruses, > > and we only > > send and receive e-mails on the basis that we are not liable > > for any such > > corruption, interception, amendment, tampering or viruses or any > > consequences thereof. > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 26 12:56:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29436 for ; Thu, 26 Feb 2004 12:56:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwPjo-000457-Sr for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 12:55:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QHtuji015683 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 12:55:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwPjo-00044r-De for sipping-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 12:55:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29426 for ; Thu, 26 Feb 2004 12:55:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwPjm-0007jh-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 12:55:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwPiu-0007e4-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 12:55:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwPi4-0007YA-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 12:54:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwPhy-0003kD-Mg; Thu, 26 Feb 2004 12:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwPhq-0003jN-60 for sipping@optimus.ietf.org; Thu, 26 Feb 2004 12:53:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29364 for ; Thu, 26 Feb 2004 12:53:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwPho-0007Wh-00 for sipping@ietf.org; Thu, 26 Feb 2004 12:53:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwPgv-0007Qm-00 for sipping@ietf.org; Thu, 26 Feb 2004 12:52:59 -0500 Received: from smtp.sylantro.com ([65.200.90.207]) by ietf-mx with esmtp (Exim 4.12) id 1AwPgO-0007K8-00 for sipping@ietf.org; Thu, 26 Feb 2004 12:52:24 -0500 Received: from 10.10.5.1 by smtp.sylantro.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v5.6.0)); Thu, 26 Feb 2004 09:49:54 -0800 X-Server-Uuid: A2273672-8896-48F6-829D-BBF711663783 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] updated dialog package Date: Thu, 26 Feb 2004 09:49:54 -0800 Message-ID: <22ACFCD87A5780449EEBDD6D78BB8DB50C37FC@sylmail1> Thread-Topic: [Sipping] updated dialog package Thread-Index: AcP78BcjwOantbFOTgeR7O73E/moJwAnm27A From: "Venkatesh Venkataramanan" To: "Rohan Mahy" cc: "Paul Pepper" , sipping X-WSS-ID: 6C20EE481XC103550-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Filtering as a mechanism would work well if the phone is receiving the = NOTIFY's from one single entity. In applications based on dialog state = where the UA could be receiving NOTIFY's from various entities, this = would amount to the UA having to establish filters at each such entity = that is providing the UA notifications which like you rightly comment = would amount to more filtering install traffic than any meaningful = exchange of information. Definitely like I said in my earlier email and = your comment, an end UA can simply discard NOTIFY's once it reaches it = limits, but limiting NOTIFY's at the source if possible would be nice to = have feature.=20 Also, what I am requesting for is not radically redefining the error = response for a NOTIFY. The 4xx response is STILL terminating = subscriptions, but with a narrower scope (just subscriptions to the = dialog that was presented to it in the payload of the NOTIFY). thanks Venkatesh -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Wednesday, February 25, 2004 2:39 PM To: Venkatesh Venkataramanan Cc: Paul Pepper; Rohan Mahy; sipping Subject: Re: [Sipping] updated dialog package Hi, We can't just redefine the meaning of error responses to a NOTIFY. The=20 behavior is very explicit in RFC3265 and its not package specific. It=20 means "terminate my subscription immediately". What you seem to want to accomplish is a type of filtering. We have=20 requirements for filtering and a proposed mechanism even. I think it=20 would be useful to compare your requirements to that work. However, I=20 am usually fairly skeptical about the value of asking for filtering=20 when it is easy to throw away the information you don't want. =20 Obviously in the case of filtering spam, you want someone upstream to=20 be able to do that, but in many other cases, sending around the=20 filtering rules themselves generates more traffic than the traffic the=20 filter would have removed... thanks, -rohan On Feb 25, 2004, at 11:51 AM, Venkatesh Venkataramanan wrote: > Also while we are at the topic of being able to reject NOTIFY's=20 > without terminating subscriptions, another useful capability to have=20 > would be for a UA to reject a NOTIFY with a specific response code so=20 > that any NOTIFY's for that dialog alone can be supressed. For example=20 > with SLA there may be UA's in the group that are of varying=20 > capabilities. For example UA1 can have capabilities to display say 2=20 > active dialogs at any point, while UA2 can have capabilities that=20 > permit it to show upto 5 active dialogs. When both the UA's are=20 > subscribed to dialog state, they receive dialog states of all dialogs. = > Now, if UA1 had an ability to respond to a NOTIFY for a third active=20 > dialog saying "Dont terminate my subscriptions; I want to continue=20 > getting notifications for all dialogs, but supress anything for this=20 > specific dialog as I have reached my limits", then it would avoid=20 > un-necessary NOTIFY overheads being sent towards UA1 and it having to=20 > accept it and throwing it away; keep track of what dialogs it has=20 > accepted without UI, so that all new NOTIFY's towards this dialog id=20 > are continued to be discarded silently ...... > > Venkatesh > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf=20 > Of > Rohan Mahy > Sent: Wednesday, February 25, 2004 9:29 AM > To: Paul Pepper > Cc: Rohan Mahy; sipping > Subject: Re: [Sipping] updated dialog package > > > > On Feb 25, 2004, at 7:32 AM, Paul Pepper wrote: > >> Hi, >> >> Comments in-line. >> >> Thanks, >> >> Paul. >> >>> -----Original Message----- >>> From: Rohan Mahy [mailto:rohan@cisco.com] >>> Sent: Tuesday, February 24, 2004 3:14 AM >>> To: Paul Pepper >>> Cc: Rohan Mahy; sipping >>> Subject: Re: [Sipping] updated dialog package >>> >>> >>> >>> On Feb 23, 2004, at 9:40 AM, Paul Pepper wrote: >>> >>>> Hi, >>>> >>>> I work for a company that has developed handset gateway devices = that >>>> enable legacy, digital, business-grade telephones to be driven = using >>>> SIP. For example, this enables an existing legacy PBX user >>>> to retain >>>> their telephones and cabling, but to replace the PBX by a >>>> Softswitch or >>>> IP Centrex system. As most business-grade telephone >>>> systems make use >>>> of >>>> a shared line facility, the addition of a shared line example to = the >>>> dialog event package ID is of great interest to us, and others who >>>> support these types of feature. >>>> >>>> Although incorporating a shared line example is a step >>>> towards a common >>>> approach to shared line implementation, I don't believe it goes far >>>> enough. Our current implementation of shared lines has >>>> shown that the >>>> following issues need to be addressed by the spec, and >>>> should be shown >>>> in the examples: >>>> >>>> o Line seize, an essential part of any shared line >>>> implementation, is >>>> not adequately described. When more than one user agent attempts to >>>> seize a line at approximately the same instant, a race condition >>>> arises. >>>> No description of how to handle the race is given - an example >>>> application/dialog-info+xml NOTIFY payload is provided, but >>>> this alone >>>> is inadequate, as message sequencing is an important part >>>> of seizing a >>>> line. The Line Seize condition will be covered in the >>>> "anil-sipping-bla-draft" that Venkatesh refers to. >>> >>> Line seizure is well beyond what would be appropriate to >>> standardize in >>> SIPPING because for many types of UAs that concept does not >>> even exist. >>> I was just trying to demonstrate a non-normative >>> description of how it >>> could be implemented. How you judge who "wins" a seizure race >>> condition >>> is an implementation specific issue. In fact, its quite likely that >>> different behaviors will be desired by different customers. When >>> talking about implementing this at Cisco, we concluded that a >>> configuration knob was needed to satisfy essentially opposite >>> requirements from two different customers. Each customer was = equally >>> adamant that he was "right" and the other was "wrong". As a >>> result, I >>> find it unlikely that SIPPING could come to come to consensus on = what >>> "proper seizing behavior" is even if we ignored the fact that >>> the bulk >>> of deployed SIP UAs are software UAs which have no lines to seize. >>> >> >> >> Yes, determining which user agents should win seize races is a matter >> of >> policy, and implementation specific. However, the mechanism used to >> convey whether a seize race has been won seems to be a matter for >> standardisation (e.g. a non-200 final response to the NOTIFY=20 >> requesting >> the seize could indicate that the seize operation has failed). > > Now I see what you are getting at. The particular mechanism that you > mention is unlikely to go over favorably because it would have the = side > effect of terminating your subscription. However, I agree it would be > useful to have a standard way to convey something like this. I'm not > convinced that this belongs in the dialog package, but I'll think = about > this. > > >>>> o Handling of multiple instances of a shared line has been >>>> overlooked. >>>> On business-grade PBX systems a line will roughly >>>> correspond to an AOR. >>>> However, many such systems permit multiple "instances" of a >>>> shared line >>>> to appear on a single endpoint. For example, a number of >>>> instances of a >>>> "product support" shared line might appear on all the >>>> endpoints of the >>>> product support group, thereby allowing multiple calls to >>>> be taken and >>>> passed around within the group. >>> >>> This has not been overlooked at all. You can have multiple >>> subscriptions (one per AOR), or you can subscribe to a list of AORs >>> with the event list extension: >>> >>> =09 >>> http://www.ietf.org/internet-drafts/draft-ietf-simple-event-li >>> st-04.txt >>> >> >> I haven't been sufficiently clear on this point. As you point out,=20 >> each >> shared AOR will have its own subscription. Take an example AOR of >> support@example. Although a single registration and two subscriptions >> (one in each direction, as subscriber and notifier, if a state agent=20 >> is >> used) are used per AOR on each user agent, multiple calls to/from = that >> AOR may be active at any time. If a user agent has the shared line >> capability then all calls to support@example will be presented on it >> by, >> say, illuminating one button per call. (Of course this is constrained >> to >> varying degrees by the user agent's display capabilities.) As each >> button shows a call to support@example the calls must be presented on >> those buttons in a consistent manner across all user agents on the >> network. This will allow Harry to put a call to support@example on=20 >> hold >> and verbally tell Thelma which button to press in order to pick that >> call up. If all the calls to support@example are presented in an >> arbitrary manner on different user agents, then the coherency of call >> presentation is lost. This is a problem as coherent call presentation >> is >> a requirement of existing PBX users, and gives the only meaningful = use >> for this feature. >> >> One way of achieving a consistent mapping of calls to buttons (if >> buttons are the user interface mechanism used) is to index buttons on >> all the user agents. That way, a call can be mapped to the specific >> button on all user agents of an installation. > > I expect that any such index would be conveyed as a target URI > parameter using a device ID of some sort. There is agenda time > scheduled in SIPPING to discuss Instance ID requirements with the > following reading list: > > draft-stucker-sip-guid-00.txt > draft-jennings-sipping-instance-id-00.txt > draft-ietf-xmpp-core-22.txt (section 2.3) > > thanks, > -rohan > > >>>> o The mechanism used to convey that a call has been placed on hold >>>> appears to rely upon implementation-specific parameters, >>>> found in the >>>> xml's element. I can't see any reference to >>>> definitions of the >>>> values used by this element's pname and pval attributes >>>> (pname=3D"+activity" pval=3D"noninteractive"), so I assume they're >>>> non-standard. >>> >>> This was due to distraction on my part. I had intended to include a >>> discussion of this in the current draft, but somehow left it >>> out at 2am >>> the day of the draft deadline. I'm terribly sorry about that. I'll >>> send out more about the hold issue tomorrow. >>> >>> thanks, >>> -rohan >>> >>>> Thanks, >>>> >>>> Paul. >>>> >>>>> -----Original Message----- >>>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>>> Sent: Thursday, February 19, 2004 6:00 PM >>>>> To: sipping >>>>> Cc: rohan@cisco.com >>>>> Subject: [Sipping] updated dialog package >>>>> >>>>> >>>>> Hi Everyone, >>>>> >>>>> I've updated the dialog packages with the changes we agreed to in >>>>> Minneapolis (removing CSeq and the Route-Set). >>>>> >>>>> I've also provided a detailed example of using the dialog >>>>> package for a >>>>> "shared-line" application. I apologize for my tardiness >>>>> here. I was >>>>> supposed to post something shortly after the meeting. I >>>>> any case, I >>>>> believe this demonstrates that the current syntax is at least >>>>> sufficient for the use cases we've discussed. I would like to = hear >>>>> from all of you if this does the trick. >>>>> >>>>> many thanks, >>>>> -rohan >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sipping mailing list >>>>> https://www1.ietf.org/mailman/listinfo/sipping >>>>> This list >>>>> is for NEW development of the application of SIP >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sip@ietf.org for new developments of core SIP >>>>> >>> >>> > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 26 14:18:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03380 for ; Thu, 26 Feb 2004 14:18:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwR15-0002bm-Ty for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 14:17:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QJHpwL010020 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 14:17:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwR15-0002bW-Mt for sipping-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 14:17:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03363 for ; Thu, 26 Feb 2004 14:17:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwR13-000160-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 14:17:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwR06-00010V-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 14:16:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwQzN-0000us-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 14:16:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwQzK-0002Ha-8S; Thu, 26 Feb 2004 14:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwQz3-0002G8-MV for sipping@optimus.ietf.org; Thu, 26 Feb 2004 14:15:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03310 for ; Thu, 26 Feb 2004 14:15:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwQz1-0000u2-00 for sipping@ietf.org; Thu, 26 Feb 2004 14:15:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwQy6-0000pZ-00 for sipping@ietf.org; Thu, 26 Feb 2004 14:14:47 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AwQxU-0000gg-00 for sipping@ietf.org; Thu, 26 Feb 2004 14:14:09 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTP00K70H0DSF@firewall.mci.com> for sipping@ietf.org; Thu, 26 Feb 2004 19:05:01 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTP00K01H054L@pmismtp02.mcilink.com>; Thu, 26 Feb 2004 19:05:01 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.143.198]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTP00J8AH09SM@pmismtp02.mcilink.com>; Thu, 26 Feb 2004 19:04:59 +0000 (GMT) Date: Thu, 26 Feb 2004 13:04:56 -0600 From: Alan Johnston Subject: Re: [Sipping] Conferencing for UAs In-reply-to: <403DE2CD.1060708@ericsson.com> X-Sender: Alan.Johnston@pop.mcit.com To: Gonzalo Camarillo Cc: hisham.khartabil@nokia.com, sipping@ietf.org, oritl@microsoft.com, Miguel.An.Garcia@nokia.com Message-id: <5.2.1.1.0.20040226125734.027ae008@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <5.2.1.1.0.20040225092901.0288fdb0@pop.mcit.com> <5.2.1.1.0.20040224084212.02819ef8@pop.mcit.com> <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB7017977C9@esebe019.ntc.nokia.com> <5.2.1.1.0.20040224084212.02819ef8@pop.mcit.com> <5.2.1.1.0.20040225092901.0288fdb0@pop.mcit.com> Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 02:13 PM 2/26/2004 +0200, Gonzalo Camarillo wrote: >Alan, > >I agree with you that we do not want to change the conferencing framework >at this point in time (I already said in my previous mail that I >understood that my comments related to this came too late). Still, I found >the discussion useful to understand your point of view. Gonzalo, Glad to hear that. I'd be happy to think about how to extend the conferencing work to cover the exploder scenarios you are proposing with MESSAGE, INVITE, and even REFER. With the current drafts, I have a hard time understanding how to do this, but I look forward to clarifications. The SUBSCRIBE exploder does not seem to have any conferencing semantics, but seems to be a SIMPLE application since it is tightly coupled to the presence application. Thanks, Alan Johnston MCI sip:alan@sipstation.com >In any event, the topic I am interested in is the creation of different >resources (identified by URIs) by a single request. In particular, how to >communicate those URIs to the UAC. (I sent separate comments on Hisham's >draft.) > >I hope we can discuss these issues in Korea. > >Thanks, > >Gonzalo > > >Alan Johnston wrote: > >>At 09:47 AM 2/25/2004 +0200, Gonzalo Camarillo wrote: >> >>>Hi Alan, >>> >>>I understand that my comments come late in the game and that it might be >>>impossible to change the conferencing framework at this point. In any >>>event, I do not agree with your statement below: >>> >>>>No - this is the problem. You are looking at your single narrow >>>>application. >>> >>> >>>I believe I am actually looking at a much wider range of applications >>>than just conferencing. So, to me, the problem is that the conferencing >>>framework is too focused on a "single narrow application"; conferencing. >> >>Gonzalo, >>If you are saying that some of your exploder services do not have a >>conferencing component, then I agree. Some of the exploder services seem >>to just be a "request to fork" to a set of URIs. Others definitely have >>conferencing semantics. The ones with conferencing semantics, I believe, >>can be, and should be modeled using the conferencing framework. >>The problem is that each method seems to have a different set of >>semantics as to what exploding that method means - INVITE is handled >>differently from SUBSCRIBE, from MESSAGE. From a high level, exploders >>may seem to be a consistent set of services. However, as I delve into >>the details and think about call flows (something absent from any of the >>exploder drafts), a different story emerges. >>I think we need to explore exactly the services and call flows that are >>being envisioned for exploders before proposing major changes to our >>conferencing framework, which I believe is well understood and documented. >> >>>In a conferencing service, there is a single resource created by the >>>initial INVITE; a conference. That's why the server can use the Contact >>>header field to send it back to the UAC. If you think of services that >>>create more than one resource (e.g., an explosion and a conference), the >>>server may not want to use the same URI for both. Moreover, >>>conceptually, is is not a good thing to use the same URI to identify >>>both resources. >> >>As Paul has pointed out - they are the same resource. Additionally, it >>is a trivial SIP routing issue to fix this - many proxies do method-based >>request routing - that would completely solve your problem of sending >>SUBSCRIBEs to a different UA than the initial request. >> >>>So, my main concern is the semantics overload of the Contact header. (We >>>abused this header when design REGISTER as well, by the way. That's why >>>I do not want to do it again.) >>> >>>In my opinion, the Contact header is the URI where you send subsequent >>>requests within the dialog. If the server wants to tell the client that >>>a resource (e.g., a conference) has been created, it can use a different >>>header to include the URI of such a resource. Note that, if you want >>>both URIs to be the same (like in the conferencing case), you can do it. >>> >>>Contact: sip:1234@a.com;isfocus >>>Resource: sip:1234@a.com;isfocus >>> >>>An entity receiving these headers would use the URI in the Contact >>>header to send subsequent requests *within* the dialog, and the URI in >>>the other header to send requests *outside* that dialog (e.g., SUBSCRIBE >>>to the conference package). >> >>No. A GRUU should be used in the Contact, and its routing is valid >>outside the dialog. >> >>>In brief, instead of sticking the conference URI in a Contact header and >>>label that URI with an isfocus parameter so that the UAC figures what is >>>going on, I find it more explicit to use a different header. Although, >>>as I said, I understand that this comment comes late and that may not be >>>useful at this point. >> >>I think much more work is needed before the working group can evaluate >>the exploders work and see how and if it fits in with existing concepts >>and approaches. >>Thanks, >>Alan Johnston >>MCI >>sip:alan@sipstation.com >> >>>Thanks, >>> >>>Gonzalo >>> >>> >>>This communication is confidential and intended solely for the >>>addressee(s). Any unauthorized review, use, disclosure or distribution >>>is prohibited. If you believe this message has been sent to you in >>>error, please notify the sender by replying to this transmission and >>>delete the message without disclosing it. Thank you. >>> >>>E-mail including attachments is susceptible to data corruption, >>>interruption, unauthorized amendment, tampering and viruses, and we only >>>send and receive e-mails on the basis that we are not liable for any >>>such corruption, interception, amendment, tampering or viruses or any >>>consequences thereof. >>> >>> >>>_______________________________________________ >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the application of SIP >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sip@ietf.org for new developments of core SIP > >-- >Gonzalo Camarillo Phone : +358 9 299 33 71 >Oy L M Ericsson Ab Mobile: +358 40 702 35 35 >Telecom R&D Fax : +358 9 299 30 52 >FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com >Finland http://www.hut.fi/~gonzalo > > >This communication is confidential and intended solely for the >addressee(s). Any unauthorized review, use, disclosure or distribution is >prohibited. If you believe this message has been sent to you in error, >please notify the sender by replying to this transmission and delete the >message without disclosing it. Thank you. > >E-mail including attachments is susceptible to data corruption, >interruption, unauthorized amendment, tampering and viruses, and we only >send and receive e-mails on the basis that we are not liable for any such >corruption, interception, amendment, tampering or viruses or any >consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Feb 26 17:49:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14428 for ; Thu, 26 Feb 2004 17:49:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwUJK-0004IJ-7O for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 17:48:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QMmsr2016504 for sipping-archive@odin.ietf.org; Thu, 26 Feb 2004 17:48:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwUJK-0004I7-0l for sipping-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 17:48:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14408 for ; Thu, 26 Feb 2004 17:48:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwUJH-0001Ar-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 17:48:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwUIK-00015T-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 17:47:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwUHY-00010l-00 for sipping-web-archive@ietf.org; Thu, 26 Feb 2004 17:47:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwUHV-00045T-BF; Thu, 26 Feb 2004 17:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwUHM-000457-PS for sipping@optimus.ietf.org; Thu, 26 Feb 2004 17:46:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14345 for ; Thu, 26 Feb 2004 17:46:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwUHK-000101-00 for sipping@ietf.org; Thu, 26 Feb 2004 17:46:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwUGV-0000vr-00 for sipping@ietf.org; Thu, 26 Feb 2004 17:46:00 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AwUGG-0000qS-00 for sipping@ietf.org; Thu, 26 Feb 2004 17:45:44 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 2092; Thu, 26 Feb 2004 17:45:28 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: [Fwd: RE: [Sipping] I-D ACTION:draft-ietf-sipping-kpml-02.txt] Date: Thu, 26 Feb 2004 17:45:14 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A1B8@zoe.office.snowshore.com> Thread-Topic: [Fwd: RE: [Sipping] I-D ACTION:draft-ietf-sipping-kpml-02.txt] Thread-Index: AcP66oS0Zw8ftexMSIakj2wwJ/uKQgArUIdw From: "Eric Burger" To: "Christer Holmberg (JO/LMF)" , Cc: Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Not registering does not stand in the way of using gruu: = draft-ietf-sip-gruu-01 offers that gruu generation is pure magic. It is = *suggested* to be done at a registrar to ensure routability, uniqueness, = etc. However, "other means" work just as well (just not as likely to = work globally). The gateway can generate its own gruu without = registering. That said, a typical deployment scenario for KPML is signaled digit = transport between media gateways/controllers and proxies in private = networks and IP Phones and IP PBXen in private networks. In these = scenarios, gruu doesn't buy you anything. Moreover, it would clearly be = "easier" to just make the request on the INVITE dialog, as that is = supposed to go to the right place by definition. So... What direction should we go with KPML? =20 Option 1: "You MUST use gruu (even if you fake gruu generation) and you MUST = create independent SUBSCRIBE dialogs for the subscription." If your UA = doesn't support gruu, you can't use KPML. If you are in the gateway or = IP PBX scenario, feel free to cheat at your own risk. My guess is IP = PBX guys will make this optimization as a proprietary (not necessarily = interoperable) extension. Option 2: "You SHOULD use gruu and SHOULD create independent SUBSCRIBE dialogs for = the subscription." KPML keeps the documentation for how to do the = subscription on the INVITE dialog. KPML documents the evils and dangers = of issuing subscriptions on INVITE dialogs. The problem here is there = is no protocol way of knowing for certain that reusing the INVITE dialog = will work. You only know from your network topology whether it is a = good idea or not. The good news is for the scenarios described above, = it will work. > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, February 24, 2004 10:26 AM > To: Eric Burger; 'jdrosen@dynamicsoft.com'; 'sipping@ietf.org' > Subject: [Fwd: RE: [Sipping] I-D=20 > ACTION:draft-ietf-sipping-kpml-02.txt] >=20 >=20 >=20 > Hi, >=20 > I guess this is a clarification question on kpml, as well as=20 > on gruu (and functions where gruu is used) in general. >=20 > If you have a node that doesn't register, but eg wants to use=20 > kpml (a gateway, for example), could it generate the gruu on=20 > its own, or is it "mandated" to use the register mechanism?=20 > If the register mechanism is not used, are there any issues=20 > which could come up? >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland >=20 >=20 >=20 >=20 >=20 > > -------- Original Message -------- > > Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-kpml-02.txt > > Date: Mon, 23 Feb 2004 17:34:22 -0500 > > From: Eric Burger > > To: Jonathan Rosenberg , > >=20 > > Yep, yep, yep, we can (and will) use GRUU. > >=20 > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Thursday, February 05, 2004 2:46 AM > > > To: sipping@ietf.org > > > Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-kpml-02.txt > > >=20 > > >=20 > > > Eric, > > >=20 > > > The draft talks about sending the subscribe requests on the=20 > > > same dialog=20 > > > as the INVITE. For many reasons that have been discussed ad=20 > > > nauseam on=20 > > > the list, dialog sharing is a bad idea. GRUU provides a=20 > > solution that=20 > > > does not require dialog sharing. As I recall, there was=20 > > discussion on=20 > > > this point in the last ietf, and this seemed to be the=20 > > > preferred direction. > > >=20 > > > Is there any reason we cant change this to use gruu's rather=20 > > > than dialog=20 > > > sharing? > > >=20 > > > Also, you are missing the IANA registration for the kpml=20 > > > event package. > > >=20 > > > Thanks, > > > Jonathan R. > > >=20 > > > Internet-Drafts@ietf.org wrote: > > >=20 > > > > A New Internet-Draft is available from the on-line=20 > > > Internet-Drafts directories. > > > > This draft is a work item of the Session Initiation=20 > > > Proposal Investigation Working Group of the IETF. > > > >=20 > > > > Title : Keypad Stimulus Protocol (KPML) > > > > Author(s) : E. Burger > > > > Filename : draft-ietf-sipping-kpml-02.txt > > > > Pages : 42 > > > > Date : 2004-2-4 > > > > =09 > > > > The Key Press Stimulus Protocol uses the SIP SUBSCRIBE/NOTIFY > > > > mechanism and Keypad Markup Language (KPML) to provide=20 > > > instructions > > > > to SIP User Agents for the reporting of user key presses. > > > >=20 > > > > A URL for this Internet-Draft is: > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-02.txt > > > >=20 > > > > To remove yourself from the IETF Announcement list, send a=20 > > > message to=20 > > > > ietf-announce-request with the word unsubscribe in the body=20 > > > of the message. > > > >=20 > > > > Internet-Drafts are also available by anonymous FTP. Login=20 > > > with the username > > > > "anonymous" and a password of your e-mail address. After=20 > > logging in, > > > > type "cd internet-drafts" and then > > > > "get draft-ietf-sipping-kpml-02.txt". > > > >=20 > > > > A list of Internet-Drafts directories can be found in > > > > http://www.ietf.org/shadow.html=20 > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >=20 > > > >=20 > > > > Internet-Drafts can also be obtained by e-mail. > > > >=20 > > > > Send a message to: > > > > mailserv@ietf.org. > > > > In the body type: > > > > "FILE /internet-drafts/draft-ietf-sipping-kpml-02.txt". > > > > =09 > > > > NOTE: The mail server at ietf.org can return the document in > > > > MIME-encoded form by using the "mpack" utility.=20 > To use this > > > > feature, insert the command "ENCODING mime"=20 > before the "FILE" > > > > command. To decode the response(s), you will=20 > need "munpack" or > > > > a MIME-compliant mail reader. Different MIME-compliant=20 > > > mail readers > > > > exhibit different behavior, especially when dealing with > > > > "multipart" MIME messages (i.e. documents which=20 > have been split > > > > up into multiple messages), so check your local=20 > documentation on > > > > how to manipulate these messages. > > > > =09 > > > > =09 > > > > Below is the data which will enable a MIME compliant mail reader > > > > implementation to automatically retrieve the ASCII=20 > version of the > > > > Internet-Draft. > > > >=20 > > >=20 > > > --=20 > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Technology Officer Parsippany, NJ=20 > > 07054-2711 > > > dynamicsoft > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > >=20 > > > _______________________________________________ > > > Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > >=20 > >=20 > >=20 > > --=20 > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=20 >=20 >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 27 02:06:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11186 for ; Fri, 27 Feb 2004 02:06:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awc4b-000195-65 for sipping-archive@odin.ietf.org; Fri, 27 Feb 2004 02:06:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R76Cxf004363 for sipping-archive@odin.ietf.org; Fri, 27 Feb 2004 02:06:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awc4Z-000186-6d for sipping-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 02:06:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10476 for ; Fri, 27 Feb 2004 02:06:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awc4V-0003bG-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 02:06:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awc3W-0003Sr-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 02:05:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awc2X-0003JM-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 02:04:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awc2U-0000EF-PU; Fri, 27 Feb 2004 02:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awc1t-0008Td-St for sipping@optimus.ietf.org; Fri, 27 Feb 2004 02:03:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07420 for ; Fri, 27 Feb 2004 02:03:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awc1q-0003D4-00 for sipping@ietf.org; Fri, 27 Feb 2004 02:03:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awc11-00034Y-00 for sipping@ietf.org; Fri, 27 Feb 2004 02:02:33 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Awbzu-0002w6-01 for sipping@ietf.org; Fri, 27 Feb 2004 02:01:22 -0500 Received: from mail3.pi.se ([195.7.64.137]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AwblE-00077N-4q for sipping@ietf.org; Fri, 27 Feb 2004 01:46:12 -0500 Received: from vit (h161n2fls31o265.telia.com [217.208.189.161]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id i1R6hRPI023497; Fri, 27 Feb 2004 07:43:30 +0100 (CET) From: "Gunnar Hellstrom" To: "Arnoud van Wijk" , "'Rosen, Brian'" , , Cc: , , , , Subject: RE: Betr.: [Sipping] ToIP Requirements Date: Fri, 27 Feb 2004 07:45:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200402261607.i1QG72rb012677@smtp.eweka.nl> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The INCOM group of the European commission made recommendations that the same emergency number shall be used for all kinds of terminals. It is dangerous to have different prefixes or other tricks in different countries. How shall you keep track of that if you are a visitor? From PSTN, it is only the old textphones that cause problems. A calling V.18 sends a very distinct calling identifier that can be catched by a gateway or an emergency centre and be properly handled. On the SIP side, the options are even better. I do not mean that all problems are solved by this statement, but I do not think that the prefix is the only solution, and I do not think we shall recommend it in connection to emergency. Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Arnoud van Wijk Sent: Thursday, February 26, 2004 4:57 PM To: 'Rosen, Brian'; 'Gunnar Hellstrom'; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; henry.sinnreich@mci.com; paulej@packetizer.com; gv@trace.wisc.edu Subject: RE: Betr.: [Sipping] ToIP Requirements Hello Brian, Yes you are right about that the PSTN cannot detect if it is a voice call or TDD/Textphone call. They are both audio. The PSTN would if it can detect it is a textphone call, route it to the text gateway. And transcode the call into T.140 over RTP as decribed in RFC 2793. This is for PSTNs which use IP to interconnect with other PSTNs or with any SIP telephones. So it is for analoge telephony into SIP telephony here. In the ToIP draft: http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-toip-01.txt A possible solution is a prefix for textphone users before dialling the selected number. It indeed would mean that you dial e.g. 600-112 instead 112 directly. Is that bad? I believe it is not. Most textphones have the emergency number pre programmed. And when textphone users have to use a pre-fix for any textphone call, then the same prefix before 112 or 911 will be fine. In the Netherlands, we have for emergency calls 800-112 instead of 112. It works fine, only almost no deaf users call 112, since they are then mostly in a situation where they do not have a textphone nearby! Maybe there are other solutions that allow the PSTN to detect that the incoming call is a textphone user and acts on it. For example it is possible to create a database where the PSTN can check if the incoming number is registered as a textphone. But using a text gateway to connect PSTN textphones/TDDs to ToIP is still the best solution, even the only solution in my opinion. There should be no attempts to transport the text telephone tones (e.g. Baudot) over the IP voice channel! I believe that will open Pandora's box. I am not a PSTN expert, and we can surely look into this matter to find a solution. Let it be prefix or any other solution that lets the PSTN immediately route the call to the text gateway. What do you PSTN people think? How would you tackle this problem? Your input will be very welcome. Greetz Arnoud Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 International text telephone: +31735588408 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: donderdag 26 februari 2004 15:36 To: 'Arnoud van Wijk'; 'Gunnar Hellstrom'; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; henry.sinnreich@mci.com; paulej@packetizer.com; gv@trace.wisc.edu Subject: RE: Betr.: [Sipping] ToIP Requirements Arnoud I do not believe this can work. A TDD user dials 112 or 911. Today, this will be routed directly to a "selective router" (a TDM switch) which sends the call to the correct Emergency Response Center. You can't insert a gateway, because you don't know that it's a TDD call until it is answered. To make it work, you would have to establish a special PSTN number for emergency TDD, which would route to the gateway, which would then call the ERC. I don't believe that is practical. Brian > -----Original Message----- > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > Sent: Thursday, February 26, 2004 9:17 AM > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > Gonzalo.Camarillo@ericsson.com; > sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > paulej@packetizer.com; gv@trace.wisc.edu > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > Hello Brian, > That is also why we need to look at the emergency call system. > This text gateway is only at the PSTN side, thus another > requirement for a > T140/RTP gateway for the PSTN is that when a local emergency number is > dialled (112, or 911 etc). That the gateway must be able to > receive that > call (even dropping existing calls if necessary). Such a call > is easy to > recognize as an emergency call. (PSTN side). > From that gateway on, it is all IP with RFC2793 interactive > text. And then > it is just all existing SIP as if it was from an IP end-point. > > This gives emergency centers an advantage, all calls will be > T.140/RTP, so > integration in their computer systems will be easy instead > being forced to > have analog textphones available for a textphone call. (or a > separate text > telephone emergency center). > > /Arnoud > > Drs. Arnoud A. T. van Wijk > Viataal > Research & Development > Afdeling RDS > Theerestraat 42 > 5271 GD Sint-Michielsgestel > The Netherlands. > Mobile: +31651921948 > International text telephone: +31735588408 > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: donderdag 26 februari 2004 15:04 > To: 'Arnoud van Wijk'; 'Gunnar Hellstrom'; > Gonzalo.Camarillo@ericsson.com; > sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > paulej@packetizer.com; gv@trace.wisc.edu > Subject: RE: Betr.: [Sipping] ToIP Requirements > > Arnoud > > Generally, you don't want to rely on very many SIP elements > to complete > an emergency call. Present systems accept TDD at all answering > points because they don't know before the calls is answered that it > is a TDD call. I certainly don't want the user to have to do anything > other than dial his local emergency number, or complete a device > specific key sequence to complete an emergency call, and I don't > want a gateway busy to prevent an emergency call. > > Brian > > > -----Original Message----- > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > Sent: Thursday, February 26, 2004 6:07 AM > > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > > Gonzalo.Camarillo@ericsson.com; > > sipping@ietf.org > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > henry.sinnreich@mci.com; > > paulej@packetizer.com; gv@trace.wisc.edu > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > Actually, > > When using the text gateway, there is no need to detect the > > TDD/Analogue > > text telephone tones/signals. That is the job of the text gateway. > > > > And for the emergency calling. We have to look closely at this in > > combination with a text gateway. Possible behaviour/action. > > And possible > > action in SIP. > > > > Right now I cannot say what has to happen, I must study the > > emergency calls > > in depth. But as I see it, using the text gateway, all SIP > > originating and > > receiving emergency calls will be possible for any textphone user. > > > > Cheers > > > > Arnoud > > > > > > Drs. Arnoud A. T. van Wijk > > Viataal > > Research & Development > > Afdeling RDS > > Theerestraat 42 > > 5271 GD Sint-Michielsgestel > > The Netherlands. > > Mobile: +31651921948 > > International text telephone: +31735588408 > > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of > > Rosen, Brian > > Sent: woensdag 25 februari 2004 23:08 > > To: 'Gunnar Hellstrom'; A vWijk; Gonzalo.Camarillo@ericsson.com; > > sipping@ietf.org > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > henry.sinnreich@mci.com; > > paulej@packetizer.com; gv@trace.wisc.edu > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > I'm particularly interested in the last one, emergency calling. > > > > Given that you propose an appropriate SDP indicating > support for text, > > do you think there is anything else we need to do to in SIP > > to make this > > happen? I don't see anything. > > > > I know that the problem of using a legacy TDD device on any kind of > > adapter is as problematic as current TDD; the call will answered > > as if it was a voice call, the baudot/whatever tones will be > > detected, > > and the operator will look for text. > > Can't think of any way to make that better. > > > > Do note that language preference headers should be set!!! > > > > Brian > > > > > -----Original Message----- > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > Sent: Wednesday, February 25, 2004 4:54 PM > > > To: A vWijk; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > henry.sinnreich@mci.com; > > > paulej@packetizer.com; gv@trace.wisc.edu > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > I think PSTN textphone gateway invocation is one area where > > > we either need > > > protocol extensions, or need agreements on what current > > > mechanisms to use. > > > > > > Another is invocation of various kinds of relay services or > > > translation > > > services. > > > > > > A third is calling emergency services and reach positions > capable of > > > handling the type of communication that the user prefers. > > > > > > > > > > > > Gunnar > > > ------------------------------------------- > > > Gunnar Hellstrom > > > Omnitor AB > > > Renathvagen 2 > > > SE 121 37 Johanneshov > > > SWEDEN > > > +46 8 556 002 03 > > > Mob: +46 708 204 288 > > > www.omnitor.se > > > Gunnar.Hellstrom@Omnitor.se > > > -------------------------------------------- > > > > > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org > > > [mailto:sipping-admin@ietf.org]On Behalf Of > > > A vWijk > > > Sent: Tuesday, February 24, 2004 1:22 PM > > > To: Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > henry.sinnreich@mci.com; > > > gunnar.hellstrom@omnitor.se; paulej@packetizer.com; > > gv@trace.wisc.edu > > > Subject: Betr.: [Sipping] ToIP Requirements > > > > > > > > > Hello Gonzalo, > > > While there are device requirements in the text. Those > > > requirements and the > > > explanation on the different analogue text telephone systems > > > is included to > > > give the reader an understanding what kind of devices will > > > connect with > > > ToIP. And the need for the text gateways. And what the > > > different behaviour > > > can/may be compared to end to end IP devices. > > > The most important part will be the ToIP framwork and the > > > text gateways and > > > how such gateways will be used and work with the ToIP framework. > > > > > > There is a ToIP framework where a terminal uses streaming > > > text as defined in > > > RFC2793 to connect with any other Interactive > > > texting/real-time streaming > > > text device. > > > This can be end-to-end IP, and a direct T140/RTP stream is > > > established with > > > SIP. But in other cases, a text gateway must be used to allow > > > T.140/RTP to > > > connect with a non IP text telephony device. > > > It can be an analogue text telephone (TDD/TTY) that uses a > > > text gateway to > > > be able to understand RFC2793 text. (PSTN-IP) > > > It can be a mobile phone running GPRS that uses the text > gateway to > > > understand RFC2793 text. (this exist right NOW using SIP! And > > > those gateways > > > will be used in mobile networks this year!) > > > Or a mobile text telephone using CTM via the text gateway to > > > communicate > > > with RFC2793 text. > > > Or even one analogue text telephone connecting to another > > > analogue text > > > telephone in a different country, and the PSTN's use IP to > > > connect the call. > > > > > > The question is for example, how do we use that gateway from > > > the IP side? Is > > > it invisible for the IP side? Or do we need special > > > extensions in SIP to > > > that the IP terminal knows it is communicating with the > > > end-device through > > > the text gateway? > > > There may be a slightly different call setup flow when a text > > > gateway is > > > included. > > > Or additional SIP messages indicating gateway activity. When > > > you connect for > > > example to an analogue text telephone with an RFC2793 capable > > > IP terminal > > > the capabilities will be less then IP to IP terminal directly > > > (different > > > transmission speeds, half/full duplex etc). > > > Or what to do with emergency calls that are in RFC 2793 text only? > > > > > > That are requirements that will be defined and worked out in > > > this draft. > > > Also, we want to make everybody in SIP and SIPPING aware > > > about those text > > > gateways. So that complicated matters like how to send > analogue text > > > telephone text through a PSTN and connect with a SIP > > > telephone using RFC2793 > > > interactive texting. When using the text gateway, there is > > > then no need for > > > RFC 2833 events at the PSTN for text telephones. > > > > > > So, yes. I believe that this should be in the SIPPING WG. And > > > it will fit in > > > the charter - support for hearing-/speech-impaired calling. > > > > > > greetz > > > > > > Arnoud > > > > > > > > > > > > Drs. Arnoud A. T. van Wijk > > > Viataal > > > Research & Development > > > Afdeling RDS > > > Theerestraat 42 > > > 5271 GD Sint-Michielsgestel > > > The Netherlands. > > > Mobile: +31651921948 > > > International text telephone: +31735588408 > > > > > > >>> Gonzalo Camarillo > > > 24-02-04 10:21 >>> > > > Hello, > > > > > > the draft below provides a set of requirements for real-time > > > conversations using SIP. > > > http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-to > > ip-01.txt > > > > Nevertheless, I have found a lot of device requirements in > > the text, but > > I fail to understand which particular protocol requirements > we need to > > fulfill with new protocol extensions. > > > > While SIPPING is the right place to handle requirements > that will lead > > to new SIP protocol extensions, SIPPING may not be the > right place to > > deal with device requirements (e.g., text phones MUST have a > > display of > > at least 100 characters). > > > > Thanks, > > > > Gonzalo > > > > > > This communication is confidential and intended solely for > > the addressee(s). > > Any unauthorized review, use, disclosure or distribution is > > prohibited. If > > you believe this message has been sent to you in error, > > please notify the > > sender by replying to this transmission and delete the > message without > > disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data corruption, > > interruption, unauthorized amendment, tampering and viruses, > > and we only > > send and receive e-mails on the basis that we are not liable > > for any such > > corruption, interception, amendment, tampering or viruses or any > > consequences thereof. > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 27 02:17:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16994 for ; Fri, 27 Feb 2004 02:17:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcF9-0005RD-T5 for sipping-archive@odin.ietf.org; Fri, 27 Feb 2004 02:17:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R7H7a6020890 for sipping-archive@odin.ietf.org; Fri, 27 Feb 2004 02:17:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcF8-0005Qh-Qy for sipping-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 02:17:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16927 for ; Fri, 27 Feb 2004 02:17:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwcF5-0004ou-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 02:17:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwcE7-0004h6-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 02:16:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwcD7-0004Z3-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 02:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcD7-0004fj-Ar; Fri, 27 Feb 2004 02:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcCJ-0004Ou-UZ for sipping@optimus.ietf.org; Fri, 27 Feb 2004 02:14:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16618 for ; Fri, 27 Feb 2004 02:14:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwcCG-0004Uk-00 for sipping@ietf.org; Fri, 27 Feb 2004 02:14:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwcBQ-0004PN-00 for sipping@ietf.org; Fri, 27 Feb 2004 02:13:17 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AwcAj-0004Je-00 for sipping@ietf.org; Fri, 27 Feb 2004 02:12:33 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1R7CYAh005570 for ; Fri, 27 Feb 2004 08:12:34 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Feb 2004 08:12:22 +0100 Received: from ericsson.com (rvi2-92-31.sw.ericsson.se [153.88.92.31]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FXFBX14L; Fri, 27 Feb 2004 08:12:38 +0100 Message-ID: <403EEDD5.3060208@ericsson.com> Date: Fri, 27 Feb 2004 09:12:21 +0200 X-Sybari-Trust: 3e923ef1 c77f3eb6 c891ec11 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping CC: Dean Willis , Rohan Mahy Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Feb 2004 07:12:22.0423 (UTC) FILETIME=[0B615A70:01C3FD01] Content-Transfer-Encoding: 7bit Subject: [Sipping] Slides Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, those of you who will be presenting in any of the two SIPPING sessions, please, send us your slides so that we can make them available to everyone at: http://www.softarmor.com/sipping/meets/ietf59/slides/ Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 27 06:56:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26959 for ; Fri, 27 Feb 2004 06:56:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awgak-00030s-UK for sipping-archive@odin.ietf.org; Fri, 27 Feb 2004 06:55:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RBtglV011578 for sipping-archive@odin.ietf.org; Fri, 27 Feb 2004 06:55:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awgak-00030f-NZ for sipping-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 06:55:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26844 for ; Fri, 27 Feb 2004 06:55:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awgag-00029n-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 06:55:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwgZo-0001yh-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 06:54:46 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AwgYx-0001pU-03 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 06:53:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AwgNb-0002Vs-KZ for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 06:42:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwgNV-0002Vm-4B; Fri, 27 Feb 2004 06:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwgMk-0002VC-Ti for sipping@optimus.ietf.org; Fri, 27 Feb 2004 06:41:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26579 for ; Fri, 27 Feb 2004 06:41:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwgMg-0000wm-00 for sipping@ietf.org; Fri, 27 Feb 2004 06:41:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwgLn-0000se-00 for sipping@ietf.org; Fri, 27 Feb 2004 06:40:16 -0500 Received: from natsmtp01.rzone.de ([81.169.145.166]) by ietf-mx with esmtp (Exim 4.12) id 1AwgKr-0000m4-00 for sipping@ietf.org; Fri, 27 Feb 2004 06:39:17 -0500 Received: from RocknRoll (pD9516DEB.dip.t-dialin.net [217.81.109.235]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i1RBcPng026398; Fri, 27 Feb 2004 12:38:25 +0100 (MET) From: "Harry Behrens" To: "'Gonzalo Camarillo'" Cc: "'Henning Schulzrinne'" , "'Dean Willis'" , "'James M. Polk'" , , "'Rohan Mahy'" , Subject: AW: AW: AW: [Sipping] SIPPING Agenda, IETF 59 Date: Fri, 27 Feb 2004 12:40:05 +0100 Message-ID: <002701c3fd26$7268a0f0$2c00a8c0@RocknRoll> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: <403EEA44.7050106@ericsson.com> Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Gonzalo, understood. Regarding "Additional requests will be=20 > accomodated=20 > if time allows" how would that work? -h > -----Urspr=FCngliche Nachricht----- > Von: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Gesendet: Freitag, 27. Februar 2004 07:57 > An: Harry Behrens > Cc: 'Henning Schulzrinne'; 'Dean Willis'; 'James M. Polk';=20 > sipping@ietf.org; 'Rohan Mahy'; hgxs@cs.columbia.edu > Betreff: Re: AW: AW: [Sipping] SIPPING Agenda, IETF 59 >=20 >=20 > Harry, >=20 > our agenda is pretty much full at this point, and, as you know, we=20 > cannot allocate time for draft presentations. In any event,=20 > if there are=20 > any open issues that have been discussed in the mailing list that you=20 > would like to further discuss, we can draw the attention of the WG to=20 > your work. >=20 > Of course, as the agenda says, "Additional requests will be=20 > accomodated=20 > if time allows". >=20 > Thanks, >=20 > Gonzalo >=20 > Harry Behrens wrote: >=20 > > That too. > > However presenting the latest relevant AAA and Billing=20 > related drafts=20 > > seemed like a good idea in general. It appears to me to be=20 > a topic of=20 > > interest and I am not presumptuous enough to assume that my=20 > draft is=20 > > the only document worthy of attention in that field ;-) > >=20 > > So: if such a "track" would exist I would like to reqeust=20 > to have one=20 > > slot allocated to my draft. If however, the notion of such=20 > a track is=20 > > not agreeable I would probably just like to request a slot. > >=20 > >=20 > > Harry > >=20 > >=20 > >=20 > >>-----Urspr=FCngliche Nachricht----- > >>Von: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > >>Gesendet: Donnerstag, 26. Februar 2004 12:07 > >>An: Harry Behrens > >>Cc: 'Henning Schulzrinne'; 'Dean Willis'; 'James M. Polk';=20 > >>sipping@ietf.org; 'Rohan Mahy'; hgxs@cs.columbia.edu > >>Betreff: Re: AW: [Sipping] SIPPING Agenda, IETF 59 > >> > >> > >>Harry, > >> > >>do you mean that you would like to request a time slot to > >>present your=20 > >>draft in SIPPING? > >> > >>Gonzalo > >> > >>Harry Behrens wrote: > >> > >> > >>>May I suggest a SIP, AAA and Billing Track? > >>>I would assume this to be of interest as we are seeing tremendous > >>>growth in the number of companies entering the ITSP market=20 > >> > >>these days. > >> > >>>Regards, > >>> > >>> Harry > >>> > >>> > >>> > >>> > >>>>-----Urspr=FCngliche Nachricht----- > >>>>Von: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] Im=20 > >>>>Auftrag von Henning Schulzrinne > >>>>Gesendet: Dienstag, 24. Februar 2004 22:11 > >>>>An: Dean Willis > >>>>Cc: James M. Polk; sipping@ietf.org; Rohan Mahy; Gonzalo > >>>>Camarillo; hgxs@cs.columbia.edu > >>>>Betreff: Re: [Sipping] SIPPING Agenda, IETF 59 > >>>> > >>>> > >>>>Reversal is fine with me. > >>>> > >>>>Dean Willis wrote: > >>>> > >>>> > >>>> > >>>>>James M. Polk wrote: > >>>>> > >>>>> > >>>>> > >>>>>>At 01:02 PM 2/24/2004 -0600, Dean Willis wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Hyperlinked version at:=20 > >>>>>>>http://www.softarmor.com/sipping/meets/ietf59/agenda.html > >>>>>>> > >>>>>>>WEDNESDAY, March 3, 2004, 1300-1500, Crystal 3 > >>>>>>> > >>>>>>>1335 SIP Emergency > >>>>>>> Henning Schulzrinne > >>>>>>> draft-ietf-sipping-sos-00.txt > >>>>>>> draft-schulzrinne-sipping-emergency-arch-00.txt > >>>>>>>1345 Location Conveyance Requirements > >>>>>>> James Polk > >>>>>>> draft-ietf-sipping-location-requirements-00.txt > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>I believe these presentations should be reversed in order > >>>> > >>>>because the > >>>> > >>>> > >>>>>>main points of discussion in the Location Requirements=20 > ID are for=20 > >>>>>>Emergency location dealing with call routing by proxies, > >> > >>adding LI > >> > >>>>>>(location information) by the proxy (whether or not the UA > >>>> > >>>>inserted it > >>>> > >>>> > >>>>>>already) and the security of the LI in transit.=20 > Discussing these=20 > >>>>>>points after the Emer-Arch doc doesn't seem to make much > >>>> > >>>>sense due to > >>>> > >>>> > >>>>>>potential rehash while the appropriate presenter is not at > >>>> > >>>>the podium > >>>> > >>>> > >>>>>>(in either direction). > >>>>>> > >>>>>>comments? > >>>>> > >>>>> > >>>>>Works for me. Henning? > >>>>> > >>>>>-- > >>>>>Dean > >>>>> > >>>>>_______________________________________________ > >>>>>Sipping mailing list > >> > >>https://www1.ietf.org/mailman/listinfo/sipping > >> > >>>>>This list > >> > >>is for NEW development of the application of SIP Use > >> > >>>>>sip-implementors@cs.columbia.edu for questions on current sip Use > >>>>>sip@ietf.org for new developments of core SIP > >>>> > >>>>_______________________________________________ > >>>>Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > >>>>This list is for NEW development of the application of SIP Use > >>>>sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>>>sip@ietf.org for new developments of core SIP > >>> > >>> > >>--=20 > >>Gonzalo Camarillo Phone : +358 9 299 33 71 > >>Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > >>Telecom R&D Fax : +358 9 299 30 52 > >>FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > >>Finland http://www.hut.fi/~gonzalo > >> > >> > >>This communication is confidential and intended solely for > >>the addressee(s). Any unauthorized review, use, disclosure or=20 > >>distribution is prohibited. If you believe this message has=20 > >>been sent to you in error, please notify the sender by=20 > >>replying to this transmission and delete the message without=20 > >>disclosing it. Thank you. > >> > >>E-mail including attachments is susceptible to data > >>corruption, interruption, unauthorized amendment, tampering=20 > >>and viruses, and we only send and receive e-mails on the=20 > >>basis that we are not liable for any such corruption,=20 > >>interception, amendment, tampering or viruses or any=20 > >>consequences thereof. > >=20 > >=20 >=20 > --=20 > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 27 12:04:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14259 for ; Fri, 27 Feb 2004 12:04:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwlOu-0005x7-4W for sipping-archive@odin.ietf.org; Fri, 27 Feb 2004 12:03:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RH3lKp022866 for sipping-archive@odin.ietf.org; Fri, 27 Feb 2004 12:03:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwlOt-0005wj-DX for sipping-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 12:03:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14227 for ; Fri, 27 Feb 2004 12:03:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwlOs-0000wh-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 12:03:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwlO3-0000oa-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 12:02:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwlNA-0000fy-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 12:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwlMP-0005RB-IP; Fri, 27 Feb 2004 12:01:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwlLi-0005GH-2K for sipping@optimus.ietf.org; Fri, 27 Feb 2004 12:00:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14081 for ; Fri, 27 Feb 2004 12:00:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwlLg-0000XV-00 for sipping@ietf.org; Fri, 27 Feb 2004 12:00:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwlKc-0000Ju-00 for sipping@ietf.org; Fri, 27 Feb 2004 11:59:23 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AwlJR-00001z-00 for sipping@ietf.org; Fri, 27 Feb 2004 11:58:09 -0500 Received: from softarmor.com (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i1RGuasa006908; Fri, 27 Feb 2004 10:56:36 -0600 Message-ID: <403F76C4.5070807@softarmor.com> Date: Fri, 27 Feb 2004 10:56:36 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harry Behrens CC: "'Gonzalo Camarillo'" , "'Henning Schulzrinne'" , "'James M. Polk'" , sipping@ietf.org, "'Rohan Mahy'" , hgxs@cs.columbia.edu Subject: Re: AW: AW: AW: [Sipping] SIPPING Agenda, IETF 59 References: <002701c3fd26$7268a0f0$2c00a8c0@RocknRoll> In-Reply-To: <002701c3fd26$7268a0f0$2c00a8c0@RocknRoll> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Harry Behrens wrote: > Gonzalo, > > understood. Regarding "Additional requests will be > >>accomodated >>if time allows" > > > how would that work? It means if we get to the end of the agenda and still have time left, the chairs ask "Ok, we're at the end of the agenda. Anybody have anything else to talk about?", and you and other folks can pop up and say "I want to talk about . . .", and we judge the consensus of the room on what topic to talk about by priority. -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 27 12:26:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14985 for ; Fri, 27 Feb 2004 12:26:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwlkH-0007Y7-JK for sipping-archive@odin.ietf.org; Fri, 27 Feb 2004 12:25:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RHPra6029013 for sipping-archive@odin.ietf.org; Fri, 27 Feb 2004 12:25:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwlkH-0007Xs-Fo for sipping-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 12:25:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14977 for ; Fri, 27 Feb 2004 12:25:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwlkF-0003dH-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 12:25:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwljP-0003VX-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 12:25:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwliX-0003M2-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 12:24:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwliT-0007Fn-Eg; Fri, 27 Feb 2004 12:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awli9-0007E3-1Y for sipping@optimus.ietf.org; Fri, 27 Feb 2004 12:23:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14918 for ; Fri, 27 Feb 2004 12:23:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awli7-0003Kk-00 for sipping@ietf.org; Fri, 27 Feb 2004 12:23:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwlhL-0003Du-00 for sipping@ietf.org; Fri, 27 Feb 2004 12:22:51 -0500 Received: from natsmtp00.rzone.de ([81.169.145.165] helo=natsmtp00.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 1AwlgL-00035o-00 for sipping@ietf.org; Fri, 27 Feb 2004 12:21:50 -0500 Received: from RocknRoll (pD9516DE0.dip.t-dialin.net [217.81.109.224]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i1RHLLD1028889; Fri, 27 Feb 2004 18:21:21 +0100 (MET) From: "Harry Behrens" To: "'Dean Willis'" Cc: "'Gonzalo Camarillo'" , "'Henning Schulzrinne'" , "'James M. Polk'" , , "'Rohan Mahy'" Subject: AW: AW: AW: AW: [Sipping] SIPPING Agenda, IETF 59 Date: Fri, 27 Feb 2004 18:23:02 +0100 Message-ID: <004601c3fd56$5b383190$2c00a8c0@RocknRoll> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: <403F76C4.5070807@softarmor.com> Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Dean, understood. Thank you for the explanation. See you in Seoul. Harry > -----Urspr=FCngliche Nachricht----- > Von: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]=20 > Im Auftrag von Dean Willis > Gesendet: Freitag, 27. Februar 2004 17:57 > An: Harry Behrens > Cc: 'Gonzalo Camarillo'; 'Henning Schulzrinne'; 'James M.=20 > Polk'; sipping@ietf.org; 'Rohan Mahy'; hgxs@cs.columbia.edu > Betreff: Re: AW: AW: AW: [Sipping] SIPPING Agenda, IETF 59 >=20 >=20 > Harry Behrens wrote: > > Gonzalo, > >=20 > > understood. Regarding "Additional requests will be > >=20 > >>accomodated > >>if time allows" > >=20 > >=20 > > how would that work? >=20 > It means if we get to the end of the agenda and still have time left,=20 > the chairs ask "Ok, we're at the end of the agenda. Anybody have=20 > anything else to talk about?", and you and other folks can pop up and=20 > say "I want to talk about . . .", and we judge the consensus=20 > of the room=20 > on what topic to talk about by priority. >=20 > -- > Dean >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 27 16:27:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25330 for ; Fri, 27 Feb 2004 16:27:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwpVF-0006pa-HK for sipping-archive@odin.ietf.org; Fri, 27 Feb 2004 16:26:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RLQbxZ026254 for sipping-archive@odin.ietf.org; Fri, 27 Feb 2004 16:26:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwpVF-0006pN-Dw for sipping-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 16:26:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25302 for ; Fri, 27 Feb 2004 16:26:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwpVD-0000Pd-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 16:26:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwpUG-0000K9-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 16:25:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwpTn-0000FD-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 16:25:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwpTk-0006cl-5v; Fri, 27 Feb 2004 16:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwpTM-0006bp-9a for sipping@optimus.ietf.org; Fri, 27 Feb 2004 16:24:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25245 for ; Fri, 27 Feb 2004 16:24:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwpTK-0000EO-00 for sipping@ietf.org; Fri, 27 Feb 2004 16:24:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwpSN-00008t-00 for sipping@ietf.org; Fri, 27 Feb 2004 16:23:39 -0500 Received: from mail3.pi.se ([195.7.64.137] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AwpRp-00003F-00; Fri, 27 Feb 2004 16:23:06 -0500 Received: from vit (h161n2fls31o265.telia.com [217.208.189.161]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id i1RLKlQe009566; Fri, 27 Feb 2004 22:20:49 +0100 (CET) From: "Gunnar Hellstrom" To: , "Henning Schulzrinne" Cc: "Toip list" , "'Sipping@Ietf. Org'" Date: Fri, 27 Feb 2004 22:22:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id i1RLKlQe009566 Content-Transfer-Encoding: quoted-printable Subject: [Sipping] [sip] Comment to draft-agrawal-sip-h323-interworking-reqs-06.txt about text support Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable In section 6.1.5 of the sip-h323-interworking spec, there is a sentence: "The IWF SHOULD be able to map the common audio, video and application format names supported in H.323 to and from the equivalent RTP/AVP [RFC3550] names." It is good practice to always mention how the three main media of video, audio and text shall be handled in real time applications. audio and video are mentioned explicitly. It may not be evident to everybody that real time interactive text is capability declared in H.323 Annex G / H.245 by DataApplicationCapability.application =3D t140 So, in fact it is covered in the sentence requiring that "application" format namnes shall be mapped. The mapping should correspond to the RTP/AVP name text/t140 and corresponding names for inclusion of protection against loss. I seek your guidance how it can be made more clear that "text" capabiliti= es can be expressed in both H.323 and SIP systems and should be mapped. ( the spec is at http://www.ietf.org/internet-drafts/draft-agrawal-sip-h323-interworking-r= eqs -06.txt ) Regards Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Feb 27 18:40:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03841 for ; Fri, 27 Feb 2004 18:40:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwraE-0005oK-Tg for sipping-archive@odin.ietf.org; Fri, 27 Feb 2004 18:39:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RNds7e022332 for sipping-archive@odin.ietf.org; Fri, 27 Feb 2004 18:39:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwraE-0005o7-Nl for sipping-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 18:39:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03813 for ; Fri, 27 Feb 2004 18:39:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwraB-0000z6-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 18:39:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwrZI-0000s0-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 18:38:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwrYR-0000kN-00 for sipping-web-archive@ietf.org; Fri, 27 Feb 2004 18:38:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwrYP-0005Xq-Tk; Fri, 27 Feb 2004 18:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwrY6-0005RK-HI for sipping@optimus.ietf.org; Fri, 27 Feb 2004 18:37:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03686 for ; Fri, 27 Feb 2004 18:37:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwrY3-0000hp-00 for sipping@ietf.org; Fri, 27 Feb 2004 18:37:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwrXC-0000c0-00 for sipping@ietf.org; Fri, 27 Feb 2004 18:36:47 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AwrWU-0000Ox-00 for sipping@ietf.org; Fri, 27 Feb 2004 18:36:02 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i1RNYv0p000399; Fri, 27 Feb 2004 17:35:01 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <10MYQ34V>; Fri, 27 Feb 2004 17:34:57 -0600 Message-ID: <9ACE0CEE075B494096C86C23878BF85906A337@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Gonzalo Camarillo'" , sipping Cc: Dean Willis , Rohan Mahy , "James M. Polk" Subject: RE: [Sipping] WGLC for draft-ietf-sipping-reason-header-for-preem ption-00.txt Date: Fri, 27 Feb 2004 17:34:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 The document looks good to me at a skim, but I believe there are a couple of points of clarification that should be added to 4.2.1. First, I believe the label for the right-most bar in the diagram should be "UA2" instead of "UA3," if my understanding of the use case is correct. Secondly, it is not clear how the "Resource-Priority: 2" in the UA3-UA4 call comes into play. None of the UAs shown in this flow are privy to any of the SIP signaling that was used to establish the UA3-UA4 call. What would seem to matter is the RSVP priorities used to establish the call. Correct? This should probably be clarified in the text. /a > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Sunday, February 08, 2004 15:29 > To: sipping > Cc: Dean Willis; Rohan Mahy; James M. Polk > Subject: [Sipping] WGLC for > draft-ietf-sipping-reason-header-for-preemption-00.txt > > > Folks, > > we would like to announce the start of the WGLC for the > following draft. > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-reason- header-for-preemption-00.txt This WGLC will end on Feb 29th. Send your comments to this mailing list and to the author. Thanks, Gonzalo SIPPING co-chair This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sat Feb 28 17:34:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06839 for ; Sat, 28 Feb 2004 17:34:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxD1b-0008FI-94 for sipping-archive@odin.ietf.org; Sat, 28 Feb 2004 17:33:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SMXZlA031692 for sipping-archive@odin.ietf.org; Sat, 28 Feb 2004 17:33:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxD1b-0008F5-5U for sipping-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 17:33:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06832 for ; Sat, 28 Feb 2004 17:33:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxD1Y-0001sw-00 for sipping-web-archive@ietf.org; Sat, 28 Feb 2004 17:33:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxD0d-0001mZ-00 for sipping-web-archive@ietf.org; Sat, 28 Feb 2004 17:32:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxD08-0001g4-00 for sipping-web-archive@ietf.org; Sat, 28 Feb 2004 17:32:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxD06-00083w-5X; Sat, 28 Feb 2004 17:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxCzb-00083a-PS for sipping@optimus.ietf.org; Sat, 28 Feb 2004 17:31:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06753 for ; Sat, 28 Feb 2004 17:31:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxCzZ-0001ep-00 for sipping@ietf.org; Sat, 28 Feb 2004 17:31:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxCym-0001ZM-00 for sipping@ietf.org; Sat, 28 Feb 2004 17:30:40 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AxCyC-0001Sc-00 for sipping@ietf.org; Sat, 28 Feb 2004 17:30:04 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1SMU4YG012980 for ; Sat, 28 Feb 2004 23:30:04 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 28 Feb 2004 23:30:04 +0100 Received: from ericsson.com (rvi2-92-190.sw.ericsson.se [153.88.92.190]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFQ077C; Sat, 28 Feb 2004 23:30:25 +0100 Message-ID: <40411668.2060102@ericsson.com> Date: Sun, 29 Feb 2004 00:30:00 +0200 X-Sybari-Trust: a903b598 c77f3eb6 9bda65ea 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Rohan Mahy , hisham.khartabil@nokia.com, sipping@ietf.org Subject: Re: [Sipping] Conference policy URI References: <2038BCC78B1AD641891A0D1AE133DBB701797704@esebe019.ntc.nokia.com> <40293C6B.4060404@dynamicsoft.com> <26C87A2E-621D-11D8-9B6B-0003938AF740@cisco.com> <404036BC.9020001@dynamicsoft.com> In-Reply-To: <404036BC.9020001@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2004 22:30:04.0084 (UTC) FILETIME=[6919CF40:01C3FE4A] Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Jonathan wrote: > As for the expense of creating registries - I dont think we should let > current administrative difficulties preclude us from doing what we think > the right thing is. This is my view as well. Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sat Feb 28 18:28:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10400 for ; Sat, 28 Feb 2004 18:28:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxDsm-0001yN-4v for sipping-archive@odin.ietf.org; Sat, 28 Feb 2004 18:28:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SNSVMP007576 for sipping-archive@odin.ietf.org; Sat, 28 Feb 2004 18:28:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxDsl-0001y7-Lm for sipping-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 18:28:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10385 for ; Sat, 28 Feb 2004 18:28:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxDsh-00000f-00 for sipping-web-archive@ietf.org; Sat, 28 Feb 2004 18:28:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxDrn-0007is-00 for sipping-web-archive@ietf.org; Sat, 28 Feb 2004 18:27:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxDrJ-0007dj-00 for sipping-web-archive@ietf.org; Sat, 28 Feb 2004 18:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxDrK-0001er-SZ; Sat, 28 Feb 2004 18:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awip3-0006fb-9M for sipping@optimus.ietf.org; Fri, 27 Feb 2004 09:18:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03141 for ; Fri, 27 Feb 2004 09:18:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awip1-0002X2-00 for sipping@ietf.org; Fri, 27 Feb 2004 09:18:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awinj-0002CX-00 for sipping@ietf.org; Fri, 27 Feb 2004 09:17:15 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Awime-0001yZ-00 for sipping@ietf.org; Fri, 27 Feb 2004 09:16:08 -0500 Received: from bear.cs.columbia.edu (IDENT:FnVXS42hwXyl1qZ4af0jPqYVMM5nMem5@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i1REFmmS006911 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 27 Feb 2004 09:15:48 -0500 (EST) Received: from cs.columbia.edu (pool-138-89-104-237.mad.east.verizon.net [138.89.104.237]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i1REFkmi012635 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Feb 2004 09:15:47 -0500 Message-ID: <403F510E.8060801@cs.columbia.edu> Date: Fri, 27 Feb 2004 09:15:42 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Gunnar Hellstrom CC: Arnoud van Wijk , "'Rosen, Brian'" , Gonzalo.Camarillo@ericsson.com, sipping@ietf.org, rrroy@att.com, barry.dingle@bigfoot.com.au, henry.sinnreich@mci.com, paulej@packetizer.com, gv@trace.wisc.edu Subject: Re: Betr.: [Sipping] ToIP Requirements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gunnar Hellstrom wrote: > The INCOM group of the European commission made recommendations that the > same emergency number shall be used for all kinds of terminals. > It is dangerous to have different prefixes or other tricks in different > countries. How shall you keep track of that if you are a visitor? There are no different 'tricks'. Please read the 'sos' and emergency-arch drafts; we would appreciate comments, but general worry not grounded on actual proposals is somewhat less helpful. Indeed, the proposals improve on the current system in that - all countries will use the same identifier, sos@ - visitors can use their home and visited country identifiers - discovery of these identifiers is automated - callers MAY, but do not have to, indicate preferences for the kind of emergency service and the kind of media desired; the latter is most likely automatic, not something a user would type in (indeed, they can't) > >>From PSTN, it is only the old textphones that cause problems. A calling V.18 > sends a very distinct calling identifier that can be catched by a gateway or > an emergency centre and be properly handled. On the SIP side, the options > are even better. > > I do not mean that all problems are solved by this statement, but I do not > think that the prefix is the only solution, and I do not think we shall > recommend it in connection to emergency. As far as I can tell, nobody is recommending a 'prefix'. > > > Gunnar > > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sat Feb 28 18:29:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10417 for ; Sat, 28 Feb 2004 18:29:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxDsm-0001yc-AQ for sipping-archive@odin.ietf.org; Sat, 28 Feb 2004 18:28:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SNSWSL007592 for sipping-archive@odin.ietf.org; Sat, 28 Feb 2004 18:28:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxDsm-0001yM-4J for sipping-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 18:28:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10363 for ; Sat, 28 Feb 2004 18:28:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxDse-0007nr-00 for sipping-web-archive@ietf.org; Sat, 28 Feb 2004 18:28:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxDrl-0007ii-00 for sipping-web-archive@ietf.org; Sat, 28 Feb 2004 18:27:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxDrJ-0007di-00 for sipping-web-archive@ietf.org; Sat, 28 Feb 2004 18:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxDrJ-0001eM-Gv; Sat, 28 Feb 2004 18:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwVHO-0005kD-V5 for sipping@optimus.ietf.org; Thu, 26 Feb 2004 18:51:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17477 for ; Thu, 26 Feb 2004 18:50:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwVHL-0006yH-00 for sipping@ietf.org; Thu, 26 Feb 2004 18:50:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwVGP-0006tI-00 for sipping@ietf.org; Thu, 26 Feb 2004 18:49:59 -0500 Received: from voodoo.izone.net.au ([202.160.129.225]) by ietf-mx with esmtp (Exim 4.12) id 1AwVG3-0006oV-00 for sipping@ietf.org; Thu, 26 Feb 2004 18:49:36 -0500 Received: from Home (dialup-92.54.194.203.acc04-dryb-mel.comindico.com.au [203.194.54.92]) by voodoo.izone.net.au (Postfix) with SMTP id E606526F33; Fri, 27 Feb 2004 10:48:52 +1100 (EST) Message-ID: <002501c3fcc3$1430a360$5c36c2cb@Home> From: "Barry Dingle" To: "Rosen, Brian" , "'Arnoud van Wijk'" , "'Gunnar Hellstrom'" , , Cc: , , , , "Len Bytheway" , "Barry Dingle" References: <313680C9A886D511A06000204840E1CF070B646A@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: Betr.: [Sipping] ToIP Requirements Date: Fri, 27 Feb 2004 10:48:41 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, In Australia, we have a separate emergency number for Textphone users. It is '106' and is regulated by legislation. We have a separate '106' emergency call centre. This makes special support for a range of text services much easier. (See http://www.aceinfo.net.au/Services/NRS/Services/ers.html). I understand that this may be difficult to implement for historical reasons in some countries - but it is possible and works well. As an aside, we are seriously investigating a 'Text Server' to support a whole range of text interworking scenarios - and ToIP is planned to be supported in Stage 2. I believe that we will eventually move to a single emergency number - but not until we can easily and reliably identify text emergency calls. Cheers, Barry DINGLE Telecommunications Consultant Project Manager - ACIF Any-to-Any Text Connectivity Options WG Fellow of the University of Melbourne barry.dingle@bigfoot.com.au Mob: +61 (0)41 911 7578 Fixed: +61 (0)3 9725 3937 ----- Original Message ----- From: "Rosen, Brian" To: "'Arnoud van Wijk'" ; "'Gunnar Hellstrom'" ; ; Cc: ; ; ; ; Sent: Friday, February 27, 2004 1:36 AM Subject: RE: Betr.: [Sipping] ToIP Requirements > Arnoud > > I do not believe this can work. A TDD user dials 112 or 911. Today, this > will be routed directly to a "selective router" (a TDM switch) which sends > the > call to the correct Emergency Response Center. You can't insert a gateway, > because you don't know that it's a TDD call until it is answered. To make > it work, you would have to establish a special PSTN number for emergency > TDD, > which would route to the gateway, which would then call the ERC. I don't > believe that is practical. > > Brian > > > > > -----Original Message----- > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > Sent: Thursday, February 26, 2004 9:17 AM > > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > > Gonzalo.Camarillo@ericsson.com; > > sipping@ietf.org > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > henry.sinnreich@mci.com; > > paulej@packetizer.com; gv@trace.wisc.edu > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > Hello Brian, > > That is also why we need to look at the emergency call system. > > This text gateway is only at the PSTN side, thus another > > requirement for a > > T140/RTP gateway for the PSTN is that when a local emergency number is > > dialled (112, or 911 etc). That the gateway must be able to > > receive that > > call (even dropping existing calls if necessary). Such a call > > is easy to > > recognize as an emergency call. (PSTN side). > > From that gateway on, it is all IP with RFC2793 interactive > > text. And then > > it is just all existing SIP as if it was from an IP end-point. > > > > This gives emergency centers an advantage, all calls will be > > T.140/RTP, so > > integration in their computer systems will be easy instead > > being forced to > > have analog textphones available for a textphone call. (or a > > separate text > > telephone emergency center). > > > > /Arnoud > > > > Drs. Arnoud A. T. van Wijk > > Viataal > > Research & Development > > Afdeling RDS > > Theerestraat 42 > > 5271 GD Sint-Michielsgestel > > The Netherlands. > > Mobile: +31651921948 > > International text telephone: +31735588408 > > > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: donderdag 26 februari 2004 15:04 > > To: 'Arnoud van Wijk'; 'Gunnar Hellstrom'; > > Gonzalo.Camarillo@ericsson.com; > > sipping@ietf.org > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > henry.sinnreich@mci.com; > > paulej@packetizer.com; gv@trace.wisc.edu > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > Arnoud > > > > Generally, you don't want to rely on very many SIP elements > > to complete > > an emergency call. Present systems accept TDD at all answering > > points because they don't know before the calls is answered that it > > is a TDD call. I certainly don't want the user to have to do anything > > other than dial his local emergency number, or complete a device > > specific key sequence to complete an emergency call, and I don't > > want a gateway busy to prevent an emergency call. > > > > Brian > > > > > -----Original Message----- > > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > > Sent: Thursday, February 26, 2004 6:07 AM > > > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > > > Gonzalo.Camarillo@ericsson.com; > > > sipping@ietf.org > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > henry.sinnreich@mci.com; > > > paulej@packetizer.com; gv@trace.wisc.edu > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > Actually, > > > When using the text gateway, there is no need to detect the > > > TDD/Analogue > > > text telephone tones/signals. That is the job of the text gateway. > > > > > > And for the emergency calling. We have to look closely at this in > > > combination with a text gateway. Possible behaviour/action. > > > And possible > > > action in SIP. > > > > > > Right now I cannot say what has to happen, I must study the > > > emergency calls > > > in depth. But as I see it, using the text gateway, all SIP > > > originating and > > > receiving emergency calls will be possible for any textphone user. > > > > > > Cheers > > > > > > Arnoud > > > > > > > > > Drs. Arnoud A. T. van Wijk > > > Viataal > > > Research & Development > > > Afdeling RDS > > > Theerestraat 42 > > > 5271 GD Sint-Michielsgestel > > > The Netherlands. > > > Mobile: +31651921948 > > > International text telephone: +31735588408 > > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > On Behalf Of > > > Rosen, Brian > > > Sent: woensdag 25 februari 2004 23:08 > > > To: 'Gunnar Hellstrom'; A vWijk; Gonzalo.Camarillo@ericsson.com; > > > sipping@ietf.org > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > henry.sinnreich@mci.com; > > > paulej@packetizer.com; gv@trace.wisc.edu > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > I'm particularly interested in the last one, emergency calling. > > > > > > Given that you propose an appropriate SDP indicating > > support for text, > > > do you think there is anything else we need to do to in SIP > > > to make this > > > happen? I don't see anything. > > > > > > I know that the problem of using a legacy TDD device on any kind of > > > adapter is as problematic as current TDD; the call will answered > > > as if it was a voice call, the baudot/whatever tones will be > > > detected, > > > and the operator will look for text. > > > Can't think of any way to make that better. > > > > > > Do note that language preference headers should be set!!! > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > Sent: Wednesday, February 25, 2004 4:54 PM > > > > To: A vWijk; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > henry.sinnreich@mci.com; > > > > paulej@packetizer.com; gv@trace.wisc.edu > > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > > > I think PSTN textphone gateway invocation is one area where > > > > we either need > > > > protocol extensions, or need agreements on what current > > > > mechanisms to use. > > > > > > > > Another is invocation of various kinds of relay services or > > > > translation > > > > services. > > > > > > > > A third is calling emergency services and reach positions > > capable of > > > > handling the type of communication that the user prefers. > > > > > > > > > > > > > > > > Gunnar > > > > ------------------------------------------- > > > > Gunnar Hellstrom > > > > Omnitor AB > > > > Renathvagen 2 > > > > SE 121 37 Johanneshov > > > > SWEDEN > > > > +46 8 556 002 03 > > > > Mob: +46 708 204 288 > > > > www.omnitor.se > > > > Gunnar.Hellstrom@Omnitor.se > > > > -------------------------------------------- > > > > > > > > > > > > -----Original Message----- > > > > From: sipping-admin@ietf.org > > > > [mailto:sipping-admin@ietf.org]On Behalf Of > > > > A vWijk > > > > Sent: Tuesday, February 24, 2004 1:22 PM > > > > To: Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > henry.sinnreich@mci.com; > > > > gunnar.hellstrom@omnitor.se; paulej@packetizer.com; > > > gv@trace.wisc.edu > > > > Subject: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > > > Hello Gonzalo, > > > > While there are device requirements in the text. Those > > > > requirements and the > > > > explanation on the different analogue text telephone systems > > > > is included to > > > > give the reader an understanding what kind of devices will > > > > connect with > > > > ToIP. And the need for the text gateways. And what the > > > > different behaviour > > > > can/may be compared to end to end IP devices. > > > > The most important part will be the ToIP framwork and the > > > > text gateways and > > > > how such gateways will be used and work with the ToIP framework. > > > > > > > > There is a ToIP framework where a terminal uses streaming > > > > text as defined in > > > > RFC2793 to connect with any other Interactive > > > > texting/real-time streaming > > > > text device. > > > > This can be end-to-end IP, and a direct T140/RTP stream is > > > > established with > > > > SIP. But in other cases, a text gateway must be used to allow > > > > T.140/RTP to > > > > connect with a non IP text telephony device. > > > > It can be an analogue text telephone (TDD/TTY) that uses a > > > > text gateway to > > > > be able to understand RFC2793 text. (PSTN-IP) > > > > It can be a mobile phone running GPRS that uses the text > > gateway to > > > > understand RFC2793 text. (this exist right NOW using SIP! And > > > > those gateways > > > > will be used in mobile networks this year!) > > > > Or a mobile text telephone using CTM via the text gateway to > > > > communicate > > > > with RFC2793 text. > > > > Or even one analogue text telephone connecting to another > > > > analogue text > > > > telephone in a different country, and the PSTN's use IP to > > > > connect the call. > > > > > > > > The question is for example, how do we use that gateway from > > > > the IP side? Is > > > > it invisible for the IP side? Or do we need special > > > > extensions in SIP to > > > > that the IP terminal knows it is communicating with the > > > > end-device through > > > > the text gateway? > > > > There may be a slightly different call setup flow when a text > > > > gateway is > > > > included. > > > > Or additional SIP messages indicating gateway activity. When > > > > you connect for > > > > example to an analogue text telephone with an RFC2793 capable > > > > IP terminal > > > > the capabilities will be less then IP to IP terminal directly > > > > (different > > > > transmission speeds, half/full duplex etc). > > > > Or what to do with emergency calls that are in RFC 2793 text only? > > > > > > > > That are requirements that will be defined and worked out in > > > > this draft. > > > > Also, we want to make everybody in SIP and SIPPING aware > > > > about those text > > > > gateways. So that complicated matters like how to send > > analogue text > > > > telephone text through a PSTN and connect with a SIP > > > > telephone using RFC2793 > > > > interactive texting. When using the text gateway, there is > > > > then no need for > > > > RFC 2833 events at the PSTN for text telephones. > > > > > > > > So, yes. I believe that this should be in the SIPPING WG. And > > > > it will fit in > > > > the charter - support for hearing-/speech-impaired calling. > > > > > > > > greetz > > > > > > > > Arnoud > > > > > > > > > > > > > > > > Drs. Arnoud A. T. van Wijk > > > > Viataal > > > > Research & Development > > > > Afdeling RDS > > > > Theerestraat 42 > > > > 5271 GD Sint-Michielsgestel > > > > The Netherlands. > > > > Mobile: +31651921948 > > > > International text telephone: +31735588408 > > > > > > > > >>> Gonzalo Camarillo > > > > 24-02-04 10:21 >>> > > > > Hello, > > > > > > > > the draft below provides a set of requirements for real-time > > > > conversations using SIP. > > > > http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-to > > > ip-01.txt > > > > > > Nevertheless, I have found a lot of device requirements in > > > the text, but > > > I fail to understand which particular protocol requirements > > we need to > > > fulfill with new protocol extensions. > > > > > > While SIPPING is the right place to handle requirements > > that will lead > > > to new SIP protocol extensions, SIPPING may not be the > > right place to > > > deal with device requirements (e.g., text phones MUST have a > > > display of > > > at least 100 characters). > > > > > > Thanks, > > > > > > Gonzalo > > > > > > > > > This communication is confidential and intended solely for > > > the addressee(s). > > > Any unauthorized review, use, disclosure or distribution is > > > prohibited. If > > > you believe this message has been sent to you in error, > > > please notify the > > > sender by replying to this transmission and delete the > > message without > > > disclosing it. Thank you. > > > > > > E-mail including attachments is susceptible to data corruption, > > > interruption, unauthorized amendment, tampering and viruses, > > > and we only > > > send and receive e-mails on the basis that we are not liable > > > for any such > > > corruption, interception, amendment, tampering or viruses or any > > > consequences thereof. > > > > > > > > > _______________________________________________ > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > _______________________________________________ > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > > > _______________________________________________ > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > _______________________________________________ > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sat Feb 28 21:46:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17145 for ; Sat, 28 Feb 2004 21:46:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxGxZ-0003JT-UX for sipping-archive@odin.ietf.org; Sat, 28 Feb 2004 21:45:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T2jfud012736 for sipping-archive@odin.ietf.org; Sat, 28 Feb 2004 21:45:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxGxZ-0003JL-MN for sipping-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 21:45:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17140 for ; Sat, 28 Feb 2004 21:45:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxGxW-0004UO-00 for sipping-web-archive@ietf.org; Sat, 28 Feb 2004 21:45:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxGwb-0004Ox-00 for sipping-web-archive@ietf.org; Sat, 28 Feb 2004 21:44:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxGw3-0004JC-00 for sipping-web-archive@ietf.org; Sat, 28 Feb 2004 21:44:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxGvx-00034S-Te; Sat, 28 Feb 2004 21:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxGvV-000310-BY for sipping@optimus.ietf.org; Sat, 28 Feb 2004 21:43:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17054 for ; Sat, 28 Feb 2004 21:43:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxGvS-0004IC-00 for sipping@ietf.org; Sat, 28 Feb 2004 21:43:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxGuW-0004D9-00 for sipping@ietf.org; Sat, 28 Feb 2004 21:42:33 -0500 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 1AxGtn-00048d-00 for sipping@ietf.org; Sat, 28 Feb 2004 21:41:47 -0500 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id DAA11736 for ; Sun, 29 Feb 2004 03:44:36 +0100 (CET) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma011587; Sun, 29 Feb 04 03:43:31 +0100 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Sun, 29 Feb 2004 03:40:33 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Sun, 29 Feb 2004 03:40:24 +0100 From: "A vWijk" To: , , , Cc: , , , , , Subject: Betr.: Re: Betr.: [Sipping] ToIP Requirements Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Barry and others, the text server can actually be the text gateway described in the ToIP = draft. I think it is a good idea to communicate about those plans of the text = server, so that we can include all the requirements into the ToIP draft. About analogue textphones and PSTNs. The requirement should be that the = PSTN MUST be able to recognize an incoming call as an analogue text = telephone call (opposed to voice and fax). The PSTN MUST then invoke the = text gateway for further call handling. In this way, the analogue text = telephony is then immediately transcoded into RFC2793 interactive texting = (T.140/RTP). The emergency systems shouldn't need any special handling for analogue = textphones since it is pure SIP telephony from then on. Greetz Arnoud <<< "Barry Dingle" 29-02 02:34 >>> Brian, In Australia, we have a separate emergency number for Textphone users. It = is '106' and is regulated by legislation. We have a separate '106' emergency call centre. This makes special support for a range of text services much easier. (See http://www.aceinfo.net.au/Services/NRS/Services/ers.html). I understand that this may be difficult to implement for historical reasons in some countries - but it is possible and works well. As an aside, we are seriously investigating a 'Text Server' to support a whole range of text interworking scenarios - and ToIP is planned to be supported in Stage 2. I believe that we will eventually move to a single emergency number - but not until we can easily and reliably identify text emergency calls. Cheers, Barry DINGLE Telecommunications Consultant Project Manager - ACIF Any-to-Any Text Connectivity Options WG Fellow of the University of Melbourne barry.dingle@bigfoot.com.au Mob: +61 (0)41 911 7578 Fixed: +61 (0)3 9725 3937 ----- Original Message -----=20 From: "Rosen, Brian" To: "'Arnoud van Wijk'" ; "'Gunnar Hellstrom'" ; ; Cc: ; ; ; ; Sent: Friday, February 27, 2004 1:36 AM Subject: RE: Betr.: [Sipping] ToIP Requirements > Arnoud > > I do not believe this can work. A TDD user dials 112 or 911. Today, = this > will be routed directly to a "selective router" (a TDM switch) which = sends > the > call to the correct Emergency Response Center. You can't insert a gateway, > because you don't know that it's a TDD call until it is answered. To = make > it work, you would have to establish a special PSTN number for emergency > TDD, > which would route to the gateway, which would then call the ERC. I = don't > believe that is practical. > > Brian > > > > > -----Original Message----- > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > Sent: Thursday, February 26, 2004 9:17 AM > > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > > Gonzalo.Camarillo@ericsson.com; > > sipping@ietf.org > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > henry.sinnreich@mci.com; > > paulej@packetizer.com; gv@trace.wisc.edu > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > Hello Brian, > > That is also why we need to look at the emergency call system. > > This text gateway is only at the PSTN side, thus another > > requirement for a > > T140/RTP gateway for the PSTN is that when a local emergency number is > > dialled (112, or 911 etc). That the gateway must be able to > > receive that > > call (even dropping existing calls if necessary). Such a call > > is easy to > > recognize as an emergency call. (PSTN side). > > From that gateway on, it is all IP with RFC2793 interactive > > text. And then > > it is just all existing SIP as if it was from an IP end-point. > > > > This gives eme _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 02:54:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11663 for ; Sun, 29 Feb 2004 02:54:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLlp-0000Z5-Li for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 02:53:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T7rriI002170 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 02:53:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLlp-0000Yv-2G for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 02:53:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11659 for ; Sun, 29 Feb 2004 02:53:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxLll-0002uM-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 02:53:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxLks-0002os-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 02:52:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxLk6-0002iy-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 02:52:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLk4-0000HO-8D; Sun, 29 Feb 2004 02:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLjn-0000Fj-4Z for sipping@optimus.ietf.org; Sun, 29 Feb 2004 02:51:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11592 for ; Sun, 29 Feb 2004 02:51:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxLjj-0002gx-00 for sipping@ietf.org; Sun, 29 Feb 2004 02:51:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxLix-0002au-00 for sipping@ietf.org; Sun, 29 Feb 2004 02:50:56 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AxLi6-0002Nf-00 for sipping@ietf.org; Sun, 29 Feb 2004 02:50:02 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 29 Feb 2004 00:00:34 +0000 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 i1T7nV1m029025; Sat, 28 Feb 2004 23:49:31 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQT01855; Sat, 28 Feb 2004 23:49:29 -0800 (PST) In-Reply-To: <404036BC.9020001@dynamicsoft.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797704@esebe019.ntc.nokia.com> <40293C6B.4060404@dynamicsoft.com> <26C87A2E-621D-11D8-9B6B-0003938AF740@cisco.com> <404036BC.9020001@dynamicsoft.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: hisham.khartabil@nokia.com, sipping@ietf.org, Rohan Mahy From: Rohan Mahy Subject: Re: [Sipping] Conference policy URI Date: Sat, 28 Feb 2004 23:50:14 -0800 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit To summarize my position: - I'm fine adding a new Call-Info purpose - I don't think a registry of these purposes was or ever will be needed/"the right thing to do" - To that end, I would be happy to log an errata against 3261 to remove the statement about such a registry - Creating an unnecessary registry causes lots of people to lots of unnecessary work, and causes resentment toward the SIP and SIPPING working groups thanks, -rohan On Feb 27, 2004, at 10:35 PM, Jonathan Rosenberg wrote: > Call-Info purpose is not new. In fact, the idea of a registry for it > is not new either. RFC 3261 explicitly calls it out: > > 20.9 Call-Info > > The Call-Info header field provides additional information about the > caller or callee, depending on whether it is found in a request or > response. The purpose of the URI is described by the "purpose" > parameter. The "icon" parameter designates an image suitable as an > iconic representation of the caller or callee. The "info" parameter > describes the caller or callee in general, for example, through a > web > page. The "card" parameter provides a business card, for example, > in > vCard [36] or LDIF [37] formats. Additional tokens can be > registered > using IANA and the procedures in Section 27. > > > The problem is that we forgot (i.e. - a bug) to include the definition > of this registry in RFC 3261. The draft is merely correcting an error > in RFC3261. > > As for the expense of creating registries - I dont think we should let > current administrative difficulties preclude us from doing what we > think the right thing is. > > -Jonathan R. > > > Rohan Mahy wrote: >> Hi, >> I believe the SIPPING working group has come down with a bad case of >> Ianaus Registritus. This rare, but preventable disease is caused by >> trying to register every possible field or parameter mentioned in a >> set of standards track documents. It is highly contagious to other >> related working groups. Treatment consists of deleting IANA >> Registration sections until the symptoms subside. The patient should >> begin feeling better immediately. >> Seriously, I like the new Call-Info purpose, but I think the IANA >> Registry goes way too far overboard. Remember that there is an >> administrative and political cost to setting up new IANA Registries. >> thansk, >> -rohan >> On Feb 10, 2004, at 12:17 PM, Jonathan Rosenberg wrote: >>> Thanks for doing this. Some comments. >>> >>> Firstly, on the registry itself. You need to give clearer guidance >>> to IANA on the registry. I would suggest including a table that >>> shows how it should look like. You need to tell IANA what >>> information needs to be provided in future RFCs that register >>> additional values (value, RFC number, registrant, etc.). Please >>> take a look at rfc2434 >>> (ftp://ftp.rfc-editor.org/in-notes/rfc2434.txt). >>> >>> Secondly, on the "policy-uri" value - you need to specify, I think, >>> what the URI type is, and what the content is at that URI (at least >>> a mandatory to implement one) in order to get interoperability. >>> Unlike the other stuff, which is just rendered for user >>> information, this resource is processed by an automata, and I think >>> you need to say more about it. >>> >>> Thanks, >>> Jonathan R. >>> >>> hisham.khartabil@nokia.com wrote: >>> >>>> Thanks Jonathan. A draft has been submitted to the SIP WG. >>>> http://www.ietf.org/internet-drafts/draft-khartabil-sip-policy-uri- >>>> call-info-purpose-00.txt >>>> Regards, >>>> Hisham >>>> >>>>> -----Original Message----- >>>>> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>>>> Sent: 24.January.2004 04:44 >>>>> To: Khartabil Hisham (Nokia-TP/Helsinki) >>>>> Cc: sipping@ietf.org >>>>> Subject: Re: [Sipping] Conference policy URI >>>>> >>>>> >>>>> I think this is a reasonable usage of Call-Info. However, it can >>>>> only be done if a "purpose" tag value is registered with IANA, as >>>>> indicated by section 20.9. However, it ocurred to me, when reading >>>>> this, that we never set up an IANA registry for call-info purpose >>>>> tokens! Oops! Thats easily rectifiable; when the draft defining >>>>> the 'policy-uri' (or whatever its called) purpose tag is written, >>>>> it should also create the registry and register the other tokens >>>>> defined in rfc3261. >>>>> >>>>> -Jonathan R. >>>>> >>>>> hisham.khartabil@nokia.com wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> There was consensus on the XCON mailing list that the conference >>>>>> state event package needs to include in the notification the >>>>>> conference policy URI. >>>>>> >>>>>> There was also consensus that some participants may not want to >>>>>> subscribe to the conference package but would still like to learn >>>>>> the conference policy URI. In this case, it was suggested that the >>>>>> Call-info header carries such information. Perhaps the >>>>>> cc-conferencing draft can include examples of that. >>>>>> >>>>>> Thanks, Hisham >>>>>> >>>>>> _______________________________________________ Sipping mailing >>>>>> list https://www1.ietf.org/mailman/listinfo/sipping This list is >>>>>> for NEW development of the application of SIP Use >>>>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>>>> sip@ietf.org for new developments of core SIP >>>>>> >>>>> >>>>> -- >>>>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>>> Chief Technology Officer Parsippany, NJ >>>>> 07054-2711 >>>>> dynamicsoft >>>>> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>>>> http://www.jdrosen.net PHONE: (973) 952-5000 >>>>> http://www.dynamicsoft.com >>>>> >>>>> >>> >>> -- >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>> Chief Technology Officer Parsippany, NJ 07054-2711 >>> dynamicsoft >>> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>> http://www.jdrosen.net PHONE: (973) 952-5000 >>> http://www.dynamicsoft.com >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 08:21:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20907 for ; Sun, 29 Feb 2004 08:21:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQsf-0001do-Ms for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 08:21:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TDLHvo006302 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 08:21:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQsf-0001dZ-Hb for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 08:21:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20805 for ; Sun, 29 Feb 2004 08:21:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxQse-0001NL-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 08:21:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxQrb-0001Ce-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 08:20:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxQqg-00015R-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 08:19:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQqV-000145-UF; Sun, 29 Feb 2004 08:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQpX-0000zi-D3 for sipping@optimus.ietf.org; Sun, 29 Feb 2004 08:18:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20638 for ; Sun, 29 Feb 2004 08:18:02 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxQpW-0000zA-00 for sipping@ietf.org; Sun, 29 Feb 2004 08:18:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxQoe-0000tC-00 for sipping@ietf.org; Sun, 29 Feb 2004 08:17:09 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AxQo3-0000nH-00 for sipping@ietf.org; Sun, 29 Feb 2004 08:16:31 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1TDGOT07117; Sun, 29 Feb 2004 15:16:24 +0200 (EET) X-Scanned: Sun, 29 Feb 2004 15:16:14 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i1TDGECI020596; Sun, 29 Feb 2004 15:16:14 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00lBNJek; Sun, 29 Feb 2004 15:16:13 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1TDGDO23723; Sun, 29 Feb 2004 15:16:13 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 29 Feb 2004 15:16:13 +0200 Content-Class: urn:content-classes:message Subject: RE: [Sipping] Re: Conferencing for UAs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Feb 2004 15:16:12 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Sipping] Re: Conferencing for UAs Thread-Index: AcP72TYX1CKzGX0WROq/g8mljCTULgCnhJxQ To: , Cc: , , , X-OriginalArrivalTime: 29 Feb 2004 13:16:13.0562 (UTC) FILETIME=[34944DA0:01C3FEC6] Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, The benefit of having the same URI would be also that you could just = SUBSCRIBE to the conference state without even needing to join it via = INVITE. I think there could be some application use cases why you would = want to do this: for instance a user wants to join a conference only = when certain other user or certain amount of users are present. To do = this, the user should only need to know the single conference URI. (Supposedly you could find out the URI to subscribe to with OPTIONS too, = but why bother, if it could be the same.) Markus > -----Original Message----- > From: sipping-admin@ietf.org=20 > [mailto:sipping-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 25 February, 2004 21:48 > To: Gonzalo Camarillo > Cc: Garcia Miguel.An (Nokia-NRC/Helsinki); sipping@ietf.org; > alan.johnston@mci.com; oritl@microsoft.com > Subject: Re: [Sipping] Re: Conferencing for UAs >=20 >=20 >=20 > I think the same URI makes sense. At the core, there really is one=20 > resource here - the conference. All that differs is the=20 > methods that are=20 > invoked on it and how that resource behaves when users contact it.=20 > Subscribing to it and initiating a session to it are two different=20 > methods, but both against fundamentally the same resource. >=20 > -Jonathan R. >=20 > Gonzalo Camarillo wrote: >=20 > > Hi, > >=20 > >> Aren't we heading to defining a generic Associated-State=20 > header with > >> a "role" parameter that contains a value "transaction",=20 > "conference", > >> "xxx", etc... > >=20 > >=20 > > I actually do not care how we encode this information; in a=20 > header with=20 > > several parameters or in multiple headers (in any case, you=20 > may be right=20 > > that using a single header could be cleaner). > >=20 > > What I want to know is whether or not people think that it=20 > is worthwhile=20 > > keeping separate the URI used for the INVITE dialog and the one (or=20 > > ones) used for subscriptions to some piece of state that is=20 > associated=20 > > somehow with that dialog. My personal opinion is that we=20 > should keep=20 > > them separate. > >=20 > > Gonzalo > >=20 > >=20 > > This communication is confidential and intended solely for the=20 > > addressee(s). Any unauthorized review, use, disclosure or=20 > distribution=20 > > is prohibited. If you believe this message has been sent to you in=20 > > error, please notify the sender by replying to this=20 > transmission and=20 > > delete the message without disclosing it. Thank you. > >=20 > > E-mail including attachments is susceptible to data corruption,=20 > > interruption, unauthorized amendment, tampering and=20 > viruses, and we only=20 > > send and receive e-mails on the basis that we are not=20 > liable for any=20 > > such corruption, interception, amendment, tampering or=20 > viruses or any=20 > > consequences thereof. > >=20 > >=20 > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 08:21:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20922 for ; Sun, 29 Feb 2004 08:21:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQsg-0001eA-DY for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 08:21:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TDLIYU006324 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 08:21:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQsg-0001dv-8s for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 08:21:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20808 for ; Sun, 29 Feb 2004 08:21:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxQsf-0001NU-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 08:21:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxQrc-0001Cm-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 08:20:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxQqg-00015S-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 08:19:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQqT-00013E-VS; Sun, 29 Feb 2004 08:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQpV-0000zT-0J for sipping@optimus.ietf.org; Sun, 29 Feb 2004 08:18:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20629 for ; Sun, 29 Feb 2004 08:17:59 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxQpT-0000yn-00 for sipping@ietf.org; Sun, 29 Feb 2004 08:17:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxQoa-0000sm-00 for sipping@ietf.org; Sun, 29 Feb 2004 08:17:06 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1AxQns-0000n7-00 for sipping@ietf.org; Sun, 29 Feb 2004 08:16:20 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1TDGF728004; Sun, 29 Feb 2004 15:16:15 +0200 (EET) X-Scanned: Sun, 29 Feb 2004 15:16:07 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i1TDG7tw014017; Sun, 29 Feb 2004 15:16:07 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00O1jU1u; Sun, 29 Feb 2004 15:16:05 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1TDG4713138; Sun, 29 Feb 2004 15:16:04 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 29 Feb 2004 15:16:04 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 29 Feb 2004 15:16:03 +0200 Content-Class: urn:content-classes:message Subject: RE: [Sipping] Conferencing for UAs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Feb 2004 15:16:03 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Sipping] Conferencing for UAs Thread-Index: AcP8nXdjVMVCbLIKR7KbkF3C/KWp3QB2YCTw To: , Cc: , , , X-OriginalArrivalTime: 29 Feb 2004 13:16:03.0097 (UTC) FILETIME=[2E577890:01C3FEC6] Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I also hope there could be more clarity on the relationship between = exploders and conferencing work. Some thoughts below. One clear use case for exploders is the establishment of a "dial-out = ad-hoc" conference. One of Gonzalo's drafts proposes that the exploder = B2BUA (which in this case becomes a conference focus) could return to = the originating UA a reference (URI) to the list, after which the UA = could use e.g. XCAP to manage the list out-of-band. The idea seems to be = that the default format for this list indeed would be the XCAP resource = list. In conferencing framework this list clearly overlaps with the dial-out = list concept to be defined in CPCP. Also, if the semantics of removing a = user from the list will result in ejection of this user from the = conference, this list may overlap with some other functionality of CPCP = too. My proposal to make the exploders and CPCP compliant with each other = would be: - When the conference is established by invoking an exploder, the = conference server will use the exploder-list to populate a CPCP document = in such a way that its semantics match with what was done with the = exploder. - URI for this CPCP document is provided in 200 OK using the mechanisms = dicussed elsewhere (Call-info purpose, new header, ...). - Conference participants can thereafter make conference policy = operations by doing changes to this document, and the situation is as if = the conference was originally created by CPCP in the first place. =20 - If ad hoc list management via re-INVITEs is still allowed, there needs = to be a clear mapping how adding/removing list entries interacts with = the CPCP document. To enable this the CPCP semantics still need more clarity, and maybe = also adopting the XCAP resource list format for the possible dial-out = etc. lists in that document would help this mapping. (We could still keep the simple non-CPCP controllable conference case, = where the only manipulated object would be a simple resource list. In = this case access lists and other such features woould not be supported.) = Do people think that this would be feasible? Or would we be getting to = an interaction that is too complex to model? In general I think there's = room for both exploders AND CPCP, so it would be important to specify = how they interwork. Regards, Markus > -----Original Message----- > From: sipping-admin@ietf.org=20 > [mailto:sipping-admin@ietf.org]On Behalf Of > ext Alan Johnston > Sent: 26 February, 2004 21:05 > To: Gonzalo Camarillo > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); sipping@ietf.org; > oritl@microsoft.com; Garcia Miguel.An (Nokia-NRC/Helsinki) > Subject: Re: [Sipping] Conferencing for UAs >=20 >=20 >=20 > At 02:13 PM 2/26/2004 +0200, Gonzalo Camarillo wrote: > >Alan, > > > >I agree with you that we do not want to change the=20 > conferencing framework=20 > >at this point in time (I already said in my previous mail that I=20 > >understood that my comments related to this came too late).=20 > Still, I found=20 > >the discussion useful to understand your point of view. >=20 > Gonzalo, >=20 > Glad to hear that. I'd be happy to think about how to extend the=20 > conferencing work to cover the exploder scenarios you are=20 > proposing with=20 > MESSAGE, INVITE, and even REFER. With the current drafts,=20 > I have a hard=20 > time understanding how to do this, but I look forward to=20 > clarifications. The SUBSCRIBE exploder does not seem to have any=20 > conferencing semantics, but seems to be a SIMPLE application=20 > since it is=20 > tightly coupled to the presence application. >=20 > Thanks, > Alan Johnston > MCI > sip:alan@sipstation.com >=20 >=20 > >In any event, the topic I am interested in is the creation=20 > of different=20 > >resources (identified by URIs) by a single request. In=20 > particular, how to=20 > >communicate those URIs to the UAC. (I sent separate comments=20 > on Hisham's=20 > >draft.) > > > >I hope we can discuss these issues in Korea. > > > >Thanks, > > > >Gonzalo > > > > > >Alan Johnston wrote: > > > >>At 09:47 AM 2/25/2004 +0200, Gonzalo Camarillo wrote: > >> > >>>Hi Alan, > >>> > >>>I understand that my comments come late in the game and=20 > that it might be=20 > >>>impossible to change the conferencing framework at this=20 > point. In any=20 > >>>event, I do not agree with your statement below: > >>> > >>>>No - this is the problem. You are looking at your single narrow=20 > >>>>application. > >>> > >>> > >>>I believe I am actually looking at a much wider range of=20 > applications=20 > >>>than just conferencing. So, to me, the problem is that the=20 > conferencing=20 > >>>framework is too focused on a "single narrow application";=20 > conferencing. > >> > >>Gonzalo, > >>If you are saying that some of your exploder services do not have a=20 > >>conferencing component, then I agree. Some of the exploder=20 > services seem=20 > >>to just be a "request to fork" to a set of URIs. Others=20 > definitely have=20 > >>conferencing semantics. The ones with conferencing=20 > semantics, I believe,=20 > >>can be, and should be modeled using the conferencing framework. > >>The problem is that each method seems to have a different set of=20 > >>semantics as to what exploding that method means - INVITE=20 > is handled=20 > >>differently from SUBSCRIBE, from MESSAGE. From a high=20 > level, exploders=20 > >>may seem to be a consistent set of services. However, as I=20 > delve into=20 > >>the details and think about call flows (something absent=20 > from any of the=20 > >>exploder drafts), a different story emerges. > >>I think we need to explore exactly the services and call=20 > flows that are=20 > >>being envisioned for exploders before proposing major=20 > changes to our=20 > >>conferencing framework, which I believe is well understood=20 > and documented. > >> > >>>In a conferencing service, there is a single resource=20 > created by the=20 > >>>initial INVITE; a conference. That's why the server can=20 > use the Contact=20 > >>>header field to send it back to the UAC. If you think of=20 > services that=20 > >>>create more than one resource (e.g., an explosion and a=20 > conference), the=20 > >>>server may not want to use the same URI for both. Moreover,=20 > >>>conceptually, is is not a good thing to use the same URI=20 > to identify=20 > >>>both resources. > >> > >>As Paul has pointed out - they are the same resource. =20 > Additionally, it=20 > >>is a trivial SIP routing issue to fix this - many proxies=20 > do method-based=20 > >>request routing - that would completely solve your problem=20 > of sending=20 > >>SUBSCRIBEs to a different UA than the initial request. > >> > >>>So, my main concern is the semantics overload of the=20 > Contact header. (We=20 > >>>abused this header when design REGISTER as well, by the=20 > way. That's why=20 > >>>I do not want to do it again.) > >>> > >>>In my opinion, the Contact header is the URI where you=20 > send subsequent=20 > >>>requests within the dialog. If the server wants to tell=20 > the client that=20 > >>>a resource (e.g., a conference) has been created, it can=20 > use a different=20 > >>>header to include the URI of such a resource. Note that,=20 > if you want=20 > >>>both URIs to be the same (like in the conferencing case),=20 > you can do it. > >>> > >>>Contact: sip:1234@a.com;isfocus > >>>Resource: sip:1234@a.com;isfocus > >>> > >>>An entity receiving these headers would use the URI in the Contact=20 > >>>header to send subsequent requests *within* the dialog,=20 > and the URI in=20 > >>>the other header to send requests *outside* that dialog=20 > (e.g., SUBSCRIBE=20 > >>>to the conference package). > >> > >>No. A GRUU should be used in the Contact, and its routing is valid=20 > >>outside the dialog. > >> > >>>In brief, instead of sticking the conference URI in a=20 > Contact header and=20 > >>>label that URI with an isfocus parameter so that the UAC=20 > figures what is=20 > >>>going on, I find it more explicit to use a different=20 > header. Although,=20 > >>>as I said, I understand that this comment comes late and=20 > that may not be=20 > >>>useful at this point. > >> > >>I think much more work is needed before the working group=20 > can evaluate=20 > >>the exploders work and see how and if it fits in with=20 > existing concepts=20 > >>and approaches. > >>Thanks, > >>Alan Johnston > >>MCI > >>sip:alan@sipstation.com > >> > >>>Thanks, > >>> > >>>Gonzalo > >>> > >>> > >>>This communication is confidential and intended solely for the=20 > >>>addressee(s). Any unauthorized review, use, disclosure or=20 > distribution=20 > >>>is prohibited. If you believe this message has been sent to you in=20 > >>>error, please notify the sender by replying to this=20 > transmission and=20 > >>>delete the message without disclosing it. Thank you. > >>> > >>>E-mail including attachments is susceptible to data corruption,=20 > >>>interruption, unauthorized amendment, tampering and=20 > viruses, and we only=20 > >>>send and receive e-mails on the basis that we are not=20 > liable for any=20 > >>>such corruption, interception, amendment, tampering or=20 > viruses or any=20 > >>>consequences thereof. > >>> > >>> > >>>_______________________________________________ > >>>Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > >>>This list is for NEW development of the application of SIP > >>>Use sip-implementors@cs.columbia.edu for questions on current sip > >>>Use sip@ietf.org for new developments of core SIP > > > >-- > >Gonzalo Camarillo Phone : +358 9 299 33 71 > >Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > >Telecom R&D Fax : +358 9 299 30 52 > >FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > >Finland http://www.hut.fi/~gonzalo > > > > > >This communication is confidential and intended solely for the=20 > >addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is=20 > >prohibited. If you believe this message has been sent to you=20 > in error,=20 > >please notify the sender by replying to this transmission=20 > and delete the=20 > >message without disclosing it. Thank you. > > > >E-mail including attachments is susceptible to data corruption,=20 > >interruption, unauthorized amendment, tampering and viruses,=20 > and we only=20 > >send and receive e-mails on the basis that we are not liable=20 > for any such=20 > >corruption, interception, amendment, tampering or viruses or any=20 > >consequences thereof. >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 09:10:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23499 for ; Sun, 29 Feb 2004 09:10:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRdn-0006hK-Ar for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 09:10:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TE9xjP025739 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 09:09:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRdm-0006h4-Nk for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 09:09:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23477 for ; Sun, 29 Feb 2004 09:09:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxRdl-0006zW-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 09:09:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxRcq-0006uU-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 09:09:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxRbx-0006pZ-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 09:08:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRbu-0006M6-6g; Sun, 29 Feb 2004 09:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRav-00063j-Co for sipping@optimus.ietf.org; Sun, 29 Feb 2004 09:07:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23424 for ; Sun, 29 Feb 2004 09:06:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxRat-0006kC-00 for sipping@ietf.org; Sun, 29 Feb 2004 09:06:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxRZy-0006fL-00 for sipping@ietf.org; Sun, 29 Feb 2004 09:06:03 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AxRZg-0006a5-00 for sipping@ietf.org; Sun, 29 Feb 2004 09:05:44 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 14121; Sun, 29 Feb 2004 09:05:17 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Feb 2004 09:04:25 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A1E4@zoe.office.snowshore.com> Thread-Topic: Comments on Policy documents Thread-Index: AcP+woJAM8XknuAIT9enDOL6wbnR9w== From: "Eric Burger" To: , "Jonathan Rosenberg (E-mail)" Cc: "Sipping (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Comments on Policy documents Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On sipping-spec-policy-00 - Do we really need end-to-end, two-party acceptance of proxy policies? Motivation: to the UAC, there is no difference between a proxy saying = "you can only do G.711" and the UAS returning an answer saying "please = only use G.711". Conversely, to the UAS, there is no difference between a proxy saying = "please only do G.711" and the UAC offering only G.711. I *can* see letting the UAC know what is going on from a human factors = perspective. Let's say I bought the latest foobratz phone that does = quadraphonic-better-than-CD-quality audio. However, I can never use it, = because everyone comes back answering with G.729ab. It might be nice to = know that it is because a proxy limited me, not that my fancy phone = doesn't work. As the owner of the UAC, I have expectations of the fancy = stuff working. That said, if my fancy phone is in the UAS role, I have = expectations that other people *don't* have my fancy features, = especially if my INVITES only have G.711 in them. In another issue, consider section 3.1.2. The document states that it = is not recommended for a proxy to reject a request that doesn't honor = the MFO. It may be better to state the obvious alternative: If the = proxy really has to enforce the policy, it flips into B2BUA mode. By = definition, end-to-end is broken (from the carrier's perspective), so = the carrier will jump in and "fix it". The idea being that if everyone = plays by the rules (or suggestions), one won't have to look for another = service provider that doesn't feel like billing :-) I would also suggest stating that proxies MUST NOT mix its MFO's on a = media-filter header populated with MFO's from another proxy. That is, a = proxy can add media-filter headers, but it cannot modify existing ones. = This is supported already in the syntax. However, I would make this a = MUST to make it easier to sign headers and ensure they don't break = header signing. Lastly, is there any reason to use different formats for = session-specific versus session-independent policy (headers v. XML)? = XML is more expressive -- if we wanted to keep XML, how about using = cid:'s for the session-specific MFO statements? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 16:53:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11511 for ; Sun, 29 Feb 2004 16:53:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxYs1-0001du-1l for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 16:53:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TLr9ZZ006310 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 16:53:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxYs0-0001dh-U0 for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 16:53:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11485 for ; Sun, 29 Feb 2004 16:53:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxYry-0004gK-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 16:53:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxYr3-0004bB-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 16:52:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxYq9-0004Wu-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 16:51:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxYpz-0001NZ-5I; Sun, 29 Feb 2004 16:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxYpF-0001JV-5h for sipping@optimus.ietf.org; Sun, 29 Feb 2004 16:50:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11403 for ; Sun, 29 Feb 2004 16:50:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxYpD-0004RK-00 for sipping@ietf.org; Sun, 29 Feb 2004 16:50:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxYoJ-0004MC-00 for sipping@ietf.org; Sun, 29 Feb 2004 16:49:20 -0500 Received: from mail3.pi.se ([195.7.64.137] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AxYnY-0004Gu-00 for sipping@ietf.org; Sun, 29 Feb 2004 16:48:32 -0500 Received: from vit ([210.93.162.110]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id i1TLkPC9010629; Sun, 29 Feb 2004 22:46:31 +0100 (CET) From: "Gunnar Hellstrom" To: "Eric Burger" , , "Sipping \(E-mail\)" Date: Sun, 29 Feb 2004 22:48:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB1A1EE@zoe.office.snowshore.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id i1TLkPC9010629 Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: manyfolks-sipping-ToIP-01 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Eric, the specified transmission method is designed for both satisfying t= he users and not straining networks: In order to not strain networks, the transport level RFC2793 says that characters should be buffered together in packets for shipping. The recommendation for shipping packets with text is to use 300 ms intervals between transmissions. The revision of RFC2793, in draft-ietf-avt-rfc2793bis-02 is stronger and more clear about this RECOMMENDATION. With the 300 ms interval between packet transmissions, we have a text flo= w that is experienced to be close enough to character-by-character, and a maximum network load of 3 packets per second containing around 3 kbit/s, including redundancy. That is sustainable for most network connections. Are there really typists that can type 60 characters per second???? I would expect that the maximum load would come from speech-to-text arrangements, where I would guess that 20 characters per second would be = a practical maximum. Therefore, 30 characters/s throughput in transmission sounded sufficient for me. With the buffering described above, this figure is not critical, so if yo= u have reasons to think that there is a real requirement for 60 cps, we sho= uld document it. Subtitling a radio report from a football match by using speech-to-text might be among the more challenging applications.. Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com]On Behalf Of Eric Burger Sent: Sunday, February 29, 2004 8:50 PM To: toip@snowshore.com; Sipping (E-mail) Subject: manyfolks-sipping-ToIP-01 I like the "network must support a minimum of 30cps" for text (section 6, requirement (d)). Then I thought about it: that's a ptime of 33ms. That= is OK. However, if we said minimum of 30cps, but really like 60cps (professional typist), that is a ptime of 16ms, which would start to stra= in many networks. Why do we say that the file format for storage should be XHTML? Are we archiving marked-up text? Why not just UTF-8? - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/toip_archive/maillist.html _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 17:04:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12275 for ; Sun, 29 Feb 2004 17:04:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZ2w-0002bC-Uj for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 17:04:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TM4QRc009984 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 17:04:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZ2w-0002ax-RO for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 17:04:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12233 for ; Sun, 29 Feb 2004 17:04:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxZ2u-0005uJ-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 17:04:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxZ1e-0005cS-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 17:03:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxYzg-0005Hy-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 17:01:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxYzg-0006Ed-4o for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 17:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxYze-0002Dj-Os; Sun, 29 Feb 2004 17:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxYyo-0001ym-On for sipping@optimus.ietf.org; Sun, 29 Feb 2004 17:00:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11805 for ; Sun, 29 Feb 2004 17:00:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxYym-0005EX-00 for sipping@ietf.org; Sun, 29 Feb 2004 17:00:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxYxt-0005AW-00 for sipping@ietf.org; Sun, 29 Feb 2004 16:59:13 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AxYxM-000556-00 for sipping@ietf.org; Sun, 29 Feb 2004 16:58:40 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Feb 2004 14:10:01 +0000 Received: from zipper.cisco.com (zipper.cisco.com [171.70.69.143]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1TLw8uB006987; Sun, 29 Feb 2004 13:58:08 -0800 (PST) Date: Sun, 29 Feb 2004 13:58:08 -0800 (PST) From: Rohan Mahy X-X-Sender: rmahy@zipper.cisco.com To: Eric Burger cc: "Jonathan Rosenberg (E-mail)" , schulzrinne@cs.columbia.edu, "Sipping (E-mail)" In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB1A1DB@zoe.office.snowshore.com> Message-ID: References: <4A3384433CE2AB46A63468CB207E209DB1A1DB@zoe.office.snowshore.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sipping] Re: State Agents in sipping-dialog-package-04 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Eric, The document already allows for state agents. Is there something specific you would want to put in the document in addition. thanks, -rohan On Sun, 29 Feb 2004, Eric Burger wrote: > I was thinking: would it not be useful to recommend a state agent for hiding devices behind a forking proxy? Isn't the subscriber interested in the user / user+device state? > > Subscribing to the dialog package will let you see the topology of all of my endpoints behind a forking proxy. You can figure out that I've got a home phone, a work phone, a soft phone, a phone at the ski slope, and a silly phone. I might not want you to know that. However, I may want you to use the cool features dialog package enables. > > If I have a stateless forking proxy, then yes, simply calling me will get you all of the 1xx's and 4xx's showing all of my devices. However, if I have a stateful proxy that collects and sorts provisional responses, only sending back a real contact, then you don't get all of my device info. Thus having a state agent would mirror the level of security a simple INVITE has. > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 17:45:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13616 for ; Sun, 29 Feb 2004 17:45:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZg3-0005D2-Sk for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 17:44:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TMip37020018 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 17:44:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZg3-0005Cn-NP for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 17:44:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13597 for ; Sun, 29 Feb 2004 17:44:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxZg1-0001dk-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 17:44:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxZf3-0001UF-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 17:43:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxZeJ-0001Jg-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 17:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZeH-00051s-II; Sun, 29 Feb 2004 17:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZdc-0004z7-71 for sipping@optimus.ietf.org; Sun, 29 Feb 2004 17:42:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13459 for ; Sun, 29 Feb 2004 17:42:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxZdZ-0001HA-00 for sipping@ietf.org; Sun, 29 Feb 2004 17:42:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxZcm-0001Ab-00 for sipping@ietf.org; Sun, 29 Feb 2004 17:41:28 -0500 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1AxZbv-0000yu-00 for sipping@ietf.org; Sun, 29 Feb 2004 17:40:35 -0500 Received: from pingtel.com (unknown[210.93.162.110]) by comcast.net (sccrmhc12) with SMTP id <2004022922400401200g83k9e> (Authid: dgpetrie); Sun, 29 Feb 2004 22:40:05 +0000 Message-ID: <40426A42.93F20F4F@pingtel.com> Date: Sun, 29 Feb 2004 17:40:02 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Burger CC: "Sipping (E-mail)" Subject: Re: [Sipping] Comment on sipping-config-framework-02 References: <4A3384433CE2AB46A63468CB207E209DB1A1DC@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric Burger wrote: > In the overview (2.3), the document states that the content delivery server MUST be in the public network or DMZ. The intention of that sentence/paragraph was that it must be possible to have profile delivery server anywhere on the Internet and that it must be possible for UAs to access that server using this framework (e.g. traverse NAT/firewalls, etc.). Thanks, I will fix the wording. > > > I would offer that for a carrier, they will be loathe to put subscriber data on the open Internet. Moreover, while it may be acceptable to have a MAC address float about in a "secure" network, service providers may be less sanguine in a sniffable, public network. The MAC address was merely a suggestion. The point was to have a unique identifier for the device. > > > How about some language about the perils of putting it in the public network, as well as the reasons for doing it. For example, to support roaming - I need my profile when I'm away without having to establish a VPN first. Based upon how the dicussion goes today, it is likely that I will be beefing up the dicussion on hoteling, roaming and the concepts of the local network, device and user profiles and subscriptions. > > > I would also be more specific on the access protocol for retrieving the profile. It is good to say, "any URI scheme", so long as one says something like "but MUST implement https at a minimum." That way, there is a minimum baseline that all devices and content delivery servers will be able to interoperate with. The URL scheme is to be defined by the profile data definintion which is out of scope for this document. > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 18:36:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16406 for ; Sun, 29 Feb 2004 18:36:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaTy-0006Ch-JR for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 18:36:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TNaQUC023841 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 18:36:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaTy-0006CS-Bj for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 18:36:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16401 for ; Sun, 29 Feb 2004 18:36:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxaTv-00061N-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 18:36:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxaT7-0005wG-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 18:35:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxaSg-0005qq-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 18:35:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaSd-000613-4w; Sun, 29 Feb 2004 18:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaRq-0005vr-6x for sipping@optimus.ietf.org; Sun, 29 Feb 2004 18:34:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16306 for ; Sun, 29 Feb 2004 18:34:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxaRn-0005oq-00 for sipping@ietf.org; Sun, 29 Feb 2004 18:34:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxaR0-0005ke-00 for sipping@ietf.org; Sun, 29 Feb 2004 18:33:23 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AxaQD-0005b6-00 for sipping@ietf.org; Sun, 29 Feb 2004 18:32:33 -0500 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 i1TNUx4U027183; Sun, 29 Feb 2004 15:31:00 -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 PAA25710; Sun, 29 Feb 2004 15:30:48 -0800 (PST) Message-Id: <4.3.2.7.2.20040229171956.02d0bee8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 29 Feb 2004 17:30:50 -0600 To: Adam Roach , "'Gonzalo Camarillo'" , sipping From: "James M. Polk" Subject: RE: [Sipping] WGLC for draft-ietf-sipping-reason-header-for-preem ption-00.txt Cc: Dean Willis , Rohan Mahy In-Reply-To: <9ACE0CEE075B494096C86C23878BF85906A337@dyn-tx-exch-001.dyn amicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 05:34 PM 2/27/2004 -0600, Adam Roach wrote: >The document looks good to me at a skim, thanks >but I believe >there are a couple of points of clarification that should >be added to 4.2.1. > >First, I believe the label for the right-most bar in the >diagram should be "UA2" instead of "UA3," if my understanding >of the use case is correct. Actually, you point out that I didn't have Figure 3 correct (section 3.0), which I copied to Figure 5 (section 4.2.1). Thanks for the catch! >Secondly, it is not clear how the "Resource-Priority: 2" in >the UA3-UA4 call comes into play. None of the UAs shown in >this flow are privy to any of the SIP signaling that was used >to establish the UA3-UA4 call. What would seem to matter is >the RSVP priorities used to establish the call. Correct? correct >This should probably be clarified in the text. I was too simple in my explanation. I will add the text explaining that the SIP R-P values translate to RSVP priorities accordingly. Thanks again. >/a > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > Sent: Sunday, February 08, 2004 15:29 > > To: sipping > > Cc: Dean Willis; Rohan Mahy; James M. Polk > > Subject: [Sipping] WGLC for > > draft-ietf-sipping-reason-header-for-preemption-00.txt > > > > > > Folks, > > > > we would like to announce the start of the WGLC for the > > following draft. > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-reason- >header-for-preemption-00.txt > >This WGLC will end on Feb 29th. > >Send your comments to this mailing list and to the author. > >Thanks, > >Gonzalo >SIPPING co-chair cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 19:09:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17791 for ; Sun, 29 Feb 2004 19:09:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axazx-0000C8-VN for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 19:09:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2109Tld000742 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 19:09:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axazx-0000Bt-Qy for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 19:09:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17787 for ; Sun, 29 Feb 2004 19:09:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axazu-00012T-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 19:09:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axaz0-0000wS-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 19:08:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxayZ-0000pv-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 19:08:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxayZ-0008NT-Kj; Sun, 29 Feb 2004 19:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axaxx-0008FH-2G for sipping@optimus.ietf.org; Sun, 29 Feb 2004 19:07:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17634 for ; Sun, 29 Feb 2004 19:07:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axaxt-0000nL-00 for sipping@ietf.org; Sun, 29 Feb 2004 19:07:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axax1-0000iC-00 for sipping@ietf.org; Sun, 29 Feb 2004 19:06:28 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AxawP-0000ZQ-00 for sipping@ietf.org; Sun, 29 Feb 2004 19:05:49 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 31806; Sun, 29 Feb 2004 19:05:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Feb 2004 19:05:14 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A1FC@zoe.office.snowshore.com> Thread-Topic: State Agents in sipping-dialog-package-04 Thread-Index: AcP/DyAig4nr+7q4R9iREOqxoxn4iwADd4ow From: "Eric Burger" To: "Rohan Mahy" Cc: "Jonathan Rosenberg (E-mail)" , , "Sipping (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: State Agents in sipping-dialog-package-04 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The State Agents section seems to me to read that State Agents are a bad = idea ("Dialog state is ideally maintained in the user agents in which = the dialog resides."). I guess a softening of the language would be = clearer. > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Sunday, February 29, 2004 4:58 PM > To: Eric Burger > Cc: Jonathan Rosenberg (E-mail); schulzrinne@cs.columbia.edu; Sipping > (E-mail) > Subject: Re: State Agents in sipping-dialog-package-04 >=20 >=20 > Hi Eric, >=20 > The document already allows for state agents. Is there=20 > something specific > you would want to put in the document in addition. >=20 > thanks, > -rohan >=20 >=20 > On Sun, 29 Feb 2004, Eric Burger wrote: >=20 > > I was thinking: would it not be useful to recommend a state=20 > agent for hiding devices behind a forking proxy? Isn't the=20 > subscriber interested in the user / user+device state? > > > > Subscribing to the dialog package will let you see the=20 > topology of all of my endpoints behind a forking proxy. You=20 > can figure out that I've got a home phone, a work phone, a=20 > soft phone, a phone at the ski slope, and a silly phone. I=20 > might not want you to know that. However, I may want you to=20 > use the cool features dialog package enables. > > > > If I have a stateless forking proxy, then yes, simply=20 > calling me will get you all of the 1xx's and 4xx's showing=20 > all of my devices. However, if I have a stateful proxy that=20 > collects and sorts provisional responses, only sending back a=20 > real contact, then you don't get all of my device info. Thus=20 > having a state agent would mirror the level of security a=20 > simple INVITE has. > > > > >=20 >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 19:21:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18419 for ; Sun, 29 Feb 2004 19:21:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbAV-0001MB-QO for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 19:20:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i210KNPT005213 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 19:20:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbAV-0001Ly-KQ for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 19:20:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18400 for ; Sun, 29 Feb 2004 19:20:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxbAT-0002EF-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 19:20:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axb9X-00029b-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 19:19:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axb9E-00024Z-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 19:19:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axb9B-00012D-Q7; Sun, 29 Feb 2004 19:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axb8e-0000yR-KH for sipping@optimus.ietf.org; Sun, 29 Feb 2004 19:18:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18310 for ; Sun, 29 Feb 2004 19:18:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axb8d-00022w-00 for sipping@ietf.org; Sun, 29 Feb 2004 19:18:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axb7i-0001wg-00 for sipping@ietf.org; Sun, 29 Feb 2004 19:17:32 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1Axb7C-0001pi-00 for sipping@ietf.org; Sun, 29 Feb 2004 19:16:58 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i210GIUG003533; Sun, 29 Feb 2004 19:16:19 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA15691; Sun, 29 Feb 2004 19:16:17 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Sun, 29 Feb 2004 19:16:17 -0500 Message-ID: <313680C9A886D511A06000204840E1CF08E909DB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: Gunnar Hellstrom , Arnoud van Wijk , Gonzalo.Camarillo@ericsson.com, sipping@ietf.org Cc: rrroy@att.com, barry.dingle@bigfoot.com.au, henry.sinnreich@mci.com, paulej@packetizer.com, gv@trace.wisc.edu Subject: RE: Betr.: [Sipping] ToIP Requirements Date: Sun, 29 Feb 2004 19:16:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 How does V.18 work? Is the "calling identifier" something in (ISDN presumably) signalling? Or is it a distinctive tone pattern? Brian > -----Original Message----- > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > Sent: Friday, February 27, 2004 1:45 AM > To: Arnoud van Wijk; 'Rosen, Brian'; Gonzalo.Camarillo@ericsson.com; > sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > paulej@packetizer.com; gv@trace.wisc.edu > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > The INCOM group of the European commission made > recommendations that the > same emergency number shall be used for all kinds of terminals. > It is dangerous to have different prefixes or other tricks in > different > countries. How shall you keep track of that if you are a visitor? > > From PSTN, it is only the old textphones that cause problems. > A calling V.18 > sends a very distinct calling identifier that can be catched > by a gateway or > an emergency centre and be properly handled. On the SIP side, > the options > are even better. > > I do not mean that all problems are solved by this statement, > but I do not > think that the prefix is the only solution, and I do not > think we shall > recommend it in connection to emergency. > > > Gunnar > > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > -----Original Message----- > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org]On Behalf Of > Arnoud van Wijk > Sent: Thursday, February 26, 2004 4:57 PM > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > Gonzalo.Camarillo@ericsson.com; > sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > paulej@packetizer.com; gv@trace.wisc.edu > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > Hello Brian, > > Yes you are right about that the PSTN cannot detect if it is > a voice call or > TDD/Textphone call. They are both audio. > The PSTN would if it can detect it is a textphone call, route > it to the text > gateway. And transcode the call into T.140 over RTP as > decribed in RFC 2793. > This is for PSTNs which use IP to interconnect with other > PSTNs or with any > SIP telephones. So it is for analoge telephony into SIP > telephony here. > > In the ToIP draft: > http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-to > ip-01.txt > A possible solution is a prefix for textphone users before > dialling the > selected number. > It indeed would mean that you dial e.g. 600-112 instead 112 directly. > Is that bad? > I believe it is not. > > Most textphones have the emergency number pre programmed. And > when textphone > users have to use a pre-fix for any textphone call, then the > same prefix > before 112 or 911 will be fine. > In the Netherlands, we have for emergency calls 800-112 > instead of 112. It > works fine, only almost no deaf users call 112, since they > are then mostly > in a situation where they do not have a textphone nearby! > > Maybe there are other solutions that allow the PSTN to detect that the > incoming call is a textphone user and acts on it. > > For example it is possible to create a database where the > PSTN can check if > the incoming number is registered as a textphone. > > But using a text gateway to connect PSTN textphones/TDDs to > ToIP is still > the best solution, even the only solution in my opinion. > There should be no attempts to transport the text telephone > tones (e.g. > Baudot) over the IP voice channel! I believe that will open > Pandora's box. > > I am not a PSTN expert, and we can surely look into this > matter to find a > solution. Let it be prefix or any other solution that lets the PSTN > immediately route the call to the text gateway. > > What do you PSTN people think? How would you tackle this > problem? Your input > will be very welcome. > > Greetz > > Arnoud > > Drs. Arnoud A. T. van Wijk > Viataal > Research & Development > Afdeling RDS > Theerestraat 42 > 5271 GD Sint-Michielsgestel > The Netherlands. > Mobile: +31651921948 > International text telephone: +31735588408 > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: donderdag 26 februari 2004 15:36 > To: 'Arnoud van Wijk'; 'Gunnar Hellstrom'; > Gonzalo.Camarillo@ericsson.com; > sipping@ietf.org > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > henry.sinnreich@mci.com; > paulej@packetizer.com; gv@trace.wisc.edu > Subject: RE: Betr.: [Sipping] ToIP Requirements > > Arnoud > > I do not believe this can work. A TDD user dials 112 or 911. > Today, this > will be routed directly to a "selective router" (a TDM > switch) which sends > the > call to the correct Emergency Response Center. You can't > insert a gateway, > because you don't know that it's a TDD call until it is > answered. To make > it work, you would have to establish a special PSTN number > for emergency > TDD, > which would route to the gateway, which would then call the > ERC. I don't > believe that is practical. > > Brian > > > > > -----Original Message----- > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > Sent: Thursday, February 26, 2004 9:17 AM > > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > > Gonzalo.Camarillo@ericsson.com; > > sipping@ietf.org > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > henry.sinnreich@mci.com; > > paulej@packetizer.com; gv@trace.wisc.edu > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > Hello Brian, > > That is also why we need to look at the emergency call system. > > This text gateway is only at the PSTN side, thus another > > requirement for a > > T140/RTP gateway for the PSTN is that when a local > emergency number is > > dialled (112, or 911 etc). That the gateway must be able to > > receive that > > call (even dropping existing calls if necessary). Such a call > > is easy to > > recognize as an emergency call. (PSTN side). > > From that gateway on, it is all IP with RFC2793 interactive > > text. And then > > it is just all existing SIP as if it was from an IP end-point. > > > > This gives emergency centers an advantage, all calls will be > > T.140/RTP, so > > integration in their computer systems will be easy instead > > being forced to > > have analog textphones available for a textphone call. (or a > > separate text > > telephone emergency center). > > > > /Arnoud > > > > Drs. Arnoud A. T. van Wijk > > Viataal > > Research & Development > > Afdeling RDS > > Theerestraat 42 > > 5271 GD Sint-Michielsgestel > > The Netherlands. > > Mobile: +31651921948 > > International text telephone: +31735588408 > > > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: donderdag 26 februari 2004 15:04 > > To: 'Arnoud van Wijk'; 'Gunnar Hellstrom'; > > Gonzalo.Camarillo@ericsson.com; > > sipping@ietf.org > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > henry.sinnreich@mci.com; > > paulej@packetizer.com; gv@trace.wisc.edu > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > Arnoud > > > > Generally, you don't want to rely on very many SIP elements > > to complete > > an emergency call. Present systems accept TDD at all answering > > points because they don't know before the calls is answered that it > > is a TDD call. I certainly don't want the user to have to > do anything > > other than dial his local emergency number, or complete a device > > specific key sequence to complete an emergency call, and I don't > > want a gateway busy to prevent an emergency call. > > > > Brian > > > > > -----Original Message----- > > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > > Sent: Thursday, February 26, 2004 6:07 AM > > > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > > > Gonzalo.Camarillo@ericsson.com; > > > sipping@ietf.org > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > henry.sinnreich@mci.com; > > > paulej@packetizer.com; gv@trace.wisc.edu > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > Actually, > > > When using the text gateway, there is no need to detect the > > > TDD/Analogue > > > text telephone tones/signals. That is the job of the text gateway. > > > > > > And for the emergency calling. We have to look closely at this in > > > combination with a text gateway. Possible behaviour/action. > > > And possible > > > action in SIP. > > > > > > Right now I cannot say what has to happen, I must study the > > > emergency calls > > > in depth. But as I see it, using the text gateway, all SIP > > > originating and > > > receiving emergency calls will be possible for any textphone user. > > > > > > Cheers > > > > > > Arnoud > > > > > > > > > Drs. Arnoud A. T. van Wijk > > > Viataal > > > Research & Development > > > Afdeling RDS > > > Theerestraat 42 > > > 5271 GD Sint-Michielsgestel > > > The Netherlands. > > > Mobile: +31651921948 > > > International text telephone: +31735588408 > > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > On Behalf Of > > > Rosen, Brian > > > Sent: woensdag 25 februari 2004 23:08 > > > To: 'Gunnar Hellstrom'; A vWijk; Gonzalo.Camarillo@ericsson.com; > > > sipping@ietf.org > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > henry.sinnreich@mci.com; > > > paulej@packetizer.com; gv@trace.wisc.edu > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > I'm particularly interested in the last one, emergency calling. > > > > > > Given that you propose an appropriate SDP indicating > > support for text, > > > do you think there is anything else we need to do to in SIP > > > to make this > > > happen? I don't see anything. > > > > > > I know that the problem of using a legacy TDD device on > any kind of > > > adapter is as problematic as current TDD; the call will answered > > > as if it was a voice call, the baudot/whatever tones will be > > > detected, > > > and the operator will look for text. > > > Can't think of any way to make that better. > > > > > > Do note that language preference headers should be set!!! > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > Sent: Wednesday, February 25, 2004 4:54 PM > > > > To: A vWijk; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > henry.sinnreich@mci.com; > > > > paulej@packetizer.com; gv@trace.wisc.edu > > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > > > I think PSTN textphone gateway invocation is one area where > > > > we either need > > > > protocol extensions, or need agreements on what current > > > > mechanisms to use. > > > > > > > > Another is invocation of various kinds of relay services or > > > > translation > > > > services. > > > > > > > > A third is calling emergency services and reach positions > > capable of > > > > handling the type of communication that the user prefers. > > > > > > > > > > > > > > > > Gunnar > > > > ------------------------------------------- > > > > Gunnar Hellstrom > > > > Omnitor AB > > > > Renathvagen 2 > > > > SE 121 37 Johanneshov > > > > SWEDEN > > > > +46 8 556 002 03 > > > > Mob: +46 708 204 288 > > > > www.omnitor.se > > > > Gunnar.Hellstrom@Omnitor.se > > > > -------------------------------------------- > > > > > > > > > > > > -----Original Message----- > > > > From: sipping-admin@ietf.org > > > > [mailto:sipping-admin@ietf.org]On Behalf Of > > > > A vWijk > > > > Sent: Tuesday, February 24, 2004 1:22 PM > > > > To: Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > henry.sinnreich@mci.com; > > > > gunnar.hellstrom@omnitor.se; paulej@packetizer.com; > > > gv@trace.wisc.edu > > > > Subject: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > > > Hello Gonzalo, > > > > While there are device requirements in the text. Those > > > > requirements and the > > > > explanation on the different analogue text telephone systems > > > > is included to > > > > give the reader an understanding what kind of devices will > > > > connect with > > > > ToIP. And the need for the text gateways. And what the > > > > different behaviour > > > > can/may be compared to end to end IP devices. > > > > The most important part will be the ToIP framwork and the > > > > text gateways and > > > > how such gateways will be used and work with the ToIP framework. > > > > > > > > There is a ToIP framework where a terminal uses streaming > > > > text as defined in > > > > RFC2793 to connect with any other Interactive > > > > texting/real-time streaming > > > > text device. > > > > This can be end-to-end IP, and a direct T140/RTP stream is > > > > established with > > > > SIP. But in other cases, a text gateway must be used to allow > > > > T.140/RTP to > > > > connect with a non IP text telephony device. > > > > It can be an analogue text telephone (TDD/TTY) that uses a > > > > text gateway to > > > > be able to understand RFC2793 text. (PSTN-IP) > > > > It can be a mobile phone running GPRS that uses the text > > gateway to > > > > understand RFC2793 text. (this exist right NOW using SIP! And > > > > those gateways > > > > will be used in mobile networks this year!) > > > > Or a mobile text telephone using CTM via the text gateway to > > > > communicate > > > > with RFC2793 text. > > > > Or even one analogue text telephone connecting to another > > > > analogue text > > > > telephone in a different country, and the PSTN's use IP to > > > > connect the call. > > > > > > > > The question is for example, how do we use that gateway from > > > > the IP side? Is > > > > it invisible for the IP side? Or do we need special > > > > extensions in SIP to > > > > that the IP terminal knows it is communicating with the > > > > end-device through > > > > the text gateway? > > > > There may be a slightly different call setup flow when a text > > > > gateway is > > > > included. > > > > Or additional SIP messages indicating gateway activity. When > > > > you connect for > > > > example to an analogue text telephone with an RFC2793 capable > > > > IP terminal > > > > the capabilities will be less then IP to IP terminal directly > > > > (different > > > > transmission speeds, half/full duplex etc). > > > > Or what to do with emergency calls that are in RFC 2793 > text only? > > > > > > > > That are requirements that will be defined and worked out in > > > > this draft. > > > > Also, we want to make everybody in SIP and SIPPING aware > > > > about those text > > > > gateways. So that complicated matters like how to send > > analogue text > > > > telephone text through a PSTN and connect with a SIP > > > > telephone using RFC2793 > > > > interactive texting. When using the text gateway, there is > > > > then no need for > > > > RFC 2833 events at the PSTN for text telephones. > > > > > > > > So, yes. I believe that this should be in the SIPPING WG. And > > > > it will fit in > > > > the charter - support for hearing-/speech-impaired calling. > > > > > > > > greetz > > > > > > > > Arnoud > > > > > > > > > > > > > > > > Drs. Arnoud A. T. van Wijk > > > > Viataal > > > > Research & Development > > > > Afdeling RDS > > > > Theerestraat 42 > > > > 5271 GD Sint-Michielsgestel > > > > The Netherlands. > > > > Mobile: +31651921948 > > > > International text telephone: +31735588408 > > > > > > > > >>> Gonzalo Camarillo > > > > 24-02-04 10:21 >>> > > > > Hello, > > > > > > > > the draft below provides a set of requirements for real-time > > > > conversations using SIP. > > > > http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-to > > > ip-01.txt > > > > > > Nevertheless, I have found a lot of device requirements in > > > the text, but > > > I fail to understand which particular protocol requirements > > we need to > > > fulfill with new protocol extensions. > > > > > > While SIPPING is the right place to handle requirements > > that will lead > > > to new SIP protocol extensions, SIPPING may not be the > > right place to > > > deal with device requirements (e.g., text phones MUST have a > > > display of > > > at least 100 characters). > > > > > > Thanks, > > > > > > Gonzalo > > > > > > > > > This communication is confidential and intended solely for > > > the addressee(s). > > > Any unauthorized review, use, disclosure or distribution is > > > prohibited. If > > > you believe this message has been sent to you in error, > > > please notify the > > > sender by replying to this transmission and delete the > > message without > > > disclosing it. Thank you. > > > > > > E-mail including attachments is susceptible to data corruption, > > > interruption, unauthorized amendment, tampering and viruses, > > > and we only > > > send and receive e-mails on the basis that we are not liable > > > for any such > > > corruption, interception, amendment, tampering or viruses or any > > > consequences thereof. > > > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 19:22:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18460 for ; Sun, 29 Feb 2004 19:22:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbBZ-0001Uf-4W for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 19:21:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i210LTY7005735 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 19:21:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbBY-0001UQ-Vr for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 19:21:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18456 for ; Sun, 29 Feb 2004 19:21:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxbBX-0002LG-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 19:21:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxbAd-0002Fi-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 19:20:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxbAE-0002AC-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 19:20:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbAE-0001Fa-1O; Sun, 29 Feb 2004 19:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axb9M-00016C-BP for sipping@optimus.ietf.org; Sun, 29 Feb 2004 19:19:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18349 for ; Sun, 29 Feb 2004 19:19:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axb9K-00027k-00 for sipping@ietf.org; Sun, 29 Feb 2004 19:19:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axb8M-00020t-00 for sipping@ietf.org; Sun, 29 Feb 2004 19:18:11 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1Axb7N-0001qE-00 for sipping@ietf.org; Sun, 29 Feb 2004 19:17:09 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i210GUUG003536; Sun, 29 Feb 2004 19:16:30 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA15689; Sun, 29 Feb 2004 19:16:14 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Sun, 29 Feb 2004 19:16:14 -0500 Message-ID: <313680C9A886D511A06000204840E1CF08E909DA@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: Barry Dingle , "'Arnoud van Wijk'" , "'Gunnar Hellstrom'" , Gonzalo.Camarillo@ericsson.com, sipping@ietf.org Cc: rrroy@att.com, henry.sinnreich@mci.com, paulej@packetizer.com, gv@trace.wisc.edu, Len Bytheway Subject: RE: Betr.: [Sipping] ToIP Requirements Date: Sun, 29 Feb 2004 19:16:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 While we can, and have, specified a single worldwide URI for emergency calls, I believe it is not even technically possible to find a single 3 digit number that is not already in use somewhere. Thus, I suspect anyone dreaming that such a thing will happen probably is going to be disappointed. Since existing TDD devices do not provide an indication that they are present until after the call is completed, I think that we should not even consider use of any kind of gateway for emergency calls. This is true of V.18 devices also, correct? Having a special number for text emergency calls does have an impact on the sos draft however. The draft discusses use of local emergency numbers. That text may have to be expanded to cover such a case. Are there other examples where there are special numbers that are used for a subset of emergency calls other than this kind of example (discriminate based on media) and the examples of a direct number for a specific responder, for example, police? Brian > -----Original Message----- > From: Barry Dingle [mailto:barry.dingle@bigfoot.com.au] > Sent: Thursday, February 26, 2004 6:49 PM > To: Rosen, Brian; 'Arnoud van Wijk'; 'Gunnar Hellstrom'; > Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > Cc: rrroy@att.com; henry.sinnreich@mci.com; paulej@packetizer.com; > gv@trace.wisc.edu; Len Bytheway; Barry Dingle > Subject: Re: Betr.: [Sipping] ToIP Requirements > > > Brian, > > In Australia, we have a separate emergency number for > Textphone users. It is > '106' and is regulated by legislation. > > We have a separate '106' emergency call centre. This makes > special support > for a range of text services much easier. (See > http://www.aceinfo.net.au/Services/NRS/Services/ers.html). I > understand > that this may be difficult to implement for historical reasons in some > countries - but it is possible and works well. > > As an aside, we are seriously investigating a 'Text Server' > to support a > whole range of text interworking scenarios - and ToIP is planned to be > supported in Stage 2. I believe that we will eventually move > to a single > emergency number - but not until we can easily and reliably > identify text > emergency calls. > > Cheers, > > Barry DINGLE > Telecommunications Consultant > Project Manager - ACIF Any-to-Any Text Connectivity Options WG > Fellow of the University of Melbourne > barry.dingle@bigfoot.com.au > Mob: +61 (0)41 911 7578 > Fixed: +61 (0)3 9725 3937 > ----- Original Message ----- > From: "Rosen, Brian" > To: "'Arnoud van Wijk'" ; "'Gunnar Hellstrom'" > ; ; > > Cc: ; ; > ; ; > > Sent: Friday, February 27, 2004 1:36 AM > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > Arnoud > > > > I do not believe this can work. A TDD user dials 112 or > 911. Today, this > > will be routed directly to a "selective router" (a TDM > switch) which sends > > the > > call to the correct Emergency Response Center. You can't insert a > gateway, > > because you don't know that it's a TDD call until it is > answered. To make > > it work, you would have to establish a special PSTN number > for emergency > > TDD, > > which would route to the gateway, which would then call the > ERC. I don't > > believe that is practical. > > > > Brian > > > > > > > > > -----Original Message----- > > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > > Sent: Thursday, February 26, 2004 9:17 AM > > > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > > > Gonzalo.Camarillo@ericsson.com; > > > sipping@ietf.org > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > henry.sinnreich@mci.com; > > > paulej@packetizer.com; gv@trace.wisc.edu > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > Hello Brian, > > > That is also why we need to look at the emergency call system. > > > This text gateway is only at the PSTN side, thus another > > > requirement for a > > > T140/RTP gateway for the PSTN is that when a local > emergency number is > > > dialled (112, or 911 etc). That the gateway must be able to > > > receive that > > > call (even dropping existing calls if necessary). Such a call > > > is easy to > > > recognize as an emergency call. (PSTN side). > > > From that gateway on, it is all IP with RFC2793 interactive > > > text. And then > > > it is just all existing SIP as if it was from an IP end-point. > > > > > > This gives emergency centers an advantage, all calls will be > > > T.140/RTP, so > > > integration in their computer systems will be easy instead > > > being forced to > > > have analog textphones available for a textphone call. (or a > > > separate text > > > telephone emergency center). > > > > > > /Arnoud > > > > > > Drs. Arnoud A. T. van Wijk > > > Viataal > > > Research & Development > > > Afdeling RDS > > > Theerestraat 42 > > > 5271 GD Sint-Michielsgestel > > > The Netherlands. > > > Mobile: +31651921948 > > > International text telephone: +31735588408 > > > > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: donderdag 26 februari 2004 15:04 > > > To: 'Arnoud van Wijk'; 'Gunnar Hellstrom'; > > > Gonzalo.Camarillo@ericsson.com; > > > sipping@ietf.org > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > henry.sinnreich@mci.com; > > > paulej@packetizer.com; gv@trace.wisc.edu > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > Arnoud > > > > > > Generally, you don't want to rely on very many SIP elements > > > to complete > > > an emergency call. Present systems accept TDD at all answering > > > points because they don't know before the calls is > answered that it > > > is a TDD call. I certainly don't want the user to have > to do anything > > > other than dial his local emergency number, or complete a device > > > specific key sequence to complete an emergency call, and I don't > > > want a gateway busy to prevent an emergency call. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > > > Sent: Thursday, February 26, 2004 6:07 AM > > > > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > > > > Gonzalo.Camarillo@ericsson.com; > > > > sipping@ietf.org > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > henry.sinnreich@mci.com; > > > > paulej@packetizer.com; gv@trace.wisc.edu > > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > > > Actually, > > > > When using the text gateway, there is no need to detect the > > > > TDD/Analogue > > > > text telephone tones/signals. That is the job of the > text gateway. > > > > > > > > And for the emergency calling. We have to look closely > at this in > > > > combination with a text gateway. Possible behaviour/action. > > > > And possible > > > > action in SIP. > > > > > > > > Right now I cannot say what has to happen, I must study the > > > > emergency calls > > > > in depth. But as I see it, using the text gateway, all SIP > > > > originating and > > > > receiving emergency calls will be possible for any > textphone user. > > > > > > > > Cheers > > > > > > > > Arnoud > > > > > > > > > > > > Drs. Arnoud A. T. van Wijk > > > > Viataal > > > > Research & Development > > > > Afdeling RDS > > > > Theerestraat 42 > > > > 5271 GD Sint-Michielsgestel > > > > The Netherlands. > > > > Mobile: +31651921948 > > > > International text telephone: +31735588408 > > > > > > > > -----Original Message----- > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > > On Behalf Of > > > > Rosen, Brian > > > > Sent: woensdag 25 februari 2004 23:08 > > > > To: 'Gunnar Hellstrom'; A vWijk; Gonzalo.Camarillo@ericsson.com; > > > > sipping@ietf.org > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > henry.sinnreich@mci.com; > > > > paulej@packetizer.com; gv@trace.wisc.edu > > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > I'm particularly interested in the last one, emergency calling. > > > > > > > > Given that you propose an appropriate SDP indicating > > > support for text, > > > > do you think there is anything else we need to do to in SIP > > > > to make this > > > > happen? I don't see anything. > > > > > > > > I know that the problem of using a legacy TDD device on > any kind of > > > > adapter is as problematic as current TDD; the call will answered > > > > as if it was a voice call, the baudot/whatever tones will be > > > > detected, > > > > and the operator will look for text. > > > > Can't think of any way to make that better. > > > > > > > > Do note that language preference headers should be set!!! > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > > Sent: Wednesday, February 25, 2004 4:54 PM > > > > > To: A vWijk; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > > henry.sinnreich@mci.com; > > > > > paulej@packetizer.com; gv@trace.wisc.edu > > > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > > > > > > I think PSTN textphone gateway invocation is one area where > > > > > we either need > > > > > protocol extensions, or need agreements on what current > > > > > mechanisms to use. > > > > > > > > > > Another is invocation of various kinds of relay services or > > > > > translation > > > > > services. > > > > > > > > > > A third is calling emergency services and reach positions > > > capable of > > > > > handling the type of communication that the user prefers. > > > > > > > > > > > > > > > > > > > > Gunnar > > > > > ------------------------------------------- > > > > > Gunnar Hellstrom > > > > > Omnitor AB > > > > > Renathvagen 2 > > > > > SE 121 37 Johanneshov > > > > > SWEDEN > > > > > +46 8 556 002 03 > > > > > Mob: +46 708 204 288 > > > > > www.omnitor.se > > > > > Gunnar.Hellstrom@Omnitor.se > > > > > -------------------------------------------- > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: sipping-admin@ietf.org > > > > > [mailto:sipping-admin@ietf.org]On Behalf Of > > > > > A vWijk > > > > > Sent: Tuesday, February 24, 2004 1:22 PM > > > > > To: Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > > henry.sinnreich@mci.com; > > > > > gunnar.hellstrom@omnitor.se; paulej@packetizer.com; > > > > gv@trace.wisc.edu > > > > > Subject: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > > > > > > Hello Gonzalo, > > > > > While there are device requirements in the text. Those > > > > > requirements and the > > > > > explanation on the different analogue text telephone systems > > > > > is included to > > > > > give the reader an understanding what kind of devices will > > > > > connect with > > > > > ToIP. And the need for the text gateways. And what the > > > > > different behaviour > > > > > can/may be compared to end to end IP devices. > > > > > The most important part will be the ToIP framwork and the > > > > > text gateways and > > > > > how such gateways will be used and work with the ToIP > framework. > > > > > > > > > > There is a ToIP framework where a terminal uses streaming > > > > > text as defined in > > > > > RFC2793 to connect with any other Interactive > > > > > texting/real-time streaming > > > > > text device. > > > > > This can be end-to-end IP, and a direct T140/RTP stream is > > > > > established with > > > > > SIP. But in other cases, a text gateway must be used to allow > > > > > T.140/RTP to > > > > > connect with a non IP text telephony device. > > > > > It can be an analogue text telephone (TDD/TTY) that uses a > > > > > text gateway to > > > > > be able to understand RFC2793 text. (PSTN-IP) > > > > > It can be a mobile phone running GPRS that uses the text > > > gateway to > > > > > understand RFC2793 text. (this exist right NOW using SIP! And > > > > > those gateways > > > > > will be used in mobile networks this year!) > > > > > Or a mobile text telephone using CTM via the text gateway to > > > > > communicate > > > > > with RFC2793 text. > > > > > Or even one analogue text telephone connecting to another > > > > > analogue text > > > > > telephone in a different country, and the PSTN's use IP to > > > > > connect the call. > > > > > > > > > > The question is for example, how do we use that gateway from > > > > > the IP side? Is > > > > > it invisible for the IP side? Or do we need special > > > > > extensions in SIP to > > > > > that the IP terminal knows it is communicating with the > > > > > end-device through > > > > > the text gateway? > > > > > There may be a slightly different call setup flow when a text > > > > > gateway is > > > > > included. > > > > > Or additional SIP messages indicating gateway activity. When > > > > > you connect for > > > > > example to an analogue text telephone with an RFC2793 capable > > > > > IP terminal > > > > > the capabilities will be less then IP to IP terminal directly > > > > > (different > > > > > transmission speeds, half/full duplex etc). > > > > > Or what to do with emergency calls that are in RFC > 2793 text only? > > > > > > > > > > That are requirements that will be defined and worked out in > > > > > this draft. > > > > > Also, we want to make everybody in SIP and SIPPING aware > > > > > about those text > > > > > gateways. So that complicated matters like how to send > > > analogue text > > > > > telephone text through a PSTN and connect with a SIP > > > > > telephone using RFC2793 > > > > > interactive texting. When using the text gateway, there is > > > > > then no need for > > > > > RFC 2833 events at the PSTN for text telephones. > > > > > > > > > > So, yes. I believe that this should be in the SIPPING WG. And > > > > > it will fit in > > > > > the charter - support for hearing-/speech-impaired calling. > > > > > > > > > > greetz > > > > > > > > > > Arnoud > > > > > > > > > > > > > > > > > > > > Drs. Arnoud A. T. van Wijk > > > > > Viataal > > > > > Research & Development > > > > > Afdeling RDS > > > > > Theerestraat 42 > > > > > 5271 GD Sint-Michielsgestel > > > > > The Netherlands. > > > > > Mobile: +31651921948 > > > > > International text telephone: +31735588408 > > > > > > > > > > >>> Gonzalo Camarillo > > > > > 24-02-04 10:21 >>> > > > > > Hello, > > > > > > > > > > the draft below provides a set of requirements for real-time > > > > > conversations using SIP. > > > > > http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-to > > > > ip-01.txt > > > > > > > > Nevertheless, I have found a lot of device requirements in > > > > the text, but > > > > I fail to understand which particular protocol requirements > > > we need to > > > > fulfill with new protocol extensions. > > > > > > > > While SIPPING is the right place to handle requirements > > > that will lead > > > > to new SIP protocol extensions, SIPPING may not be the > > > right place to > > > > deal with device requirements (e.g., text phones MUST have a > > > > display of > > > > at least 100 characters). > > > > > > > > Thanks, > > > > > > > > Gonzalo > > > > > > > > > > > > This communication is confidential and intended solely for > > > > the addressee(s). > > > > Any unauthorized review, use, disclosure or distribution is > > > > prohibited. If > > > > you believe this message has been sent to you in error, > > > > please notify the > > > > sender by replying to this transmission and delete the > > > message without > > > > disclosing it. Thank you. > > > > > > > > E-mail including attachments is susceptible to data corruption, > > > > interruption, unauthorized amendment, tampering and viruses, > > > > and we only > > > > send and receive e-mails on the basis that we are not liable > > > > for any such > > > > corruption, interception, amendment, tampering or viruses or any > > > > consequences thereof. > > > > > > > > > > > > _______________________________________________ > > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > _______________________________________________ > > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > _______________________________________________ > > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 20:45:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21801 for ; Sun, 29 Feb 2004 20:45:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcUo-0000Nh-AA for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 20:45:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i211jQld001461 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 20:45:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcUo-0000NU-5s for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 20:45:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21762 for ; Sun, 29 Feb 2004 20:45:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcUl-0002Hf-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 20:45:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcTG-0001zL-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 20:43:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxcSX-0001pr-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 20:43:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcST-0008Ux-Ou; Sun, 29 Feb 2004 20:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcRs-0008Ti-8E for sipping@optimus.ietf.org; Sun, 29 Feb 2004 20:42:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21608 for ; Sun, 29 Feb 2004 20:42:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcRp-0001n6-00 for sipping@ietf.org; Sun, 29 Feb 2004 20:42:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcQu-0001i3-00 for sipping@ietf.org; Sun, 29 Feb 2004 20:41:25 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AxcQ9-0001Xk-00 for sipping@ietf.org; Sun, 29 Feb 2004 20:40:37 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 12529; Sun, 29 Feb 2004 20:40:10 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Feb 2004 20:40:08 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A204@zoe.office.snowshore.com> Thread-Topic: manyfolks-sipping-ToIP-01 Thread-Index: AcP/Dchf1VZgVdrrQT2p/XZJCZCb5wAHyKlA From: "Eric Burger" To: "Gunnar Hellstrom" , , "Sipping (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: manyfolks-sipping-ToIP-01 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Works for me. > -----Original Message----- > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > Sent: Sunday, February 29, 2004 4:48 PM > To: Eric Burger; TOIP Mailing List; Sipping (E-mail) > Subject: RE: manyfolks-sipping-ToIP-01 >=20 >=20 > Eric, the specified transmission method is designed for both=20 > satisfying the > users and not straining networks: >=20 > In order to not strain networks, the transport level RFC2793 says that > characters should be buffered together in packets for shipping. The > recommendation for shipping packets with text is to use 300=20 > ms intervals > between transmissions. >=20 > The revision of RFC2793, in draft-ietf-avt-rfc2793bis-02 is=20 > stronger and > more clear about this RECOMMENDATION. >=20 > With the 300 ms interval between packet transmissions, we=20 > have a text flow > that is experienced to be close enough to=20 > character-by-character, and a > maximum network load of 3 packets per second containing=20 > around 3 kbit/s, > including redundancy. That is sustainable for most network=20 > connections. >=20 > Are there really typists that can type 60 characters per second???? > I would expect that the maximum load would come from speech-to-text > arrangements, where I would guess that 20 characters per=20 > second would be a > practical maximum. Therefore, 30 characters/s throughput in=20 > transmission > sounded sufficient for me. >=20 > With the buffering described above, this figure is not=20 > critical, so if you > have reasons to think that there is a real requirement for 60=20 > cps, we should > document it. >=20 > Subtitling a radio report from a football match by using=20 > speech-to-text > might be among the more challenging applications.. >=20 >=20 > Gunnar > ------------------------------------------- > Gunnar Hellstr=F6m > Omnitor AB > Renathv=E4gen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- >=20 >=20 > -----Original Message----- > From: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com]On > Behalf Of Eric Burger > Sent: Sunday, February 29, 2004 8:50 PM > To: toip@snowshore.com; Sipping (E-mail) > Subject: manyfolks-sipping-ToIP-01 >=20 >=20 > I like the "network must support a minimum of 30cps" for text=20 > (section 6, > requirement (d)). Then I thought about it: that's a ptime of=20 > 33ms. That is > OK. However, if we said minimum of 30cps, but really like 60cps > (professional typist), that is a ptime of 16ms, which would=20 > start to strain > many networks. >=20 > Why do we say that the file format for storage should be=20 > XHTML? Are we > archiving marked-up text? Why not just UTF-8? >=20 >=20 > - > This list is maintained by Snowshore Networks -=20 > http://www.snowshore.com > All comments on this list are the comments of the message=20 > originators and > Snowshore is not to be held responsible for any actions or=20 > comments found > on this list. The archives for this list can be found at > http://flyingfox.snowshore.com/toip_archive/maillist.html >=20 >=20 >=20 >=20 >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 21:20:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24536 for ; Sun, 29 Feb 2004 21:20:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd2Z-0004gG-Jj for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 21:20:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i212KJmc017986 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 21:20:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd2Z-0004g1-8a for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 21:20:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24533 for ; Sun, 29 Feb 2004 21:20:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axd2W-0006rZ-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 21:20:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axd1g-0006nk-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 21:19:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axd1N-0006j3-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 21:19:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd1J-0004UR-A7; Sun, 29 Feb 2004 21:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd0t-0004Tn-SI for sipping@optimus.ietf.org; Sun, 29 Feb 2004 21:18:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24421 for ; Sun, 29 Feb 2004 21:18:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axd0r-0006gj-00 for sipping@ietf.org; Sun, 29 Feb 2004 21:18:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axd04-0006YK-00 for sipping@ietf.org; Sun, 29 Feb 2004 21:17:45 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1Axcz1-0006Iy-00 for sipping@ietf.org; Sun, 29 Feb 2004 21:16:39 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i212G2U22334; Sun, 29 Feb 2004 18:16:02 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 29 Feb 2004 20:16:02 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304EECE85@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "'Eric Burger'" Cc: "Sipping (E-mail)" Date: Sun, 29 Feb 2004 20:16:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FF32.82468C18" Subject: [Sipping] RE: Comments on sip-guid-00 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 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. ------_=_NextPart_001_01C3FF32.82468C18 Content-Type: text/plain; charset="iso-8859-1" I think you're leaving a key element out of your argument of how unique this type of mechanism is. UAs are not envisioned to be generating these IDs on a whim, really it's something that they do at build time (ie embedded into the hardware perhaps, ala MAC, etc) or something they do at installation time (soft phone, etc). Because of this, I believe the uniqueness is much higher than you've calculated because in your example, all of those billion UA's would have to have been installed within that 15 minute period as well, typically. This is highly unlikely to ever occur, and furthermore, if it should ever occur, I'd be willing to eat my hat (given that the odds of me being struck dead by a meteorite or dying of old age are vastly more likely). =) Regards, Brian -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Sunday, February 29, 2004 1:50 PM To: Stucker, Brian [NGC:B617:EXCH] Cc: Sipping (E-mail) Subject: Comments on sip-guid-00 First, a statistics issue. I disagree that the time, in of itself, has quite the properties asserted. For example, given a billion UA's, if they have a 15-minute clock drift with a Normal distribution, well over 3,000 of them will think it is the same time in any given 5-minute window. That is still pretty good odds, but not the one-in-a-trillion asserted. This gets worse if the UA's have random number generators that have a correlation with their notion of time (e.g., time is used as a salt, boot at the same time with the same salt, etc.). [Yes, I did Monte Carlo simulations a lifetime ago...] The text goes through the algorithm for generating a GUID, but then the example has what looks like an IP address in it. Is that a proper interpretation? Where does the 10.33.15.8 come from? ------_=_NextPart_001_01C3FF32.82468C18 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comments on sip-guid-00

I think you're leaving a key element out of your = argument of how unique this type of mechanism is. UAs are not = envisioned to be generating these IDs on a whim, really it's something = that they do at build time (ie embedded into the hardware perhaps, ala = MAC, etc) or something they do at installation time (soft phone, etc). =

Because of this, I believe the uniqueness is much = higher than you've calculated because in your example, all of those = billion UA's would have to have been installed within that 15 minute = period as well, typically. This is highly unlikely to ever occur, and = furthermore, if it should ever occur, I'd be willing to eat my hat = (given that the odds of me being struck dead by a meteorite or dying of = old age are vastly more likely). =3D)

Regards,

Brian

-----Original Message-----
From: Eric Burger [mailto:eburger@snowshore.com]<= /FONT>
Sent: Sunday, February 29, 2004 1:50 PM
To: Stucker, Brian [NGC:B617:EXCH]
Cc: Sipping (E-mail)
Subject: Comments on sip-guid-00


First, a statistics issue.  I disagree that the = time, in of itself, has quite the properties asserted.  For = example, given a billion UA's, if they have a 15-minute clock drift = with a Normal distribution, well over 3,000 of them will think it is = the same time in any given 5-minute window.

That is still pretty good odds, but not the = one-in-a-trillion asserted.  This gets worse if the UA's have = random number generators that have a correlation with their notion of = time (e.g., time is used as a salt, boot at the same time with the same = salt, etc.).  [Yes, I did Monte Carlo simulations a lifetime = ago...]

The text goes through the algorithm for generating a = GUID, but then the example has what looks like an IP address in = it.  Is that a proper interpretation?  Where does the = 10.33.15.8 come from?

------_=_NextPart_001_01C3FF32.82468C18-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 21:28:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24879 for ; Sun, 29 Feb 2004 21:28:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd9a-0005Zh-67 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 21:27:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i212RYkI021430 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 21:27:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd9Z-0005ZZ-NH for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 21:27:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24873 for ; Sun, 29 Feb 2004 21:27:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axd9X-0007bk-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 21:27:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axd8g-0007V5-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 21:26:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axd86-0007Nk-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 21:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd87-00054E-KP; Sun, 29 Feb 2004 21:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd7Y-00052h-I1 for sipping@optimus.ietf.org; Sun, 29 Feb 2004 21:25:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24737 for ; Sun, 29 Feb 2004 21:25:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axd7V-0007Ks-00 for sipping@ietf.org; Sun, 29 Feb 2004 21:25:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axd6e-0007Ei-00 for sipping@ietf.org; Sun, 29 Feb 2004 21:24:33 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Axd65-00078k-00 for sipping@ietf.org; Sun, 29 Feb 2004 21:23:57 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i212NPr29249 for ; Sun, 29 Feb 2004 20:23:25 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <17CK1JBG>; Mon, 1 Mar 2004 02:23:24 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00B3EF82C@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sipping@ietf.org Date: Mon, 1 Mar 2004 02:23:23 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] comments on draft-schulzrinne-sipping-emergency-arch Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 In general, I am happy with this draft, but in reading it, I did have a few specific comments. 1) Section 3 (Terminology). I am confused here, and in the rest of the document, about the distinction between ECC and PSAP. I think the issue here is that as defined by the associated text, these are actually different concepts in some countries, yet the text goes on to say that in USA, PSAP is the ECC. Maybe we need to clarify. 2) Section 5.2. Mobile systems, possible in conjunction with the cell site location, may also transmit mobile country code and mobile network code of the host network. This MCC and MNC in itself does constitute location information, in that it tells that the user (with border constraints) is in a particular country) - which may be sufficient itself for determining the ECC to be used. 3) Section 5.3. Somewhere around here, for any particular emergency call, we need to identify that it is possible to have multiple elements of location information generated by different entities involved in the call (e.g. terminal generated, outbound proxy generated, etc.). We need a statement that each location can be added to the call information, and that one does not overwrite another. It is up to the ECC to decide which (if any) location it wishes to believe, possibly in association with any location from the end user received via the media path. 4) Section 5.4. Where information is delivered later, do we need an indicator within the INVITE that such information may be available later in the call? What is the mechanism for providing information later in the call (push or pull), i.e. is additional information just sent later in the dialog in another request, or does the location gathering entity indicate the availability of new information which can then be fetched. 5) Section 7. This section seems to assume sips. As this is apparently a hop-by-hop mechanism, what is wrong with depending on any hop by hop security mechanism, e.g. IPsec - why does it have to be SIPs. 6) Section 9. In addition to the generic mechanism mentioned here, there may be access transport specific mechanisms for downloading this information to the UE. For example, a 3GPP phone from release 5 onwards can have this information downloaded from visited network entities at network registration time. The existence of these mechanisms should be acknowledged in the document at this point. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 21:29:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25007 for ; Sun, 29 Feb 2004 21:29:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdAa-0005qJ-RM for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 21:28:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i212SaAV022453 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 21:28:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdAa-0005q4-N6 for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 21:28:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24944 for ; Sun, 29 Feb 2004 21:28:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxdAY-0007kz-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 21:28:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axd9i-0007dJ-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 21:27:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axd92-0007Vh-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 21:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd94-0005Fj-BN; Sun, 29 Feb 2004 21:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd8M-0005Dc-RU for sipping@optimus.ietf.org; Sun, 29 Feb 2004 21:26:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24782 for ; Sun, 29 Feb 2004 21:26:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axd8K-0007RQ-00 for sipping@ietf.org; Sun, 29 Feb 2004 21:26:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axd7P-0007K5-00 for sipping@ietf.org; Sun, 29 Feb 2004 21:25:19 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1Axd6Z-00078z-00 for sipping@ietf.org; Sun, 29 Feb 2004 21:24:27 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 7255; Sun, 29 Feb 2004 21:24:00 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Feb 2004 21:23:58 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A212@zoe.office.snowshore.com> Thread-Topic: Comments on sip-guid-00 Thread-Index: AcP/MycG90zJjjdjRMakdF/g5Mdu1wAAIkjw From: "Eric Burger" To: "Brian Stucker" Cc: "Sipping (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: Comments on sip-guid-00 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Agreed :-) -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Sunday, February 29, 2004 9:16 PM To: Eric Burger Cc: Sipping (E-mail) Subject: RE: Comments on sip-guid-00 I think you're leaving a key element out of your argument of how unique = this type of mechanism is. UAs are not envisioned to be generating these = IDs on a whim, really it's something that they do at build time (ie = embedded into the hardware perhaps, ala MAC, etc) or something they do = at installation time (soft phone, etc).=20 Because of this, I believe the uniqueness is much higher than you've = calculated because in your example, all of those billion UA's would have = to have been installed within that 15 minute period as well, typically. = This is highly unlikely to ever occur, and furthermore, if it should = ever occur, I'd be willing to eat my hat (given that the odds of me = being struck dead by a meteorite or dying of old age are vastly more = likely). =3D) Regards,=20 Brian=20 -----Original Message-----=20 From: Eric Burger [mailto:eburger@snowshore.com]=20 Sent: Sunday, February 29, 2004 1:50 PM=20 To: Stucker, Brian [NGC:B617:EXCH]=20 Cc: Sipping (E-mail)=20 Subject: Comments on sip-guid-00=20 First, a statistics issue. I disagree that the time, in of itself, has = quite the properties asserted. For example, given a billion UA's, if = they have a 15-minute clock drift with a Normal distribution, well over = 3,000 of them will think it is the same time in any given 5-minute = window. That is still pretty good odds, but not the one-in-a-trillion asserted. = This gets worse if the UA's have random number generators that have a = correlation with their notion of time (e.g., time is used as a salt, = boot at the same time with the same salt, etc.). [Yes, I did Monte = Carlo simulations a lifetime ago...] The text goes through the algorithm for generating a GUID, but then the = example has what looks like an IP address in it. Is that a proper = interpretation? Where does the 10.33.15.8 come from? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 21:37:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25497 for ; Sun, 29 Feb 2004 21:37:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdIR-0006Hw-3Q for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 21:36:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i212ahWd024166 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 21:36:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdIR-0006Hh-0I for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 21:36:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25492 for ; Sun, 29 Feb 2004 21:36:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxdIO-0000vd-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 21:36:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxdHU-0000oZ-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 21:35:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxdGr-0000gU-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 21:35:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdGq-000657-Ip; Sun, 29 Feb 2004 21:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdGQ-00062v-At for sipping@optimus.ietf.org; Sun, 29 Feb 2004 21:34:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25347 for ; Sun, 29 Feb 2004 21:34:35 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxdGN-0000eH-00 for sipping@ietf.org; Sun, 29 Feb 2004 21:34:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxdFW-0000Wc-00 for sipping@ietf.org; Sun, 29 Feb 2004 21:33:43 -0500 Received: from imo-m24.mx.aol.com ([64.12.137.5]) by ietf-mx with esmtp (Exim 4.12) id 1AxdEL-0000JV-00 for sipping@ietf.org; Sun, 29 Feb 2004 21:32:29 -0500 Received: from Mpierce1@aol.com by imo-m24.mx.aol.com (mail_out_v36_r4.14.) id l.15e.2bc7fd9f (3972) for ; Sun, 29 Feb 2004 21:31:58 -0500 (EST) Message-ID: <15e.2bc7fd9f.2d73fa9e@aol.com> Date: Sun, 29 Feb 2004 21:31:58 EST To: sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_15e.2bc7fd9f.2d73fa9e_boundary" X-Mailer: 6.0 for Windows XP sub 10500 Subject: [Sipping] WGLC for draft-ietf-sipping-reason-header-for-preemption-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 --part1_15e.2bc7fd9f.2d73fa9e_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Comments on WGLC for reason header. Sorry that I didn't review this version and comment by Feb 29. I had thought that this issue was resolved after our e-mail discussion some time ago. The draft defines 2 reasons for preemption (access and network) and provides an indicatation to the UA of which one occurred. The requirment for Assured Service (otherwise known as MLPP) is that the preempted party is not allowed to know why the preemption occurred. This would have the result of telling the person something they are not supposed to know, that the party they were talking to got a more important call. Presuming that some network may want to notify the UA of the reason, this needs to be corrected by adding a third reason in Section 6.0 as follows (also in Section 4.0 as appropriate): In instances where this namespace is used to indicate preemption, but it is not desirable to notify the UA at the end of the preempted session the reason for the preemption, the following syntax shall be used: Reason: preemption ; cause=3 ;text="Unspecified_Preemption" This case may be used in place of either the UA_Preemption in Section 4.1 or the RSVP_Preemption in Section 4.2. If neccesary, a new Section 4.3 could be added to explain this 3rd value, that is, why/when it would be used. This would be one paragraph, no diagram needed. I'll provide it if needed. Mike Pierce --part1_15e.2bc7fd9f.2d73fa9e_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Comments on W= GLC for reason header.
Sorry that I didn't review this version and comment by Feb 29. I had tho= ught that this issue was resolved after our e-mail discussion some time ago.

The draft defines 2 reasons for preemption (access and network) and prov= ides an indicatation to the UA of which one occurred.

The requirment for Assured Service (otherwise known as MLPP) is that the= preempted party is not allowed to know why the preemption occurred. This wo= uld have the result of telling the person something they are not supposed to= know, that the party they were talking to got a more important call.

Presuming that some network may want to notify the UA of the reason, thi= s needs to be corrected by adding a third reason in Section 6.0 as follows (= also in Section 4.0 as appropriate):

In instances where this namespace is used to indicate preemption,=20
but it is not desirable to notify the UA at the end of the preempted= =20
session the reason for the preemption, the following syntax shall be= used:

  Reason: preemption ; cause=3D3 ;text=3D"Unspecified_Pre= emption"

  This case may be used in place of either the UA_Preempt= ion in=20
  Section 4.1 or the RSVP_Preemption in Section 4.2.

If neccesary, a new Section 4.3 could be added to explain this 3rd value= , that is, why/when it would be used. This would be one paragraph, no diagra= m needed. I'll provide it if needed.

Mike Pierce
--part1_15e.2bc7fd9f.2d73fa9e_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 22:20:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28061 for ; Sun, 29 Feb 2004 22:20:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axdyf-0001Mn-Dq for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 22:20:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i213KLMv005243 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 22:20:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axdyf-0001MU-4s for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 22:20:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28055 for ; Sun, 29 Feb 2004 22:20:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axdyb-0005co-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 22:20:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axdxg-0005Yg-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 22:19:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxdxN-0005Ua-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 22:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdxN-0001CE-Ly; Sun, 29 Feb 2004 22:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axdwn-0001Bw-Am for sipping@optimus.ietf.org; Sun, 29 Feb 2004 22:18:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28011 for ; Sun, 29 Feb 2004 22:18:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axdwk-0005U6-00 for sipping@ietf.org; Sun, 29 Feb 2004 22:18:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axdvl-0005Pi-00 for sipping@ietf.org; Sun, 29 Feb 2004 22:17:21 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1AxdvK-0005Ke-00 for sipping@ietf.org; Sun, 29 Feb 2004 22:16:54 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 29 Feb 2004 19:15:25 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i213GJT4004772; Sun, 29 Feb 2004 22:16:19 -0500 (EST) Received: from cisco.com (sin-vpn-client-20-15.cisco.com [10.68.20.15]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGK29260; Sun, 29 Feb 2004 22:16:15 -0500 (EST) Message-ID: <4042AAFD.4060506@cisco.com> Date: Sun, 29 Feb 2004 22:16:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: "Cullen Jennings (E-mail)" , "Sipping (E-mail)" Subject: Re: [Sipping] Comments on sip-voicemail-uri-01 References: <4A3384433CE2AB46A63468CB207E209DB1A1DE@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric Burger wrote: > Big question: why bother if we get everything from history-info? I know, "it's easier on the UAS", but do we care? I think the big difference is that it moves the responsibility for who decides. If you *want* the voicemail system to decide which mailbox to use, then history-info is a plausible mechanism for giving it all the raw data, and then letting it decide. But if you want to let something else (e.g. a proxy) decide which mailbox (perhaps based on policy for the AOR rather than policy for the VM system) then some mechanism to explicitly tell the VM system your choice seems more appropriate. I suppose the proxy could lie in the history-info, based on a presumption of what algorithm the VM system uses to choose the mailbox, but I certainly hope nobody goes that way. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 23:16:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00010 for ; Sun, 29 Feb 2004 23:16:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axeqx-0005cu-AT for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 23:16:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i214GRgx021627 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 23:16:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axeqx-0005ck-3d for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 23:16:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29998 for ; Sun, 29 Feb 2004 23:16:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axeqv-0002np-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:16:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axeq1-0002j1-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:15:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axepe-0002e4-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:15:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axepb-0005KV-CK; Sun, 29 Feb 2004 23:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axep5-0005Jf-5d for sipping@optimus.ietf.org; Sun, 29 Feb 2004 23:14:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29953 for ; Sun, 29 Feb 2004 23:14:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axep3-0002d5-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:14:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxeoY-0002Yo-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:14:00 -0500 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx with esmtp (Exim 4.12) id 1Axenh-0002Mk-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:13:05 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTV00GCHQD0ER@firewall.mci.com> for sipping@ietf.org; Mon, 01 Mar 2004 04:12:36 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTV00B01QCZRI@pmismtp02.mcilink.com>; Mon, 01 Mar 2004 04:12:36 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.104.128]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTV00B62QCV38@pmismtp02.mcilink.com>; Mon, 01 Mar 2004 04:12:35 +0000 (GMT) Date: Sun, 29 Feb 2004 22:12:31 -0600 From: Alan Johnston Subject: RE: [Sipping] Conferencing for UAs In-reply-to: X-Sender: Alan.Johnston@pop.mcit.com To: Markus.Isomaki@nokia.com, Gonzalo.Camarillo@ericsson.com Cc: hisham.khartabil@nokia.com, sipping@ietf.org, oritl@microsoft.com, Miguel.An.Garcia@nokia.com Message-id: <5.2.1.1.0.20040229221119.02c344a0@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Markus, I think you are on the right track. Look for some movement on harmonizing exploders and conferencing this week - stay tuned... Thanks, Alan Johnston MCI sip:alan@sipstation.com At 03:16 PM 2/29/2004 +0200, Markus.Isomaki@nokia.com wrote: >Hi, > >I also hope there could be more clarity on the relationship between >exploders and conferencing work. Some thoughts below. > >One clear use case for exploders is the establishment of a "dial-out >ad-hoc" conference. One of Gonzalo's drafts proposes that the exploder >B2BUA (which in this case becomes a conference focus) could return to the >originating UA a reference (URI) to the list, after which the UA could use >e.g. XCAP to manage the list out-of-band. The idea seems to be that the >default format for this list indeed would be the XCAP resource list. > >In conferencing framework this list clearly overlaps with the dial-out >list concept to be defined in CPCP. Also, if the semantics of removing a >user from the list will result in ejection of this user from the >conference, this list may overlap with some other functionality of CPCP too. > >My proposal to make the exploders and CPCP compliant with each other would be: >- When the conference is established by invoking an exploder, the >conference server will use the exploder-list to populate a CPCP document >in such a way that its semantics match with what was done with the exploder. >- URI for this CPCP document is provided in 200 OK using the mechanisms >dicussed elsewhere (Call-info purpose, new header, ...). >- Conference participants can thereafter make conference policy operations >by doing changes to this document, and the situation is as if the >conference was originally created by CPCP in the first place. >- If ad hoc list management via re-INVITEs is still allowed, there needs >to be a clear mapping how adding/removing list entries interacts with the >CPCP document. > >To enable this the CPCP semantics still need more clarity, and maybe also >adopting the XCAP resource list format for the possible dial-out etc. >lists in that document would help this mapping. > >(We could still keep the simple non-CPCP controllable conference case, >where the only manipulated object would be a simple resource list. In this >case access lists and other such features woould not be supported.) > >Do people think that this would be feasible? Or would we be getting to an >interaction that is too complex to model? In general I think there's room >for both exploders AND CPCP, so it would be important to specify how they >interwork. > >Regards, > Markus > > > -----Original Message----- > > From: sipping-admin@ietf.org > > [mailto:sipping-admin@ietf.org]On Behalf Of > > ext Alan Johnston > > Sent: 26 February, 2004 21:05 > > To: Gonzalo Camarillo > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); sipping@ietf.org; > > oritl@microsoft.com; Garcia Miguel.An (Nokia-NRC/Helsinki) > > Subject: Re: [Sipping] Conferencing for UAs > > > > > > > > At 02:13 PM 2/26/2004 +0200, Gonzalo Camarillo wrote: > > >Alan, > > > > > >I agree with you that we do not want to change the > > conferencing framework > > >at this point in time (I already said in my previous mail that I > > >understood that my comments related to this came too late). > > Still, I found > > >the discussion useful to understand your point of view. > > > > Gonzalo, > > > > Glad to hear that. I'd be happy to think about how to extend the > > conferencing work to cover the exploder scenarios you are > > proposing with > > MESSAGE, INVITE, and even REFER. With the current drafts, > > I have a hard > > time understanding how to do this, but I look forward to > > clarifications. The SUBSCRIBE exploder does not seem to have any > > conferencing semantics, but seems to be a SIMPLE application > > since it is > > tightly coupled to the presence application. > > > > Thanks, > > Alan Johnston > > MCI > > sip:alan@sipstation.com > > > > > > >In any event, the topic I am interested in is the creation > > of different > > >resources (identified by URIs) by a single request. In > > particular, how to > > >communicate those URIs to the UAC. (I sent separate comments > > on Hisham's > > >draft.) > > > > > >I hope we can discuss these issues in Korea. > > > > > >Thanks, > > > > > >Gonzalo > > > > > > > > >Alan Johnston wrote: > > > > > >>At 09:47 AM 2/25/2004 +0200, Gonzalo Camarillo wrote: > > >> > > >>>Hi Alan, > > >>> > > >>>I understand that my comments come late in the game and > > that it might be > > >>>impossible to change the conferencing framework at this > > point. In any > > >>>event, I do not agree with your statement below: > > >>> > > >>>>No - this is the problem. You are looking at your single narrow > > >>>>application. > > >>> > > >>> > > >>>I believe I am actually looking at a much wider range of > > applications > > >>>than just conferencing. So, to me, the problem is that the > > conferencing > > >>>framework is too focused on a "single narrow application"; > > conferencing. > > >> > > >>Gonzalo, > > >>If you are saying that some of your exploder services do not have a > > >>conferencing component, then I agree. Some of the exploder > > services seem > > >>to just be a "request to fork" to a set of URIs. Others > > definitely have > > >>conferencing semantics. The ones with conferencing > > semantics, I believe, > > >>can be, and should be modeled using the conferencing framework. > > >>The problem is that each method seems to have a different set of > > >>semantics as to what exploding that method means - INVITE > > is handled > > >>differently from SUBSCRIBE, from MESSAGE. From a high > > level, exploders > > >>may seem to be a consistent set of services. However, as I > > delve into > > >>the details and think about call flows (something absent > > from any of the > > >>exploder drafts), a different story emerges. > > >>I think we need to explore exactly the services and call > > flows that are > > >>being envisioned for exploders before proposing major > > changes to our > > >>conferencing framework, which I believe is well understood > > and documented. > > >> > > >>>In a conferencing service, there is a single resource > > created by the > > >>>initial INVITE; a conference. That's why the server can > > use the Contact > > >>>header field to send it back to the UAC. If you think of > > services that > > >>>create more than one resource (e.g., an explosion and a > > conference), the > > >>>server may not want to use the same URI for both. Moreover, > > >>>conceptually, is is not a good thing to use the same URI > > to identify > > >>>both resources. > > >> > > >>As Paul has pointed out - they are the same resource. > > Additionally, it > > >>is a trivial SIP routing issue to fix this - many proxies > > do method-based > > >>request routing - that would completely solve your problem > > of sending > > >>SUBSCRIBEs to a different UA than the initial request. > > >> > > >>>So, my main concern is the semantics overload of the > > Contact header. (We > > >>>abused this header when design REGISTER as well, by the > > way. That's why > > >>>I do not want to do it again.) > > >>> > > >>>In my opinion, the Contact header is the URI where you > > send subsequent > > >>>requests within the dialog. If the server wants to tell > > the client that > > >>>a resource (e.g., a conference) has been created, it can > > use a different > > >>>header to include the URI of such a resource. Note that, > > if you want > > >>>both URIs to be the same (like in the conferencing case), > > you can do it. > > >>> > > >>>Contact: sip:1234@a.com;isfocus > > >>>Resource: sip:1234@a.com;isfocus > > >>> > > >>>An entity receiving these headers would use the URI in the Contact > > >>>header to send subsequent requests *within* the dialog, > > and the URI in > > >>>the other header to send requests *outside* that dialog > > (e.g., SUBSCRIBE > > >>>to the conference package). > > >> > > >>No. A GRUU should be used in the Contact, and its routing is valid > > >>outside the dialog. > > >> > > >>>In brief, instead of sticking the conference URI in a > > Contact header and > > >>>label that URI with an isfocus parameter so that the UAC > > figures what is > > >>>going on, I find it more explicit to use a different > > header. Although, > > >>>as I said, I understand that this comment comes late and > > that may not be > > >>>useful at this point. > > >> > > >>I think much more work is needed before the working group > > can evaluate > > >>the exploders work and see how and if it fits in with > > existing concepts > > >>and approaches. > > >>Thanks, > > >>Alan Johnston > > >>MCI > > >>sip:alan@sipstation.com > > >> > > >>>Thanks, > > >>> > > >>>Gonzalo > > >>> > > >>> > > >>>This communication is confidential and intended solely for the > > >>>addressee(s). Any unauthorized review, use, disclosure or > > distribution > > >>>is prohibited. If you believe this message has been sent to you in > > >>>error, please notify the sender by replying to this > > transmission and > > >>>delete the message without disclosing it. Thank you. > > >>> > > >>>E-mail including attachments is susceptible to data corruption, > > >>>interruption, unauthorized amendment, tampering and > > viruses, and we only > > >>>send and receive e-mails on the basis that we are not > > liable for any > > >>>such corruption, interception, amendment, tampering or > > viruses or any > > >>>consequences thereof. > > >>> > > >>> > > >>>_______________________________________________ > > >>>Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > >>>This list is for NEW development of the application of SIP > > >>>Use sip-implementors@cs.columbia.edu for questions on current sip > > >>>Use sip@ietf.org for new developments of core SIP > > > > > >-- > > >Gonzalo Camarillo Phone : +358 9 299 33 71 > > >Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > >Telecom R&D Fax : +358 9 299 30 52 > > >FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > >Finland http://www.hut.fi/~gonzalo > > > > > > > > >This communication is confidential and intended solely for the > > >addressee(s). Any unauthorized review, use, disclosure or > > distribution is > > >prohibited. If you believe this message has been sent to you > > in error, > > >please notify the sender by replying to this transmission > > and delete the > > >message without disclosing it. Thank you. > > > > > >E-mail including attachments is susceptible to data corruption, > > >interruption, unauthorized amendment, tampering and viruses, > > and we only > > >send and receive e-mails on the basis that we are not liable > > for any such > > >corruption, interception, amendment, tampering or viruses or any > > >consequences thereof. > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 23:27:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00586 for ; Sun, 29 Feb 2004 23:27:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axf1d-00070K-Tt for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 23:27:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i214RTVt026918 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 23:27:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axf1d-000705-Dz for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 23:27:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00575 for ; Sun, 29 Feb 2004 23:27:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axf1b-0003t1-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:27:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axf0l-0003o4-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:26:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axf0G-0003iH-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:26:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axf0E-0006nt-IY; Sun, 29 Feb 2004 23:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axezf-0006mJ-Cg for sipping@optimus.ietf.org; Sun, 29 Feb 2004 23:25:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00504 for ; Sun, 29 Feb 2004 23:25:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axezd-0003gn-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:25:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axeyg-0003bz-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:24:26 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AxeyN-0003XS-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:24:07 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i214O7Ah029352 for ; Mon, 1 Mar 2004 05:24:07 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 05:24:07 +0100 Received: from ericsson.com (rvi2-93-147.sw.ericsson.se [153.88.93.147]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFN4Q1M; Mon, 1 Mar 2004 05:24:39 +0100 Message-ID: <4042BAE3.9010804@ericsson.com> Date: Mon, 01 Mar 2004 06:24:03 +0200 X-Sybari-Trust: 9338c2fd c77f3eb6 73f6aa1c 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: "Sipping (E-mail)" References: <4A3384433CE2AB46A63468CB207E209DB1A1EC@zoe.office.snowshore.com> In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB1A1EC@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2004 04:24:07.0511 (UTC) FILETIME=[09954670:01C3FF45] Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Forwarding URI list requirement (sipping-exploders-02) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, I am not sure if we need that requirement either, actually... this requirement deals with something similar to the cc: header in email... Let's discuss whether or not we need it. Opinions? Gonzalo Eric Burger wrote: > Requirement 8 says it must be possible to forward a URI list to the recipients of a message sent using the list. > > Where did the requirement come from? I think that would help decide if it belongs. I think it opens up a whole security issue in that just because parties B and C got blasted by my spam message, C still might not want B to get their address. -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 23:43:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01563 for ; Sun, 29 Feb 2004 23:43:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfGG-0000Lz-8E for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 23:42:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i214gadb001355 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 23:42:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfGF-0000Lm-Nu for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 23:42:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01554 for ; Sun, 29 Feb 2004 23:42:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfGD-0005NY-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:42:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfFL-0005Hc-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:41:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxfEk-0005Aw-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfEj-0008Iu-Pp; Sun, 29 Feb 2004 23:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfEE-0008Gy-9V for sipping@optimus.ietf.org; Sun, 29 Feb 2004 23:40:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01440 for ; Sun, 29 Feb 2004 23:40:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfEC-00059E-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:40:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfDJ-000548-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:39:33 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AxfCM-0004sw-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:38:34 -0500 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i214c31m005347; Sun, 29 Feb 2004 20:38:03 -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 UAA05969; Sun, 29 Feb 2004 20:38:01 -0800 (PST) Message-Id: <4.3.2.7.2.20040229221258.0231fec0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 29 Feb 2004 22:38:03 -0600 To: Mpierce1@aol.com, sipping@ietf.org From: "James M. Polk" Subject: Re: [Sipping] WGLC for draft-ietf-sipping-reason-header-for-preemption-00.txt In-Reply-To: <15e.2bc7fd9f.2d73fa9e@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 comments in-line At 09:31 PM 2/29/2004 -0500, Mpierce1@aol.com wrote: >Comments on WGLC for reason header. >Sorry that I didn't review this version and comment by Feb 29. I had >thought that this issue was resolved after our e-mail discussion some time >ago. > >The draft defines 2 reasons for preemption (access and network) and >provides an indicatation to the UA of which one occurred. > >The requirment for Assured Service (otherwise known as MLPP) is that the >preempted party is not allowed to know why the preemption occurred. This >would have the result of telling the person how exactly is informing the UA translate into telling the user why something has happened always (which is the way I read your question)? Communicating in the BYE "why" a session was preempted to all the SIP entities (including the remote UA) is a network mgmt requirement (SIP layer synchronization) and a function at least some want knowledge of, perhaps not the DSN at the moment. >something they are not supposed to know, that the party they were talking >to got a more important call. > >Presuming that some network may want to notify the UA of the reason, this >needs to be corrected by adding a third reason in Section 6.0 as follows >(also in Section 4.0 as appropriate): I believe this can be accomplished by using the following: Reason: Q.850; cause=8 which is a generic preemption indication for the circuit world if others disagree - adding this 3rd "reason" is fine with me >In instances where this namespace is used to indicate preemption, >but it is not desirable to notify the UA at the end of the preempted >session the reason for the preemption, the following syntax shall be used: > > Reason: preemption ; cause=3 ;text="Unspecified_Preemption" > > This case may be used in place of either the UA_Preemption in > Section 4.1 or the RSVP_Preemption in Section 4.2. > >If neccesary, a new Section 4.3 could be added to explain this 3rd value, >that is, why/when it would be used. This would be one paragraph, no >diagram needed. I'll provide it if needed. > >Mike Pierce cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 23:44:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01640 for ; Sun, 29 Feb 2004 23:44:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfHA-0000SJ-Cw for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 23:43:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i214hWBj001745 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 23:43:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfHA-0000S4-9X for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 23:43:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01607 for ; Sun, 29 Feb 2004 23:43:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfH8-0005Tk-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:43:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfGG-0005O0-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:42:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxfFg-0005Hw-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:42:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfFh-0008TX-Gk; Sun, 29 Feb 2004 23:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfF4-0008SW-4L for sipping@optimus.ietf.org; Sun, 29 Feb 2004 23:41:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01464 for ; Sun, 29 Feb 2004 23:41:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfF2-0005ET-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:41:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfE3-000588-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:40:20 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AxfD3-0004ye-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:39:17 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i214dHYG029350 for ; Mon, 1 Mar 2004 05:39:17 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 05:39:17 +0100 Received: from ericsson.com (rvi2-93-147.sw.ericsson.se [153.88.93.147]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFN4S19; Mon, 1 Mar 2004 05:39:49 +0100 Message-ID: <4042BE71.2080600@ericsson.com> Date: Mon, 01 Mar 2004 06:39:13 +0200 X-Sybari-Trust: 3abc0b88 c77f3eb6 73f6aa1c 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: volkerh@bell-labs.com, "Jonathan Rosenberg (E-mail)" , "Sipping (E-mail)" References: <4A3384433CE2AB46A63468CB207E209DB1A1DD@zoe.office.snowshore.com> In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB1A1DD@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2004 04:39:17.0823 (UTC) FILETIME=[282BDCF0:01C3FF47] Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Comments on Session-Independent Policy document Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > Considering the security implications, a content server MUST support > sips: and MUST support https for retrieval. Yes, when we do the security considerations section we will talk about this... mandating TLs sounds sensible. > Where do the codec names (6.1.2.1.1) come from? RTP? If so, say so. Yes, they come from the RTP. They are the names of the payloads... we'll say so. Thanks for the comments, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 23:44:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01695 for ; Sun, 29 Feb 2004 23:44:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfHB-0000TA-Vw for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 23:43:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i214hXkk001798 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 23:43:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfHB-0000Sv-QT for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 23:43:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01615 for ; Sun, 29 Feb 2004 23:43:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfH9-0005Tu-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:43:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfGI-0005OG-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:42:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxfFn-0005I4-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:42:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfFj-00007H-O1; Sun, 29 Feb 2004 23:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfF9-0008Ss-Eu for sipping@optimus.ietf.org; Sun, 29 Feb 2004 23:41:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01485 for ; Sun, 29 Feb 2004 23:41:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfF7-0005FH-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:41:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfEF-00059n-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:40:34 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AxfDh-00053G-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:39:57 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i214dGUG005259; Sun, 29 Feb 2004 23:39:16 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA04371; Sun, 29 Feb 2004 23:39:14 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Sun, 29 Feb 2004 23:39:14 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6475@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Gunnar Hellstrom'" , Barry Dingle , "'Arnoud van Wijk'" , Gonzalo.Camarillo@ericsson.com, sipping@ietf.org Cc: rrroy@att.com, henry.sinnreich@mci.com, paulej@packetizer.com, gv@trace.wisc.edu, Len Bytheway Subject: RE: Betr.: [Sipping] ToIP Requirements Date: Sun, 29 Feb 2004 23:39:12 -0500 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 Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This means that there is no way to detect a text call with V.18 without answering the call, which is the same as a BAUDOT device. All you are pointing out is that you can tell right away with V.18, which is not the case for BAUDOT. So, for emergency calling, there is no difference. All calls go to the answering point, which has to be text capable. As was pointed out in previous messages, some jurisdictions have separate phone numbers for text emergency calls. So, from the emergency call perspective: SIP calls marked with Text media would be routed to a text capable=20 answering point. This is the fundamental capability we can=20 do something about. It requires no new mechanisms. Mechanisms that learn local emergency phone numbers need to be able to accommodate text-specific numbers. Older V.18 and BAUDOT TDD devices would arrive at emergency centers in the way they do now, and are indistinguishable from voice calls until they are answered. In the next revision of ToIP requirements, can we delete (c) from Section 8.8? There is no concept of an emergency stream; a call can be distinguished as an emergency call and which streams it offers is not germane. Brian=20 > -----Original Message----- > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > Sent: Sunday, February 29, 2004 9:26 PM > To: Rosen, Brian; Barry Dingle; 'Arnoud van Wijk'; > Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > Cc: rrroy@att.com; henry.sinnreich@mci.com; paulej@packetizer.com; > gv@trace.wisc.edu; Len Bytheway > Subject: RE: Betr.: [Sipping] ToIP Requirements >=20 >=20 > 1. How it is in PSTN: > A calling V.18 sends a specific data pattern for text=20 > telephony in the V.8 > signal CI. > It is sent in the connected voice channel. > So, as with all calls from PSTN, there is no indication=20 > before the call is > set up about what kind of media will be used. >=20 > But it is far more easy to identify it as a textphone call=20 > than it is for > some of the old systems. E.G the US system "Baudot" is silent=20 > when calling, > and the answering side must guess that it is a textphone. >=20 > There is not yet any really clear trend to move to V.18 for=20 > users in USA. > Therefore I agree that the mechanisms for emergency calls=20 > must for a long > time accomplish for the tedious task to try to respond in=20 > text on PSTN to > all incoming silent calls to discriminate the text callers.=20 > That response > should be done with V.18 signals, so that it at least is=20 > prepared for more > convenient handling when people have moved to using V.18 textphones. >=20 > 2. In SIP. > In SIP, we have text in a separate media stream in the call.=20 > An emergency > centre should have capability to use both voice and text=20 > simultaneously. > There are mechanisms in discussion about indicating=20 > preference for handling > the call with text as the main medium. I am not sure that we=20 > can require > that preference to be set in a SIP terminal used for an=20 > emergency call by a > text depending person. > So, the safe handling would be for the emergency centre to offer text > capability, and if text connection is achieved, an automatic=20 > text greeting > is sent in that channel, while the emergency agent responds=20 > in voice. If the > caller then starts using the text channel, it is evident=20 > enough that text is > preferred. >=20 >=20 > Gunnar >=20 > ------------------------------------------- > Gunnar Hellstr=F6m > Omnitor AB > Renathv=E4gen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- >=20 >=20 > -----Original Message----- > From: sipping-admin@ietf.org=20 > [mailto:sipping-admin@ietf.org]On Behalf Of > Rosen, Brian > Sent: Monday, March 01, 2004 1:16 AM > To: Barry Dingle; 'Arnoud van Wijk'; 'Gunnar Hellstrom'; > Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > Cc: rrroy@att.com; henry.sinnreich@mci.com; paulej@packetizer.com; > gv@trace.wisc.edu; Len Bytheway > Subject: RE: Betr.: [Sipping] ToIP Requirements >=20 >=20 > While we can, and have, specified a single worldwide URI > for emergency calls, I believe it is not even technically > possible to find a single 3 digit number that is not > already in use somewhere. Thus, I suspect anyone > dreaming that such a thing will happen probably is > going to be disappointed. >=20 > Since existing TDD devices do not provide an indication > that they are present until after the call is completed, > I think that we should not even consider use of any > kind of gateway for emergency calls. This is true of > V.18 devices also, correct? >=20 > Having a special number for text emergency calls does > have an impact on the sos draft however. The draft > discusses use of local emergency numbers. That text > may have to be expanded to cover such a case. >=20 > Are there other examples where there are special > numbers that are used for a subset of emergency > calls other than this kind of example (discriminate > based on media) and the examples of a direct number > for a specific responder, for example, police? >=20 > Brian >=20 > > -----Original Message----- > > From: Barry Dingle [mailto:barry.dingle@bigfoot.com.au] > > Sent: Thursday, February 26, 2004 6:49 PM > > To: Rosen, Brian; 'Arnoud van Wijk'; 'Gunnar Hellstrom'; > > Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > Cc: rrroy@att.com; henry.sinnreich@mci.com; paulej@packetizer.com; > > gv@trace.wisc.edu; Len Bytheway; Barry Dingle > > Subject: Re: Betr.: [Sipping] ToIP Requirements > > > > > > Brian, > > > > In Australia, we have a separate emergency number for > > Textphone users. It is > > '106' and is regulated by legislation. > > > > We have a separate '106' emergency call centre. This makes > > special support > > for a range of text services much easier. (See > > http://www.aceinfo.net.au/Services/NRS/Services/ers.html). I > > understand > > that this may be difficult to implement for historical=20 > reasons in some > > countries - but it is possible and works well. > > > > As an aside, we are seriously investigating a 'Text Server' > > to support a > > whole range of text interworking scenarios - and ToIP is=20 > planned to be > > supported in Stage 2. I believe that we will eventually move > > to a single > > emergency number - but not until we can easily and reliably > > identify text > > emergency calls. > > > > Cheers, > > > > Barry DINGLE > > Telecommunications Consultant > > Project Manager - ACIF Any-to-Any Text Connectivity Options WG > > Fellow of the University of Melbourne > > barry.dingle@bigfoot.com.au > > Mob: +61 (0)41 911 7578 > > Fixed: +61 (0)3 9725 3937 > > ----- Original Message ----- > > From: "Rosen, Brian" > > To: "'Arnoud van Wijk'" ; "'Gunnar Hellstrom'" > > ; ; > > > > Cc: ; ; > > ; ; > > > > Sent: Friday, February 27, 2004 1:36 AM > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > Arnoud > > > > > > I do not believe this can work. A TDD user dials 112 or > > 911. Today, this > > > will be routed directly to a "selective router" (a TDM > > switch) which sends > > > the > > > call to the correct Emergency Response Center. You can't insert = a > > gateway, > > > because you don't know that it's a TDD call until it is > > answered. To make > > > it work, you would have to establish a special PSTN number > > for emergency > > > TDD, > > > which would route to the gateway, which would then call the > > ERC. I don't > > > believe that is practical. > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > > > Sent: Thursday, February 26, 2004 9:17 AM > > > > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > > > > Gonzalo.Camarillo@ericsson.com; > > > > sipping@ietf.org > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > henry.sinnreich@mci.com; > > > > paulej@packetizer.com; gv@trace.wisc.edu > > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > > > Hello Brian, > > > > That is also why we need to look at the emergency call system. > > > > This text gateway is only at the PSTN side, thus another > > > > requirement for a > > > > T140/RTP gateway for the PSTN is that when a local > > emergency number is > > > > dialled (112, or 911 etc). That the gateway must be able to > > > > receive that > > > > call (even dropping existing calls if necessary). Such a call > > > > is easy to > > > > recognize as an emergency call. (PSTN side). > > > > From that gateway on, it is all IP with RFC2793 interactive > > > > text. And then > > > > it is just all existing SIP as if it was from an IP end-point. > > > > > > > > This gives emergency centers an advantage, all calls will be > > > > T.140/RTP, so > > > > integration in their computer systems will be easy instead > > > > being forced to > > > > have analog textphones available for a textphone call. (or a > > > > separate text > > > > telephone emergency center). > > > > > > > > /Arnoud > > > > > > > > Drs. Arnoud A. T. van Wijk > > > > Viataal > > > > Research & Development > > > > Afdeling RDS > > > > Theerestraat 42 > > > > 5271 GD Sint-Michielsgestel > > > > The Netherlands. > > > > Mobile: +31651921948 > > > > International text telephone: +31735588408 > > > > > > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: donderdag 26 februari 2004 15:04 > > > > To: 'Arnoud van Wijk'; 'Gunnar Hellstrom'; > > > > Gonzalo.Camarillo@ericsson.com; > > > > sipping@ietf.org > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > henry.sinnreich@mci.com; > > > > paulej@packetizer.com; gv@trace.wisc.edu > > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > Arnoud > > > > > > > > Generally, you don't want to rely on very many SIP elements > > > > to complete > > > > an emergency call. Present systems accept TDD at all answering > > > > points because they don't know before the calls is > > answered that it > > > > is a TDD call. I certainly don't want the user to have > > to do anything > > > > other than dial his local emergency number, or complete a = device > > > > specific key sequence to complete an emergency call, and I = don't > > > > want a gateway busy to prevent an emergency call. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > > > > Sent: Thursday, February 26, 2004 6:07 AM > > > > > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > > > > > Gonzalo.Camarillo@ericsson.com; > > > > > sipping@ietf.org > > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > > henry.sinnreich@mci.com; > > > > > paulej@packetizer.com; gv@trace.wisc.edu > > > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > > > > > > Actually, > > > > > When using the text gateway, there is no need to detect the > > > > > TDD/Analogue > > > > > text telephone tones/signals. That is the job of the > > text gateway. > > > > > > > > > > And for the emergency calling. We have to look closely > > at this in > > > > > combination with a text gateway. Possible behaviour/action. > > > > > And possible > > > > > action in SIP. > > > > > > > > > > Right now I cannot say what has to happen, I must study the > > > > > emergency calls > > > > > in depth. But as I see it, using the text gateway, all SIP > > > > > originating and > > > > > receiving emergency calls will be possible for any > > textphone user. > > > > > > > > > > Cheers > > > > > > > > > > Arnoud > > > > > > > > > > > > > > > Drs. Arnoud A. T. van Wijk > > > > > Viataal > > > > > Research & Development > > > > > Afdeling RDS > > > > > Theerestraat 42 > > > > > 5271 GD Sint-Michielsgestel > > > > > The Netherlands. > > > > > Mobile: +31651921948 > > > > > International text telephone: +31735588408 > > > > > > > > > > -----Original Message----- > > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > > > On Behalf Of > > > > > Rosen, Brian > > > > > Sent: woensdag 25 februari 2004 23:08 > > > > > To: 'Gunnar Hellstrom'; A vWijk;=20 > Gonzalo.Camarillo@ericsson.com; > > > > > sipping@ietf.org > > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > > henry.sinnreich@mci.com; > > > > > paulej@packetizer.com; gv@trace.wisc.edu > > > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > I'm particularly interested in the last one,=20 > emergency calling. > > > > > > > > > > Given that you propose an appropriate SDP indicating > > > > support for text, > > > > > do you think there is anything else we need to do to in SIP > > > > > to make this > > > > > happen? I don't see anything. > > > > > > > > > > I know that the problem of using a legacy TDD device on > > any kind of > > > > > adapter is as problematic as current TDD; the call=20 > will answered > > > > > as if it was a voice call, the baudot/whatever tones will be > > > > > detected, > > > > > and the operator will look for text. > > > > > Can't think of any way to make that better. > > > > > > > > > > Do note that language preference headers should be set!!! > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > > > Sent: Wednesday, February 25, 2004 4:54 PM > > > > > > To: A vWijk; Gonzalo.Camarillo@ericsson.com;=20 > sipping@ietf.org > > > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > > > henry.sinnreich@mci.com; > > > > > > paulej@packetizer.com; gv@trace.wisc.edu > > > > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > > > > > > > > > I think PSTN textphone gateway invocation is one area where > > > > > > we either need > > > > > > protocol extensions, or need agreements on what current > > > > > > mechanisms to use. > > > > > > > > > > > > Another is invocation of various kinds of relay services or > > > > > > translation > > > > > > services. > > > > > > > > > > > > A third is calling emergency services and reach positions > > > > capable of > > > > > > handling the type of communication that the user prefers. > > > > > > > > > > > > > > > > > > > > > > > > Gunnar > > > > > > ------------------------------------------- > > > > > > Gunnar Hellstrom > > > > > > Omnitor AB > > > > > > Renathvagen 2 > > > > > > SE 121 37 Johanneshov > > > > > > SWEDEN > > > > > > +46 8 556 002 03 > > > > > > Mob: +46 708 204 288 > > > > > > www.omnitor.se > > > > > > Gunnar.Hellstrom@Omnitor.se > > > > > > -------------------------------------------- > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: sipping-admin@ietf.org > > > > > > [mailto:sipping-admin@ietf.org]On Behalf Of > > > > > > A vWijk > > > > > > Sent: Tuesday, February 24, 2004 1:22 PM > > > > > > To: Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > > > henry.sinnreich@mci.com; > > > > > > gunnar.hellstrom@omnitor.se; paulej@packetizer.com; > > > > > gv@trace.wisc.edu > > > > > > Subject: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > > > > > > > > > Hello Gonzalo, > > > > > > While there are device requirements in the text. Those > > > > > > requirements and the > > > > > > explanation on the different analogue text telephone = systems > > > > > > is included to > > > > > > give the reader an understanding what kind of devices will > > > > > > connect with > > > > > > ToIP. And the need for the text gateways. And what the > > > > > > different behaviour > > > > > > can/may be compared to end to end IP devices. > > > > > > The most important part will be the ToIP framwork and the > > > > > > text gateways and > > > > > > how such gateways will be used and work with the ToIP > > framework. > > > > > > > > > > > > There is a ToIP framework where a terminal uses streaming > > > > > > text as defined in > > > > > > RFC2793 to connect with any other Interactive > > > > > > texting/real-time streaming > > > > > > text device. > > > > > > This can be end-to-end IP, and a direct T140/RTP stream is > > > > > > established with > > > > > > SIP. But in other cases, a text gateway must be=20 > used to allow > > > > > > T.140/RTP to > > > > > > connect with a non IP text telephony device. > > > > > > It can be an analogue text telephone (TDD/TTY) that uses a > > > > > > text gateway to > > > > > > be able to understand RFC2793 text. (PSTN-IP) > > > > > > It can be a mobile phone running GPRS that uses the text > > > > gateway to > > > > > > understand RFC2793 text. (this exist right NOW=20 > using SIP! And > > > > > > those gateways > > > > > > will be used in mobile networks this year!) > > > > > > Or a mobile text telephone using CTM via the text gateway = to > > > > > > communicate > > > > > > with RFC2793 text. > > > > > > Or even one analogue text telephone connecting to another > > > > > > analogue text > > > > > > telephone in a different country, and the PSTN's use IP to > > > > > > connect the call. > > > > > > > > > > > > The question is for example, how do we use that gateway = from > > > > > > the IP side? Is > > > > > > it invisible for the IP side? Or do we need special > > > > > > extensions in SIP to > > > > > > that the IP terminal knows it is communicating with the > > > > > > end-device through > > > > > > the text gateway? > > > > > > There may be a slightly different call setup flow=20 > when a text > > > > > > gateway is > > > > > > included. > > > > > > Or additional SIP messages indicating gateway activity. = When > > > > > > you connect for > > > > > > example to an analogue text telephone with an=20 > RFC2793 capable > > > > > > IP terminal > > > > > > the capabilities will be less then IP to IP=20 > terminal directly > > > > > > (different > > > > > > transmission speeds, half/full duplex etc). > > > > > > Or what to do with emergency calls that are in RFC > > 2793 text only? > > > > > > > > > > > > That are requirements that will be defined and worked out = in > > > > > > this draft. > > > > > > Also, we want to make everybody in SIP and SIPPING aware > > > > > > about those text > > > > > > gateways. So that complicated matters like how to send > > > > analogue text > > > > > > telephone text through a PSTN and connect with a SIP > > > > > > telephone using RFC2793 > > > > > > interactive texting. When using the text gateway, there is > > > > > > then no need for > > > > > > RFC 2833 events at the PSTN for text telephones. > > > > > > > > > > > > So, yes. I believe that this should be in the=20 > SIPPING WG. And > > > > > > it will fit in > > > > > > the charter - support for hearing-/speech-impaired calling. > > > > > > > > > > > > greetz > > > > > > > > > > > > Arnoud > > > > > > > > > > > > > > > > > > > > > > > > Drs. Arnoud A. T. van Wijk > > > > > > Viataal > > > > > > Research & Development > > > > > > Afdeling RDS > > > > > > Theerestraat 42 > > > > > > 5271 GD Sint-Michielsgestel > > > > > > The Netherlands. > > > > > > Mobile: +31651921948 > > > > > > International text telephone: +31735588408 > > > > > > > > > > > > >>> Gonzalo Camarillo > > > > > > 24-02-04 10:21 >>> > > > > > > Hello, > > > > > > > > > > > > the draft below provides a set of requirements for = real-time > > > > > > conversations using SIP. > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-to > > > > > ip-01.txt > > > > > > > > > > Nevertheless, I have found a lot of device requirements in > > > > > the text, but > > > > > I fail to understand which particular protocol requirements > > > > we need to > > > > > fulfill with new protocol extensions. > > > > > > > > > > While SIPPING is the right place to handle requirements > > > > that will lead > > > > > to new SIP protocol extensions, SIPPING may not be the > > > > right place to > > > > > deal with device requirements (e.g., text phones MUST have a > > > > > display of > > > > > at least 100 characters). > > > > > > > > > > Thanks, > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > This communication is confidential and intended solely for > > > > > the addressee(s). > > > > > Any unauthorized review, use, disclosure or distribution is > > > > > prohibited. If > > > > > you believe this message has been sent to you in error, > > > > > please notify the > > > > > sender by replying to this transmission and delete the > > > > message without > > > > > disclosing it. Thank you. > > > > > > > > > > E-mail including attachments is susceptible to data=20 > corruption, > > > > > interruption, unauthorized amendment, tampering and viruses, > > > > > and we only > > > > > send and receive e-mails on the basis that we are not liable > > > > > for any such > > > > > corruption, interception, amendment, tampering or=20 > viruses or any > > > > > consequences thereof. > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > This list is for NEW development of the application of SIP > > > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > This list is for NEW development of the application of SIP > > > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > This list is for NEW development of the application of SIP > > > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > This list is for NEW development of the application of SIP > > > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 >=20 >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Feb 29 23:53:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02136 for ; Sun, 29 Feb 2004 23:53:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfPx-0001LB-1z for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 23:52:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i214qb16005147 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 23:52:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfPw-0001Kw-Tx for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 23:52:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02133 for ; Sun, 29 Feb 2004 23:52:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfPu-0006Qm-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:52:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfOx-0006KZ-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:51:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxfOS-0006EW-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 23:51:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfOQ-00018f-WB; Sun, 29 Feb 2004 23:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfO0-00017t-JH for sipping@optimus.ietf.org; Sun, 29 Feb 2004 23:50:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02063 for ; Sun, 29 Feb 2004 23:50:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfNy-0006De-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:50:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfN2-00067Y-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:49:37 -0500 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 1AxfMV-00061d-00 for sipping@ietf.org; Sun, 29 Feb 2004 23:49:03 -0500 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id FAA18177 for ; Mon, 1 Mar 2004 05:51:51 +0100 (CET) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma017996; Mon, 1 Mar 04 05:50:40 +0100 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Mon, 01 Mar 2004 05:47:43 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Mon, 01 Mar 2004 05:47:16 +0100 From: "A vWijk" To: , , , , Cc: , , , , Subject: Betr.: RE: Betr.: [Sipping] ToIP Requirements Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable And that is why those 2 solutions would be best IMHO: 1. using a prefix number when using a textphone. This prefix is for every textphone call you place! Thus not emergency only = but any call made by the textphone. 600-911, 600-555-123456, 600-800-cheapshoe. 2. Label the phone number you use for the textphone as text telephone = user. In both cases the PSTN will immediately invoke the text gateway. Which = then sends the V.18 reception/boudot reception signalling. I know that it is not perfect, but the analogue textphones will disappear = quickly. 2-3 years for most users and up to 10-15 years for the last few = users. I and many deaf people I know will throw the analogue textphone out of the = window as soon as possible. We will use mobile textphones via the textgateway and SIP phones with = RFC2793 (and our pcs with an interactive text client). greetz Arnoud <<< "Gunnar Hellstrom" 01-03 03:27 >>> 1. How it is in PSTN: A calling V.18 sends a specific data pattern for text telephony in the V.8 signal CI. It is sent in the connected voice channel. So, as with all calls from PSTN, there is no indication before the call is set up about what kind of media will be used. But it is far more easy to identify it as a textphone call than it is for some of the old systems. E.G the US system "Baudot" is silent when = calling, and the answering side must guess that it is a textphone. There is not yet any really clear trend to move to V.18 for users in USA. Therefore I agree that the mechanisms for emergency calls must for a long time accomplish for the tedious task to try to respond in text on PSTN to all incoming silent calls to discriminate the text callers. That response should be done with V.18 signals, so that it at least is prepared for more convenient handling when people have moved to using V.18 textphones. 2. In SIP. In SIP, we have text in a separate media stream in the call. An emergency centre should have capability to use both voice and text simultaneously. There are mechanisms in discussion about indicating preference for = handling the call with text as the main medium. I am not sure that we can require that preference to be set in a SIP terminal used for an emergency call by = a text depending person. So, the safe handling would be for the emergency centre to offer text capability, and if text connection is achieved, an automatic text greeting is sent in that channel, while the emergency agent responds in voice. If = the caller then starts using the text channel, it is evident enough that text = is preferred. Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Rosen, Brian Sent: Monday, March 01, 2004 1:16 AM To: Barry Dingle; 'Arnoud van Wijk'; 'Gunnar Hellstrom'; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org Cc: rrroy@att.com; henry.sinnreich@mci.com; paulej@packetizer.com; gv@trace.wisc.edu; Len Bytheway Subject: RE: Betr.: [Sipping] ToIP Requirements While we can, and have, specified a single worldwide URI for emergency calls, I believe it is not even technically possible to find a single 3 digit number that is not already in use somewhere. Thus, I suspect anyone dreaming that such a thing will happen probably is going to be disappointed. Since existing TDD devices do not provide an indication that they are present until after the call is completed, I think that we should not even consider use of any kind of gateway for emergency calls. This is true of V.18 devices also, correct? Having a special number for text emergency calls does have _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP