From exim@www1.ietf.org Tue May 4 14:47:41 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20176 for ; Tue, 4 May 2004 14:47:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4pE-0002cK-A0 for sipping-archive@odin.ietf.org; Tue, 04 May 2004 14:39:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44IdSca010052 for sipping-archive@odin.ietf.org; Tue, 4 May 2004 14:39:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4jI-0000Wm-PB for sipping-web-archive@optimus.ietf.org; Tue, 04 May 2004 14:33:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18814 for ; Tue, 4 May 2004 14:33:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL4jG-0005NQ-6V for sipping-web-archive@ietf.org; Tue, 04 May 2004 14:33:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4iF-0005Dz-00 for sipping-web-archive@ietf.org; Tue, 04 May 2004 14:32:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL4hd-00054Y-00 for sipping-web-archive@ietf.org; Tue, 04 May 2004 14:31:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4cE-0006jX-V8; Tue, 04 May 2004 14:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4SO-0003za-TZ for sipping@optimus.ietf.org; Tue, 04 May 2004 14:15:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17200 for ; Tue, 4 May 2004 14:15:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL4SM-0003FU-EN for sipping@ietf.org; Tue, 04 May 2004 14:15:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4RT-00038l-00 for sipping@ietf.org; Tue, 04 May 2004 14:14:55 -0400 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 1BL4QZ-000327-00 for sipping@ietf.org; Tue, 04 May 2004 14:13:59 -0400 Received: from softarmor.com (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i44IDxu3013043; Tue, 4 May 2004 13:14:00 -0500 Message-ID: <4097DD67.3060104@softarmor.com> Date: Tue, 04 May 2004 13:13:59 -0500 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: Gonzalo Camarillo , Rohan Mahy , Allison Mankin Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Poll: Consensus on adoption of the URI-list work Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 See: draft-camarillo-sipping-uri-list-02.txt It seems that the URI-list stuff is becoming important for its use in ad-hoc list requests. I've heard of several other groups that are referring to it in their specifications, and wish for us to conclude on the specification ASAP. The current draft is fairly mature, and we seem to have a constituency for the specification. Consequently, I'd like to suggest that the SIPPING group consider adopting this draft as a working group effort, targeted for informational RFC, with an estimated delivery date to IESG of June, 2004. Please respond, aye or nay, if you care. The chairs will, as usual, judge consensus and report the recommendation (for or against) to the AD for consideration. Thanks, -- Dean Willis SIPPING co-chair _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 4 14:51:57 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20517 for ; Tue, 4 May 2004 14:51:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4tt-0003hy-Cg for sipping-archive@odin.ietf.org; Tue, 04 May 2004 14:44:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44IiHkU014250 for sipping-archive@odin.ietf.org; Tue, 4 May 2004 14:44:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4oe-00027P-LP for sipping-web-archive@optimus.ietf.org; Tue, 04 May 2004 14:38:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19375 for ; Tue, 4 May 2004 14:38:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL4ob-000682-W7 for sipping-web-archive@ietf.org; Tue, 04 May 2004 14:38:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4nl-00061y-00 for sipping-web-archive@ietf.org; Tue, 04 May 2004 14:37:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL4n3-0005vj-00 for sipping-web-archive@ietf.org; Tue, 04 May 2004 14:37:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4dH-0006wt-5h; Tue, 04 May 2004 14:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4a9-000613-15 for sipping@optimus.ietf.org; Tue, 04 May 2004 14:23:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17781 for ; Tue, 4 May 2004 14:23:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL4a6-00047M-G0 for sipping@ietf.org; Tue, 04 May 2004 14:23:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4ZD-00040a-00 for sipping@ietf.org; Tue, 04 May 2004 14:22:56 -0400 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 1BL4YN-0003sq-00; Tue, 04 May 2004 14:22:03 -0400 Received: from softarmor.com (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i44INTu3013105; Tue, 4 May 2004 13:23:29 -0500 Message-ID: <4097DFA1.2010609@softarmor.com> Date: Tue, 04 May 2004 13:23:29 -0500 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, simple@ietf.org CC: Robert Sparks , Hisham Khartabil , Gonzalo Camarillo , Allison Mankin , Ted Hardie Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Poll: Adopt message exploder draft from SIMPLE? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 SIMPLE working group has been discussing mechanisms for sending a MESSAGE request to multiple recipients. It has been suggested that this work might be more-at-home in the SIPPING group, as we'll also be discussing "exploder" methods for otehr request types. The current draft is: draft-garcia-simple-message-exploder-00.txt I expect to see this work, when completed, referenced by the usual set of external bodies that reference our work. So, I'd like to ask the SIPPING working group: How do you feel about this? Anybody radically opposed to moving this from SIMPLE to SIPPING and adopting the work? Anybody radically in favor? Thanks, -- Dean Willis SIPPING WG co-chair _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 5 02:56:35 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25278 for ; Wed, 5 May 2004 02:56:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGJL-0001ZR-6l for sipping-archive@odin.ietf.org; Wed, 05 May 2004 02:55:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i456tIC7006031 for sipping-archive@odin.ietf.org; Wed, 5 May 2004 02:55:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLG74-0006hX-8f for sipping-web-archive@optimus.ietf.org; Wed, 05 May 2004 02:42:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24599 for ; Wed, 5 May 2004 02:42:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLG70-0002Xx-Ll for sipping-web-archive@ietf.org; Wed, 05 May 2004 02:42:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLG5t-0002Kc-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 02:41:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLG5A-0002AO-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 02:40:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLFxp-0003YX-Ey; Wed, 05 May 2004 02:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLFw8-00031u-Pi for sipping@optimus.ietf.org; Wed, 05 May 2004 02:31:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23822 for ; Wed, 5 May 2004 02:31:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLFw4-0000j1-VN for sipping@ietf.org; Wed, 05 May 2004 02:31:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLFv7-0000Zo-00 for sipping@ietf.org; Wed, 05 May 2004 02:30:17 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BLFuT-0000Hr-00; Wed, 05 May 2004 02:29:37 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i456TUk28229; Wed, 5 May 2004 09:29:30 +0300 (EET DST) X-Scanned: Wed, 5 May 2004 09:29:04 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i456T4IQ011882; Wed, 5 May 2004 09:29:04 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00aelpgG; Wed, 05 May 2004 09:29:03 EEST 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 i456T2H16439; Wed, 5 May 2004 09:29:02 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 5 May 2004 09:29:00 +0300 Message-ID: <409889AC.5000005@nokia.com> Date: Wed, 05 May 2004 09:29:00 +0300 From: Miguel Garcia 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, es-es MIME-Version: 1.0 To: Dean Willis CC: sipping@ietf.org, simple@ietf.org, Robert Sparks , Hisham Khartabil , Gonzalo Camarillo , Allison Mankin , Ted Hardie References: <4097DFA1.2010609@softarmor.com> In-Reply-To: <4097DFA1.2010609@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2004 06:29:00.0335 (UTC) FILETIME=[40813BF0:01C4326A] Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Simple] Poll: Adopt message exploder draft from SIMPLE? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 Dean: As an author of the MESSAGE exploder document, I agree with you that the document perhaps fits better in the SIPPING WG. I was about to publish a new version that included comments we got in the mailing list. I will wait until we reach consensus of which is the appropriate WG. - Miguel Dean Willis wrote: > > The SIMPLE working group has been discussing mechanisms for sending a > MESSAGE request to multiple recipients. It has been suggested that this > work might be more-at-home in the SIPPING group, as we'll also be > discussing "exploder" methods for otehr request types. > > The current draft is: > > draft-garcia-simple-message-exploder-00.txt > > I expect to see this work, when completed, referenced by the usual set > of external bodies that reference our work. > > So, I'd like to ask the SIPPING working group: How do you feel about > this? Anybody radically opposed to moving this from SIMPLE to SIPPING > and adopting the work? Anybody radically in favor? > > Thanks, > > -- > Dean Willis > SIPPING WG co-chair > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia tel:+358-50-4804586 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 Wed May 5 03:02:49 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25676 for ; Wed, 5 May 2004 03:02:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGOw-0003bU-17 for sipping-archive@odin.ietf.org; Wed, 05 May 2004 03:01:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45715wU013852 for sipping-archive@odin.ietf.org; Wed, 5 May 2004 03:01:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGKm-0002BZ-02 for sipping-web-archive@optimus.ietf.org; Wed, 05 May 2004 02:56:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25318 for ; Wed, 5 May 2004 02:56:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLGKi-000567-9f for sipping-web-archive@ietf.org; Wed, 05 May 2004 02:56:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLGJb-0004t3-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 02:55:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLGIn-0004hh-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 02:54:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLG6a-0006ef-Q7; Wed, 05 May 2004 02:42:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLG0x-0004LZ-1o for sipping@optimus.ietf.org; Wed, 05 May 2004 02:36:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24229 for ; Wed, 5 May 2004 02:36:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLG0t-0001Uv-7h for sipping@ietf.org; Wed, 05 May 2004 02:36:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLFzu-0001LS-00 for sipping@ietf.org; Wed, 05 May 2004 02:35:15 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BLFzQ-0001Ci-00 for sipping@ietf.org; Wed, 05 May 2004 02:34:44 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i456WrB22095; Wed, 5 May 2004 09:32:53 +0300 (EET DST) X-Scanned: Wed, 5 May 2004 09:32:35 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i456WZKf019940; Wed, 5 May 2004 09:32:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00jxVSK8; Wed, 05 May 2004 09:32:34 EEST 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 i456WXH19130; Wed, 5 May 2004 09:32:33 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 5 May 2004 09:32:30 +0300 Message-ID: <40988A7E.3070704@nokia.com> Date: Wed, 05 May 2004 09:32:30 +0300 From: Miguel Garcia 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, es-es MIME-Version: 1.0 To: ext Dean Willis CC: sipping@ietf.org, Gonzalo Camarillo , Rohan Mahy , Allison Mankin Subject: Re: [Sipping] Poll: Consensus on adoption of the URI-list work References: <4097DD67.3060104@softarmor.com> In-Reply-To: <4097DD67.3060104@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2004 06:32:30.0252 (UTC) FILETIME=[BDA006C0:01C4326A] 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 Dean: I agree and support on adopting this document as WG item. But I don't agree with the track publication. You proposed to publish it as informational RFC, which I believe is not right. It should be standards track, since the document contains a bunch of normative statements and is actually a protocol specification. - Miguel ext Dean Willis wrote: > > See: draft-camarillo-sipping-uri-list-02.txt > > It seems that the URI-list stuff is becoming important for its use in > ad-hoc list requests. I've heard of several other groups that are > referring to it in their specifications, and wish for us to conclude on > the specification ASAP. > > The current draft is fairly mature, and we seem to have a constituency > for the specification. > > Consequently, I'd like to suggest that the SIPPING group consider > adopting this draft as a working group effort, targeted for > informational RFC, with an estimated delivery date to IESG of June, 2004. > > Please respond, aye or nay, if you care. The chairs will, as usual, > judge consensus and report the recommendation (for or against) to the AD > for consideration. > > Thanks, > > -- > Dean Willis > SIPPING co-chair > > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Miguel A. Garcia tel:+358-50-4804586 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 Wed May 5 03:27:11 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26791 for ; Wed, 5 May 2004 03:27:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGlq-0001oP-CR for sipping-archive@odin.ietf.org; Wed, 05 May 2004 03:24:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i457OkcH006957 for sipping-archive@odin.ietf.org; Wed, 5 May 2004 03:24:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGdo-0007ku-Q9 for sipping-web-archive@optimus.ietf.org; Wed, 05 May 2004 03:16:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26164 for ; Wed, 5 May 2004 03:16:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLGdm-0000t2-KB for sipping-web-archive@ietf.org; Wed, 05 May 2004 03:16:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLGcd-0000Y2-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 03:15:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLGbG-0000Ci-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 03:13:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGXa-000679-BH; Wed, 05 May 2004 03:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGU3-00051Q-8h for sipping@optimus.ietf.org; Wed, 05 May 2004 03:06:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25754 for ; Wed, 5 May 2004 03:06:20 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLGTz-0006or-7f for sipping@ietf.org; Wed, 05 May 2004 03:06:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLGT0-0006f4-00 for sipping@ietf.org; Wed, 05 May 2004 03:05:19 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BLGSO-0006Ve-00 for sipping@ietf.org; Wed, 05 May 2004 03:04:40 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4574Vv19319; Wed, 5 May 2004 10:04:31 +0300 (EET DST) X-Scanned: Wed, 5 May 2004 10:04:09 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i45749MM023927; Wed, 5 May 2004 10:04:09 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 006p9Wkl; Wed, 05 May 2004 10:04:07 EEST 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 i45741H12976; Wed, 5 May 2004 10:04:01 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 5 May 2004 10:04:00 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 5 May 2004 10:03:59 +0300 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: Wed, 5 May 2004 10:03:59 +0300 Message-ID: Thread-Topic: [Simple] Poll: Adopt message exploder draft from SIMPLE? Thread-Index: AcQyBrs6G4dno9CRS6mLu8mb1Zz76AAYjoPQ To: , Cc: , , , , X-OriginalArrivalTime: 05 May 2004 07:03:59.0836 (UTC) FILETIME=[23E7A9C0:01C4326F] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: [Simple] Poll: Adopt message exploder draft from SIMPLE? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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'm definitely in favor of doing the exploders work. INVITE & REFER are = needed for efficient (ad hoc) conferencing, and MESSAGE is a must for = building any decent IM system with SIP. As the goal should be to solve = the problem for all methods in a uniform manner, I think it makes sense = to have also MESSAGE done in SIPPING, but I have no strong preference on = this. For external bodies I think both OMA and 3GPP have such requirements = (for push-to-talk conference setup and for multi-party IM) that = exploders would be adopted by them if they were available. But the more = important point is that these are necessary extensions of SIP, which = probably should have been done even earlier, given that there are = already several proprietary implementations of this kind of mechanisms. Markus =20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Dean Willis > Sent: 04 May, 2004 21:23 > To: sipping@ietf.org; simple@ietf.org > Cc: Robert Sparks; Khartabil Hisham (Nokia-TP-MSW/Helsinki); Gonzalo > Camarillo; Allison Mankin; Ted Hardie > Subject: [Simple] Poll: Adopt message exploder draft from SIMPLE? >=20 >=20 >=20 > The SIMPLE working group has been discussing mechanisms for sending a=20 > MESSAGE request to multiple recipients. It has been suggested=20 > that this=20 > work might be more-at-home in the SIPPING group, as we'll also be=20 > discussing "exploder" methods for otehr request types. >=20 > The current draft is: >=20 > draft-garcia-simple-message-exploder-00.txt >=20 > I expect to see this work, when completed, referenced by the=20 > usual set=20 > of external bodies that reference our work. >=20 > So, I'd like to ask the SIPPING working group: How do you feel about=20 > this? Anybody radically opposed to moving this from SIMPLE to SIPPING=20 > and adopting the work? Anybody radically in favor? >=20 > Thanks, >=20 > -- > Dean Willis > SIPPING WG co-chair >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=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 May 5 03:28:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26901 for ; Wed, 5 May 2004 03:28:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGna-0002HT-Pt for sipping-archive@odin.ietf.org; Wed, 05 May 2004 03:26:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i457QYaG008760 for sipping-archive@odin.ietf.org; Wed, 5 May 2004 03:26:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGjW-00011M-PK for sipping-web-archive@optimus.ietf.org; Wed, 05 May 2004 03:22:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26397 for ; Wed, 5 May 2004 03:22:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLGjU-00021F-Mi for sipping-web-archive@ietf.org; Wed, 05 May 2004 03:22:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLGiT-0001mX-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 03:21:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLGhT-0001at-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 03:20:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGcR-0007Vp-EB; Wed, 05 May 2004 03:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGYo-0006Pp-D6 for sipping@optimus.ietf.org; Wed, 05 May 2004 03:11:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25853 for ; Wed, 5 May 2004 03:11:15 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLGYk-0007a1-Bf for sipping@ietf.org; Wed, 05 May 2004 03:11:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLGXl-0007Q4-00 for sipping@ietf.org; Wed, 05 May 2004 03:10:13 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BLGWo-0007Gm-00 for sipping@ietf.org; Wed, 05 May 2004 03:09:14 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i45794B06896; Wed, 5 May 2004 10:09:04 +0300 (EET DST) X-Scanned: Wed, 5 May 2004 10:08:22 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4578MSp003996; Wed, 5 May 2004 10:08:22 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00DYRFLr; Wed, 05 May 2004 10:08:21 EEST 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 i4578KH16876; Wed, 5 May 2004 10:08:20 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 5 May 2004 10:08:18 +0300 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] Poll: Consensus on adoption of the URI-list work Date: Wed, 5 May 2004 10:08:18 +0300 Message-ID: Thread-Topic: [Sipping] Poll: Consensus on adoption of the URI-list work Thread-Index: AcQyBg1HBMyXG0avSU2blmadC9+laAAZs81Q To: , Cc: , , X-OriginalArrivalTime: 05 May 2004 07:08:18.0336 (UTC) FILETIME=[BDFBA200:01C4326F] 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, Yes, I support adopting this, and I also agree that the draft seems to = be quite stable already. Proposed Standard makes more sense than = Informational, I think. Markus > -----Original Message----- > From: sipping-admin@ietf.org=20 > [mailto:sipping-admin@ietf.org]On Behalf Of > ext Dean Willis > Sent: 04 May, 2004 21:14 > To: sipping@ietf.org > Cc: Gonzalo Camarillo; Rohan Mahy; Allison Mankin > Subject: [Sipping] Poll: Consensus on adoption of the URI-list work >=20 >=20 >=20 > See: draft-camarillo-sipping-uri-list-02.txt >=20 > It seems that the URI-list stuff is becoming important for its use in=20 > ad-hoc list requests. I've heard of several other groups that are=20 > referring to it in their specifications, and wish for us to=20 > conclude on=20 > the specification ASAP. >=20 > The current draft is fairly mature, and we seem to have a=20 > constituency=20 > for the specification. >=20 > Consequently, I'd like to suggest that the SIPPING group consider=20 > adopting this draft as a working group effort, targeted for=20 > informational RFC, with an estimated delivery date to IESG of=20 > June, 2004. >=20 > Please respond, aye or nay, if you care. The chairs will, as usual,=20 > judge consensus and report the recommendation (for or=20 > against) to the AD=20 > for consideration. >=20 > Thanks, >=20 > -- > Dean Willis > SIPPING co-chair >=20 >=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 >=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 May 5 03:58:08 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28211 for ; Wed, 5 May 2004 03:58:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLHB6-0001km-6G for sipping-archive@odin.ietf.org; Wed, 05 May 2004 03:50:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i457oqKQ006736 for sipping-archive@odin.ietf.org; Wed, 5 May 2004 03:50:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLH7p-0000y0-CI for sipping-web-archive@optimus.ietf.org; Wed, 05 May 2004 03:47:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27648 for ; Wed, 5 May 2004 03:47:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLH7n-0006k0-23 for sipping-web-archive@ietf.org; Wed, 05 May 2004 03:47:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLH6v-0006Z1-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 03:46:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLH6A-0006NY-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 03:45:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGyj-0006j2-GC; Wed, 05 May 2004 03:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGw5-0005zV-5m for sipping@optimus.ietf.org; Wed, 05 May 2004 03:35:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27213 for ; Wed, 5 May 2004 03:35:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLGw2-0004Yf-Qm for sipping@ietf.org; Wed, 05 May 2004 03:35:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLGv8-0004NY-00 for sipping@ietf.org; Wed, 05 May 2004 03:34:22 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly05b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BLGuE-00041S-00 for sipping@ietf.org; Wed, 05 May 2004 03:33:26 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly05b.srv.mailcontrol.com (MailControl) with SMTP id i457WFSc018033; Wed, 5 May 2004 08:32:16 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Wed, 5 May 2004 08:32:21 +0100 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] Re: WGLC for draft-ietf-sipping-transc-3pcc-00 Date: Wed, 5 May 2004 08:32:14 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF3B7@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sipping] Re: WGLC for draft-ietf-sipping-transc-3pcc-00 Thread-Index: AcQumXzc3WccHI92R5e1+43JztKEQQD2Yn/g From: "Chris Boulton" To: "Dean Willis" , "Paul Kyzivat" Cc: "Gonzalo Camarillo" , , "Rohan Mahy" , "Allison Mankin" 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 Yes from me for supporting ;-) >-----Original Message----- >From: Dean Willis [mailto:dean.willis@softarmor.com] >Sent: 30 April 2004 10:45 >To: Paul Kyzivat >Cc: Gonzalo Camarillo; sipping@ietf.org; Rohan Mahy; Allison Mankin >Subject: Re: [Sipping] Re: WGLC for draft-ietf-sipping-transc-3pcc-00 > >Paul Kyzivat wrote: > >Gonzalo quoted: >>> " It is recommended that an offerer does not invoke transcoding >>> services before making sure that the answerer does not support the >>> capabilities needed for the session. Making wrong assumptions about >>> the answerer's capabilities can lead to situations where two >>> transcoders are introduced (one by the offerer and one by the >>> answerer) in a session that would not need any transcoding services >>> at all." >... > >Paul pondered: >> I suppose you could view this as a problem for the human operator of the >> device - to select an appropriate phone feature based on known >> capabilities of the callee. But that is pretty much a cop out. And it >> doesn't work when the decision has to be made by the callee, as when >> the initial invite has no offer, unless you expect the callee to select >> different answer modes depending on who is calling. > >Would something like a priority-ordered preference/capability set in >caller-preferences/callee caps be a big aid here? > >-- >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 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 Wed May 5 04:33:40 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29939 for ; Wed, 5 May 2004 04:33:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLHjC-0003Aw-Ut for sipping-archive@odin.ietf.org; Wed, 05 May 2004 04:26:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i458Q62Q012207 for sipping-archive@odin.ietf.org; Wed, 5 May 2004 04:26:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLHWr-0008IC-C4 for sipping-web-archive@optimus.ietf.org; Wed, 05 May 2004 04:13:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29032 for ; Wed, 5 May 2004 04:13:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLHWo-00047A-Mo for sipping-web-archive@ietf.org; Wed, 05 May 2004 04:13:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLHVv-0003wB-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 04:12:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLHVI-0003lh-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 04:11:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLHKG-0004Br-Nc; Wed, 05 May 2004 04:00:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLHHK-0003EQ-UK for sipping@optimus.ietf.org; Wed, 05 May 2004 03:57:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28193 for ; Wed, 5 May 2004 03:57:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLHHI-0000yb-8u for sipping@ietf.org; Wed, 05 May 2004 03:57:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLHGJ-0000nI-00 for sipping@ietf.org; Wed, 05 May 2004 03:56:16 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly05b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BLHFJ-0000Ry-00 for sipping@ietf.org; Wed, 05 May 2004 03:55:13 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly05b.srv.mailcontrol.com (MailControl) with SMTP id i457sYSc030610; Wed, 5 May 2004 08:54:34 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Wed, 5 May 2004 08:54:39 +0100 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] Poll: Consensus on adoption of the URI-list work Date: Wed, 5 May 2004 08:54:33 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF3B8@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sipping] Poll: Consensus on adoption of the URI-list work Thread-Index: AcQyBg1HBMyXG0avSU2blmadC9+laAAZs81QAAJQVTA= From: "Chris Boulton" To: , , Cc: , , 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 Obviously, I meant this for supporting ;-) >-----Original Message----- >From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >Sent: 05 May 2004 08:08 >To: dean.willis@softarmor.com; sipping@ietf.org >Cc: Gonzalo.Camarillo@ericsson.com; rohan@cisco.com; mankin@psg.com >Subject: RE: [Sipping] Poll: Consensus on adoption of the URI-list work > >Hi, > >Yes, I support adopting this, and I also agree that the draft seems to be >quite stable already. Proposed Standard makes more sense than >Informational, I think. > >Markus > >> -----Original Message----- >> From: sipping-admin@ietf.org >> [mailto:sipping-admin@ietf.org]On Behalf Of >> ext Dean Willis >> Sent: 04 May, 2004 21:14 >> To: sipping@ietf.org >> Cc: Gonzalo Camarillo; Rohan Mahy; Allison Mankin >> Subject: [Sipping] Poll: Consensus on adoption of the URI-list work >> >> >> >> See: draft-camarillo-sipping-uri-list-02.txt >> >> It seems that the URI-list stuff is becoming important for its use in >> ad-hoc list requests. I've heard of several other groups that are >> referring to it in their specifications, and wish for us to >> conclude on >> the specification ASAP. >> >> The current draft is fairly mature, and we seem to have a >> constituency >> for the specification. >> >> Consequently, I'd like to suggest that the SIPPING group consider >> adopting this draft as a working group effort, targeted for >> informational RFC, with an estimated delivery date to IESG of >> June, 2004. >> >> Please respond, aye or nay, if you care. The chairs will, as usual, >> judge consensus and report the recommendation (for or >> against) to the AD >> for consideration. >> >> Thanks, >> >> -- >> Dean Willis >> SIPPING co-chair >> >> >> >> >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the 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 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 Wed May 5 06:21:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04858 for ; Wed, 5 May 2004 06:21:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLJPm-0001TH-UD for sipping-archive@odin.ietf.org; Wed, 05 May 2004 06:14:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45AE9AI005640 for sipping-archive@odin.ietf.org; Wed, 5 May 2004 06:14:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLJN8-0008Eu-VI for sipping-web-archive@optimus.ietf.org; Wed, 05 May 2004 06:11:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04417 for ; Wed, 5 May 2004 06:11:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLJN5-0004FU-8e for sipping-web-archive@ietf.org; Wed, 05 May 2004 06:11:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLJMB-00043N-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 06:10:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLJLc-0003rP-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 06:09:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLJDA-00050y-Pf; Wed, 05 May 2004 06:01:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLJBj-0004N4-0y for sipping@optimus.ietf.org; Wed, 05 May 2004 05:59:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03454 for ; Wed, 5 May 2004 05:59:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLJBf-0001Za-Ax for sipping@ietf.org; Wed, 05 May 2004 05:59:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLJ7Z-0000ty-00 for sipping@ietf.org; Wed, 05 May 2004 05:55:22 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLJ5b-0000KC-00 for sipping@ietf.org; Wed, 05 May 2004 05:53:19 -0400 Received: from smtp6.clb.oleane.net ([213.56.31.26]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLItD-0007Ds-8e for sipping@ietf.org; Wed, 05 May 2004 05:40:31 -0400 Received: from Pavillonquatre ([194.206.151.59]) by smtp6.clb.oleane.net with ESMTP id i459duFS009148 for ; Wed, 5 May 2004 11:39:56 +0200 Message-Id: <200405050939.i459duFS009148@smtp6.clb.oleane.net> From: "Peter Lewis" To: Date: Wed, 5 May 2004 11:39:55 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C43295.B001F250" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQyhOvuzZ/6+tkgQyqqUqVF7YsvUg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: [Sipping] TVoDSL 2005: Broadcasting TV content over ADSL Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_RED,HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C43295.B001F250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit TVoDSL 2005: Broadcasting TV content over ADSL Home networks, middleware, access networks and compression tools: all the TVoDSL technical issues will be addressed in detail by the major manufacturing, economic and regulatory players in this promising new market at the TVoDSL Conference, to take place in Paris on January 25 to 28, 2005. The organizers expect more than 600 participants and 40 exhibitors at the Triple Play Showcase. The call for proposals dead line has been extended to May 28 Get all details at: http://www.upperside.fr/tvodsl2005/tvodsl2005cfp ------=_NextPart_000_0038_01C43295.B001F250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

TVoDSL 2005: Broadcasting TV content over ADSL

Home networks, middleware, access networks and compression tools: all = the TVoDSL technical issues will be addressed in detail by the major manufacturing, economic and regulatory players in this = promising new market at the TVoDSL Conference, to take place in Paris on January 25 to 28, 2005. =

The organizers expect more than 600 = participants and 40 exhibitors at the Triple Play Showcase.

 

The call for proposals dead line has been = extended to May 28

 

Get all details = at:

http://www.upperside.fr/tvodsl2005/tvodsl2005cfp<= /span>

 

 

 

------=_NextPart_000_0038_01C43295.B001F250-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 5 07:06:03 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06580 for ; Wed, 5 May 2004 07:06:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLKCE-0006Zb-BQ for sipping-archive@odin.ietf.org; Wed, 05 May 2004 07:04:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45B4EpS025268 for sipping-archive@odin.ietf.org; Wed, 5 May 2004 07:04:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLKBX-0006G6-0r for sipping-web-archive@optimus.ietf.org; Wed, 05 May 2004 07:03:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06547 for ; Wed, 5 May 2004 07:03:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLKBS-0007NG-US for sipping-web-archive@ietf.org; Wed, 05 May 2004 07:03:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLKAZ-0007BB-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 07:02:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLKA0-0006yp-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 07:01:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLK2L-00042x-Nf; Wed, 05 May 2004 06:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLK0v-0003Xr-W0 for sipping@optimus.ietf.org; Wed, 05 May 2004 06:52:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06151 for ; Wed, 5 May 2004 06:52:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLK0r-00050V-Pq for sipping@ietf.org; Wed, 05 May 2004 06:52:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLJzu-0004oT-00 for sipping@ietf.org; Wed, 05 May 2004 06:51:31 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BLJzc-0004bv-00 for sipping@ietf.org; Wed, 05 May 2004 06:51:12 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i45AoULc019131; Wed, 5 May 2004 05:50:31 -0500 (CDT) Received: from ericsson.com (rvi2-92-16.sw.ericsson.se [153.88.92.16]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQWK7FPJ; Wed, 5 May 2004 05:50:18 -0500 Message-ID: <4098C6F7.5050904@ericsson.com> Date: Wed, 05 May 2004 13:50:31 +0300 X-Sybari-Trust: 7d22eee2 08d63d2e 0d57a2e8 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: Dean Willis , sipping@ietf.org, Rohan Mahy , Allison Mankin Subject: Re: [Sipping] Re: WGLC for draft-ietf-sipping-transc-3pcc-00 References: <408F9D5F.6020407@softarmor.com> <4090B7A5.4020607@softarmor.com> <40913C65.3050305@cisco.com> <409152F0.70209@ericsson.com> <40917F16.90604@cisco.com> <4092202F.2030303@softarmor.com> <40924F31.6030504@cisco.com> In-Reply-To: <40924F31.6030504@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 Paul, We can add discussions on the issues you are mentioning to the framework document. They are interesting issues. I believe they belong to the framework document and not to the document we are WGLCing. This document deals with how to invoke a transcoder; not with the reasons that led you to decide to invoke it or with how to avoid using it. Thanks, Gonzalo Paul Kyzivat wrote: > > > Dean Willis wrote: > >> >> Paul pondered: > > > `:-) > >>> I suppose you could view this as a problem for the human operator of >>> the device - to select an appropriate phone feature based on known >>> capabilities of the callee. But that is pretty much a cop out. And it >>> doesn't work when the decision has to be made by the callee, as when >>> the initial invite has no offer, unless you expect the callee to >>> select different answer modes depending on who is calling. >> >> >> Would something like a priority-ordered preference/capability set in >> caller-preferences/callee caps be a big aid here? > > > Well, the normal use of callerprefs is to select among alternative > advertised contacts. That doesn't seem to be the case here. Of course an > endpoint *could* choose to alter its behavior based on callerprefs, but > I don't know if we want to suggest that. > > However I suppose a variant is possible. An endpoint with these > capabilities could register multiple contacts, tagged with capabilities > for voice and text. Depending upon which one was called, it could do the > right thing. And it could prioritize its native capabilities higher, so > that a forking proxy would try that first even if the caller expresses > no preferences. > > If that were done, when a call arrives at the contact associated with > text, only text would be offered. When a call arrives at the contact > associated with voice then all the games described in this draft would > be carried out. > > That sounds like an interesting approach. > > Paul -- 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 5 11:35:58 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21400 for ; Wed, 5 May 2004 11:35:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOFM-0002hI-JS for sipping-archive@odin.ietf.org; Wed, 05 May 2004 11:23:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45FNi9T010366 for sipping-archive@odin.ietf.org; Wed, 5 May 2004 11:23:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLO9a-0008HY-2c for sipping-web-archive@optimus.ietf.org; Wed, 05 May 2004 11:17:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20301 for ; Wed, 5 May 2004 11:17:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLO9Y-0005Xp-NZ for sipping-web-archive@ietf.org; Wed, 05 May 2004 11:17:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLO8h-0005JC-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 11:16:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLO87-000549-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 11:16:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNxL-0001Nl-3w; Wed, 05 May 2004 11:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNon-0006EZ-Sc for sipping@optimus.ietf.org; Wed, 05 May 2004 10:56:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17950 for ; Wed, 5 May 2004 10:56:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNol-0006r7-9d for sipping@ietf.org; Wed, 05 May 2004 10:56:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNnn-0006XW-00 for sipping@ietf.org; Wed, 05 May 2004 10:55:15 -0400 Received: from [200.51.236.210] (helo=mail3.telefonica.com.ar) by ietf-mx with esmtp (Exim 4.12) id 1BLNmb-0006BB-00 for sipping@ietf.org; Wed, 05 May 2004 10:54:01 -0400 Received: from mailhub.telefonica.com.ar ([10.249.7.11]) by mail3 with InterScan Messaging Security Suite; Wed, 05 May 2004 11:54:34 -0300 Received: by mailhub.telefonica.com.ar with Internet Mail Service (5.5.2657.72) id ; Wed, 5 May 2004 11:53:51 -0300 Message-ID: From: De Leo Walter To: sipping@ietf.org Cc: Veiga Jorge Date: Wed, 5 May 2004 11:53:41 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C432B0.C1545960" Subject: [Sipping] Service Discovery Mechanism using 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.2 required=5.0 tests=AWL,HTML_50_60,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_01C432B0.C1545960 Content-Type: text/plain; charset="iso-8859-1" Is there some work or plan to define a Service Discovery mechanismo using SIP? I elaborate: Suppose there is some AS providing a set of services. Is there a mechanism for: a) The AS publicize the services it provides. b) The UA access to a list of AS providing the service its user need. I find it very like a Presence Service but where the resource is not a user but a Service. That is a Service "Presence" Server would maintain a list of Service-AS presence status to which a user could subscribe. Is any work in this line of thought or interest in developing that mechanism? Or is there some other approach for this task? Regards. ______________________________________________________ Walter D. De Leo Defensa 390 Piso 1 (C1065AAF) Buenos Aires. Argentina Tel: 54 11 4332-5027 Fax: 54 11 4303-5586 Int 2302 email: deleow@telefonica.com.ar ------_=_NextPart_001_01C432B0.C1545960 Content-Type: text/html; charset="iso-8859-1" Mensaje
Is there some work or plan to define a Service Discovery mechanismo using SIP?
 
I elaborate:
 
Suppose there is some AS providing a set of services. Is there a mechanism for:
 
a) The AS publicize the services it provides.
b) The UA access to a list of AS providing the service its user need.
 
I find it very like a Presence Service but where the resource is not a user but a Service.
That is a Service "Presence" Server would maintain a list of Service-AS presence status to which a user could subscribe.
 
Is any work in this line of thought or interest in developing that mechanism?
 
Or is there some other approach for this task?
 
Regards.
 

______________________________________________________

Walter D. De Leo

Defensa 390 Piso 1 (C1065AAF) Buenos Aires. Argentina

Tel: 54 11 4332-5027  Fax: 54 11 4303-5586 Int 2302
email: deleow@telefonica.com.ar

 
------_=_NextPart_001_01C432B0.C1545960-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 5 11:49:55 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22100 for ; Wed, 5 May 2004 11:49:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOWN-0001Gm-AN for sipping-archive@odin.ietf.org; Wed, 05 May 2004 11:41:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45FfJZ5004875 for sipping-archive@odin.ietf.org; Wed, 5 May 2004 11:41:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOUp-0008Ow-1r for sipping-web-archive@optimus.ietf.org; Wed, 05 May 2004 11:39:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21585 for ; Wed, 5 May 2004 11:39:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLOUo-0003W4-1V for sipping-web-archive@ietf.org; Wed, 05 May 2004 11:39:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLOTu-0003I7-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 11:38:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLOTZ-00033o-00 for sipping-web-archive@ietf.org; Wed, 05 May 2004 11:38:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOFe-0003CK-FI; Wed, 05 May 2004 11:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLO5s-0007OB-VA for sipping@optimus.ietf.org; Wed, 05 May 2004 11:13:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20038 for ; Wed, 5 May 2004 11:13:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLO5s-0004Wm-3y for sipping@ietf.org; Wed, 05 May 2004 11:13:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLO4x-0004G5-00 for sipping@ietf.org; Wed, 05 May 2004 11:13:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BLO3r-0003gC-00 for sipping@ietf.org; Wed, 05 May 2004 11:11:51 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 05 May 2004 08:06:43 -0700 X-BrightmailFiltered: true 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 i45FBIYu021366; Wed, 5 May 2004 11:11:19 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIE01324; Wed, 5 May 2004 11:11:18 -0400 (EDT) Message-ID: <40990416.6000009@cisco.com> Date: Wed, 05 May 2004 11:11:18 -0400 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: Dean Willis , sipping@ietf.org, Rohan Mahy , Allison Mankin Subject: Re: [Sipping] Re: WGLC for draft-ietf-sipping-transc-3pcc-00 References: <408F9D5F.6020407@softarmor.com> <4090B7A5.4020607@softarmor.com> <40913C65.3050305@cisco.com> <409152F0.70209@ericsson.com> <40917F16.90604@cisco.com> <4092202F.2030303@softarmor.com> <40924F31.6030504@cisco.com> <4098C6F7.5050904@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: > Paul, > > We can add discussions on the issues you are mentioning to the framework > document. They are interesting issues. I believe they belong to the > framework document and not to the document we are WGLCing. This document > deals with how to invoke a transcoder; not with the reasons that led you > to decide to invoke it or with how to avoid using it. OK. Based on my "pondering", I did conclude that the UAS can know what to offer based on the contact address used. So moving the rest to the framework works. Paul > Thanks, > > Gonzalo > > Paul Kyzivat wrote: > >> >> >> Dean Willis wrote: >> >>> >>> Paul pondered: >> >> >> >> `:-) >> >>>> I suppose you could view this as a problem for the human operator of >>>> the device - to select an appropriate phone feature based on known >>>> capabilities of the callee. But that is pretty much a cop out. And >>>> it doesn't work when the decision has to be made by the callee, as >>>> when the initial invite has no offer, unless you expect the callee >>>> to select different answer modes depending on who is calling. >>> >>> >>> >>> Would something like a priority-ordered preference/capability set in >>> caller-preferences/callee caps be a big aid here? >> >> >> >> Well, the normal use of callerprefs is to select among alternative >> advertised contacts. That doesn't seem to be the case here. Of course >> an endpoint *could* choose to alter its behavior based on callerprefs, >> but I don't know if we want to suggest that. >> >> However I suppose a variant is possible. An endpoint with these >> capabilities could register multiple contacts, tagged with >> capabilities for voice and text. Depending upon which one was called, >> it could do the right thing. And it could prioritize its native >> capabilities higher, so that a forking proxy would try that first even >> if the caller expresses no preferences. >> >> If that were done, when a call arrives at the contact associated with >> text, only text would be offered. When a call arrives at the contact >> associated with voice then all the games described in this draft would >> be carried out. >> >> That sounds like an interesting approach. >> >> 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 May 6 11:10: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 LAA19202 for ; Thu, 6 May 2004 11:10:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkOA-0003jO-Kf for sipping-archive@odin.ietf.org; Thu, 06 May 2004 11:02:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46F2Ibx014342 for sipping-archive@odin.ietf.org; Thu, 6 May 2004 11:02:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkM5-0002Wz-JJ for sipping-web-archive@optimus.ietf.org; Thu, 06 May 2004 11:00:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18405 for ; Thu, 6 May 2004 11:00:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLkM3-0005cl-2u for sipping-web-archive@ietf.org; Thu, 06 May 2004 11:00:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLkKs-0005AC-00 for sipping-web-archive@ietf.org; Thu, 06 May 2004 10:58:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLkKL-0004ku-00 for sipping-web-archive@ietf.org; Thu, 06 May 2004 10:58:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLk7T-0006ET-R5; Thu, 06 May 2004 10:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjvd-0001Hq-8D for sipping@optimus.ietf.org; Thu, 06 May 2004 10:32:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16938 for ; Thu, 6 May 2004 10:32:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLjva-0001pi-SB for sipping@ietf.org; Thu, 06 May 2004 10:32:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLjud-0001QM-00 for sipping@ietf.org; Thu, 06 May 2004 10:31:47 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BLjtx-0000lC-00; Thu, 06 May 2004 10:31:05 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i46EUTLp031527; Thu, 6 May 2004 09:30:29 -0500 Message-ID: <409A4C01.5020401@dynamicsoft.com> Date: Thu, 06 May 2004 09:30:25 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: sipping@ietf.org, simple@ietf.org, Robert Sparks , Hisham Khartabil , Gonzalo Camarillo , Allison Mankin , Ted Hardie Subject: Re: [Sipping] Poll: Adopt message exploder draft from SIMPLE? References: <4097DFA1.2010609@softarmor.com> In-Reply-To: <4097DFA1.2010609@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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I concur that this work belongs in SIPPING, and that it makes sense to coordinate it with the "exploding" efforts for different methods. Dean Willis wrote: > > The SIMPLE working group has been discussing mechanisms for sending a > MESSAGE request to multiple recipients. It has been suggested that this > work might be more-at-home in the SIPPING group, as we'll also be > discussing "exploder" methods for otehr request types. > > The current draft is: > > draft-garcia-simple-message-exploder-00.txt > > I expect to see this work, when completed, referenced by the usual set > of external bodies that reference our work. > > So, I'd like to ask the SIPPING working group: How do you feel about > this? Anybody radically opposed to moving this from SIMPLE to SIPPING > and adopting the work? Anybody radically in favor? > > Thanks, > > -- > Dean Willis > SIPPING WG co-chair > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 May 6 15:24: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 PAA13566 for ; Thu, 6 May 2004 15:24:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLoJn-0004Up-91 for sipping-archive@odin.ietf.org; Thu, 06 May 2004 15:14:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46JE356017283 for sipping-archive@odin.ietf.org; Thu, 6 May 2004 15:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLoEr-0000VB-Il for sipping-web-archive@optimus.ietf.org; Thu, 06 May 2004 15:08:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12009 for ; Thu, 6 May 2004 15:08:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLoEo-0003df-H6 for sipping-web-archive@ietf.org; Thu, 06 May 2004 15:08:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLoDp-0003DJ-00 for sipping-web-archive@ietf.org; Thu, 06 May 2004 15:07:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLoCs-0002mp-00 for sipping-web-archive@ietf.org; Thu, 06 May 2004 15:06:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLo0Q-00054G-PF; Thu, 06 May 2004 14:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnsr-0001hK-Ne for sipping@optimus.ietf.org; Thu, 06 May 2004 14:46:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10545 for ; Thu, 6 May 2004 14:46:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLnso-0001s8-Td for sipping@ietf.org; Thu, 06 May 2004 14:46:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLnrl-0001SS-00 for sipping@ietf.org; Thu, 06 May 2004 14:45:06 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BLnrA-00011M-00 for sipping@ietf.org; Thu, 06 May 2004 14:44:28 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i46IfdLc018330; Thu, 6 May 2004 13:41:39 -0500 (CDT) Received: from ericsson.com (rvi2-93-91.sw.ericsson.se [153.88.93.91]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQWK09Q4; Thu, 6 May 2004 13:41:24 -0500 Message-ID: <409A86E3.80102@ericsson.com> Date: Thu, 06 May 2004 21:41:39 +0300 X-Sybari-Trust: 8688f00f 08d63d2e 7e64d14e 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: Miguel Garcia , Jonathan Rosemberg , SIPPING mailing list , Henning Schulzrinne References: <406DF1EC.4050400@cisco.com> <4085401C.2000008@nokia.com> <4086E14A.6080403@cisco.com> <4087BADB.70004@ericsson.com> <4087DC51.2050508@cisco.com> In-Reply-To: <4087DC51.2050508@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Simple] Re: Managing multiple body parts Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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, the set of issues you mention below could be documented in the guidelines for authors of SIP extensions document: http://www.jdrosen.net/papers/draft-ietf-sip-guidelines-07.txt This way, every document defining new body parts would take them into consideration. Jonathan, Henning, what is the status of that draft? Gonzalo Paul Kyzivat wrote: > > > Gonzalo Camarillo wrote: > >> Hi Paul, >> >> typically you either tag the body with a content disposition tag, or >> have a pointer somewhere in the message pointing to the body part... >> or both. > > > Note that even if you don't explicitly tag a body with a content > disposition it implicitly has one, because there is a defaulting rule. > >> What sort of things do you have in mind, besides the ones I mentioned? > > > Here are a few fuzzy issues: > > - what content-disposition should a multipart/mixed body have? > Should the recipient always look inside one for interesting > content, regardless of the disposition? > > - It is ok to nest body parts arbitrarily deep in nested > multipart/mixed bodies? Or is there a cannonical way that > body parts should be composed? > > - What should happen, in an invite, to a body part with > content-type of application/sdp but with a content-disposition > of something other than "session"? (E.g. "render".) > > - What should happen if an invite contains two body parts that > both have content-type of application/sdp and content-disposition > of session. (In a multipart/mixed, not multipart/alternative.) > > - What content-disposition should be used for the content of > a MESSAGE message? A NOTIFY message? A SUBSCRIBE message? > > - What content-disposition should be used for multipart/signed > and multipart/encrypted bodies? Should it match whatever it > is that is signed or encrypted? > > - What content-disposition should be used for body parts that > are referenced via a cid: uri somewhere in the message? > > - Does the fact that a body part is referenced by a cid: uri > mean that it shouldn't also be processed as it would have been > had it not been referenced by a cid: uri? What if the reference > is from an extension header that the recipient doesn't understand? > > - The content-disposition header has a handling parameter. > An error should be generated if any parts with handling=required > aren't able to be processed. In the context of sip, how is a > determination made whether a part has been processed? Is it > sufficient that it be understood even if it isn't acted upon? > > I can probably come up with more, but that is a start. > > 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 May 6 15:54: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 PAA15966 for ; Thu, 6 May 2004 15:54:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLosx-00026Z-PP for sipping-archive@odin.ietf.org; Thu, 06 May 2004 15:50:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46JoNsw008092 for sipping-archive@odin.ietf.org; Thu, 6 May 2004 15:50:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLoqe-0001Db-PY for sipping-web-archive@optimus.ietf.org; Thu, 06 May 2004 15:48:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15591 for ; Thu, 6 May 2004 15:47:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLoqd-0004jO-Aw for sipping-web-archive@ietf.org; Thu, 06 May 2004 15:47:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLopn-0004Hb-00 for sipping-web-archive@ietf.org; Thu, 06 May 2004 15:47:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLoom-0003nm-00 for sipping-web-archive@ietf.org; Thu, 06 May 2004 15:46:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLog3-0005UK-U8; Thu, 06 May 2004 15:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLoe5-0004Xb-S6 for sipping@optimus.ietf.org; Thu, 06 May 2004 15:35:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14542 for ; Thu, 6 May 2004 15:34:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLoe4-0006nZ-Gy for sipping@ietf.org; Thu, 06 May 2004 15:35:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLod4-0006Nh-00 for sipping@ietf.org; Thu, 06 May 2004 15:33:59 -0400 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 1BLocE-0005ax-00 for sipping@ietf.org; Thu, 06 May 2004 15:33:06 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 06 May 2004 11:47:19 +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 i46JWXW9018470; Thu, 6 May 2004 12:32:33 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIF07416; Thu, 6 May 2004 15:32:32 -0400 (EDT) Message-ID: <409A92CF.4000300@cisco.com> Date: Thu, 06 May 2004 15:32:31 -0400 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: Miguel Garcia , Jonathan Rosemberg , SIPPING mailing list , Henning Schulzrinne References: <406DF1EC.4050400@cisco.com> <4085401C.2000008@nokia.com> <4086E14A.6080403@cisco.com> <4087BADB.70004@ericsson.com> <4087DC51.2050508@cisco.com> <409A86E3.80102@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Simple] Re: Managing multiple body parts Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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, Adding stuff to the guidelines for extensions won't help clarify stuff that is already out there, like 3261. Someone who only sets out to implement 3261 faces some of these issues regarding what might be received and how to interpret it. Seems like eventually something might need to go into the next rev of 3261. But it still sounds like this might be a good place to start. I guess it isn't the issues that should be documented in the guidelines for authors - it is guidelines for addressing the issues that need to be there. I suspect there is not concensus on the proper resolution for those issues. But I suppose that can be cured by proposing something for the guidelines and seeing what complaints arise. If that is the right place, and the intent is to rev that draft, I could propose some new content for section 4.12. Thanks, Paul Gonzalo Camarillo wrote: > Paul, > > the set of issues you mention below could be documented in the > guidelines for authors of SIP extensions document: > > http://www.jdrosen.net/papers/draft-ietf-sip-guidelines-07.txt > > This way, every document defining new body parts would take them into > consideration. > > Jonathan, Henning, what is the status of that draft? > > Gonzalo > > > > Paul Kyzivat wrote: > >> >> >> Gonzalo Camarillo wrote: >> >>> Hi Paul, >>> >>> typically you either tag the body with a content disposition tag, or >>> have a pointer somewhere in the message pointing to the body part... >>> or both. >> >> >> >> Note that even if you don't explicitly tag a body with a content >> disposition it implicitly has one, because there is a defaulting rule. >> >>> What sort of things do you have in mind, besides the ones I mentioned? >> >> >> >> Here are a few fuzzy issues: >> >> - what content-disposition should a multipart/mixed body have? >> Should the recipient always look inside one for interesting >> content, regardless of the disposition? >> >> - It is ok to nest body parts arbitrarily deep in nested >> multipart/mixed bodies? Or is there a cannonical way that >> body parts should be composed? >> >> - What should happen, in an invite, to a body part with >> content-type of application/sdp but with a content-disposition >> of something other than "session"? (E.g. "render".) >> >> - What should happen if an invite contains two body parts that >> both have content-type of application/sdp and content-disposition >> of session. (In a multipart/mixed, not multipart/alternative.) >> >> - What content-disposition should be used for the content of >> a MESSAGE message? A NOTIFY message? A SUBSCRIBE message? >> >> - What content-disposition should be used for multipart/signed >> and multipart/encrypted bodies? Should it match whatever it >> is that is signed or encrypted? >> >> - What content-disposition should be used for body parts that >> are referenced via a cid: uri somewhere in the message? >> >> - Does the fact that a body part is referenced by a cid: uri >> mean that it shouldn't also be processed as it would have been >> had it not been referenced by a cid: uri? What if the reference >> is from an extension header that the recipient doesn't understand? >> >> - The content-disposition header has a handling parameter. >> An error should be generated if any parts with handling=required >> aren't able to be processed. In the context of sip, how is a >> determination made whether a part has been processed? Is it >> sufficient that it be understood even if it isn't acted upon? >> >> I can probably come up with more, but that is a start. >> >> 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 Fri May 7 11:09:04 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29661 for ; Fri, 7 May 2004 11:09:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6b5-00052h-AE for sipping-archive@odin.ietf.org; Fri, 07 May 2004 10:45:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47Ej601019380 for sipping-archive@odin.ietf.org; Fri, 7 May 2004 10:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6NW-00081T-QM for sipping-web-archive@optimus.ietf.org; Fri, 07 May 2004 10:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25994 for ; Fri, 7 May 2004 10:31:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM6NU-0006U8-Jb for sipping-web-archive@ietf.org; Fri, 07 May 2004 10:31:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM6Mb-00061B-00 for sipping-web-archive@ietf.org; Fri, 07 May 2004 10:30:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM6Lc-0005XF-00 for sipping-web-archive@ietf.org; Fri, 07 May 2004 10:29:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5vb-0000vD-VW; Fri, 07 May 2004 10:02:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM3bt-0003LS-RH for sipping@optimus.ietf.org; Fri, 07 May 2004 07:33:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16449 for ; Fri, 7 May 2004 07:33:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM3bt-00001T-5k for sipping@ietf.org; Fri, 07 May 2004 07:33:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM3b6-0007QD-00 for sipping@ietf.org; Fri, 07 May 2004 07:32:57 -0400 Received: from viap106.atea.be ([194.78.143.106] helo=hrtades9.atea.be) by ietf-mx with esmtp (Exim 4.12) id 1BM3aL-0006wz-00 for sipping@ietf.org; Fri, 07 May 2004 07:32:09 -0400 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JMT2YM0V; Fri, 7 May 2004 13:31:38 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Fri, 7 May 2004 13:31:38 +0200 Message-ID: <6B546A602AD2D211BFF00008C7A428890A940FA5@hrtades2.atea.be> From: Huybrighs Joseph To: "'sipping@ietf.org'" Date: Fri, 7 May 2004 13:31:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sipping] SIP Transfer Failure Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 Both draft-ietf-sipping-cc-transfer-02 and draft-ietf-sipping-service-examples-06 not really describe how the Transferor, after having invoked transfer, can be re-invited in case the transfer failed (e.g. the Transfer-Target failed to answer, wrong address in case of a blind transfer, etc.). Consider the following scenario: A establishes a dialog with B. B transfers to C. The dialog between A and C terminates with a 4xx. Solution from draft: B A C | (D1) REFER/202 | | |----------------------->| INVITE/18x | | |----------------->| | | 4xx | | (D1) NOTIFY (4xx)/200 |<-----------------| |<-----------------------| | | (D1) BYE/200 | | |----------------------->| | | | | | (D1) re-INVITE/200 | | |----------------------->| | | RTP | | |<---------------------->| | The proposal puts the responsibility to re-connect A and B on the Transferor. This works fine in case the Transferor still has an established dialog with the Transferee and an active User Interface that keeps track of what happened with the transfer request. Depending on the type of device the Transferor is using, this will not always be the case. E.g. if the Transferor is using a simple POTS phone, the transfer might have been initiated by going on hook during the consultation call with C. To get the Transferor back to the Transferee we will have to ring the Transferor's phone. This is not obvious with the proposed solution. Alternative Solution: B A C | (D1) REFER/202 | | |----------------------->| INVITE/18x | | |----------------->| | | 4xx | | (D1) NOTIFY (4xx)/200 |<-----------------| |<-----------------------| | | (D1) BYE/200 | | |----------------------->| | | | | | (D2) INVITE/18x/200 | | |<-----------------------| | | RTP | | |<---------------------->| | I would think that re-connecting the Transferor back to the Transferee is a feature that has to be controlled by the Transferee. This is indicated in the above diagram by the A party sending an new INVITE request to B resulting in the creation of a new dialog (D2). The original dialog (D1) can then be terminated when a final response is passed through the NOTIFY request. It also nicely solves ringing the Transferor when he or she would have gone on-hook before the transfer request finished. E.g. the A party being the initiator of the new 'call' would get ring-back tone if it is a POTS phone. Does this make sense? Jos Huybrighs Siemens _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 10 05:17:56 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18866 for ; Mon, 10 May 2004 05:17:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN6tW-0007yr-Ed for sipping-archive@odin.ietf.org; Mon, 10 May 2004 05:16:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4A9GII2030639 for sipping-archive@odin.ietf.org; Mon, 10 May 2004 05:16:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN6qq-0007Vp-El for sipping-web-archive@optimus.ietf.org; Mon, 10 May 2004 05:13:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18651 for ; Mon, 10 May 2004 05:13:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN6qn-0005k8-6p for sipping-web-archive@ietf.org; Mon, 10 May 2004 05:13:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN6po-0005QU-00 for sipping-web-archive@ietf.org; Mon, 10 May 2004 05:12:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN6on-0004zC-00 for sipping-web-archive@ietf.org; Mon, 10 May 2004 05:11:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN6fp-0003TE-2V; Mon, 10 May 2004 05:02:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN6eS-0003Kv-Cg for sipping@optimus.ietf.org; Mon, 10 May 2004 05:00:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18138 for ; Mon, 10 May 2004 05:00:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN6eP-0001nY-8a for sipping@ietf.org; Mon, 10 May 2004 05:00:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN6dQ-0001Uz-00 for sipping@ietf.org; Mon, 10 May 2004 04:59:40 -0400 Received: from firewall.citel.com ([62.190.107.60] helo=ivor.citel.com) by ietf-mx with smtp (Exim 4.12) id 1BN6cf-0000uR-00 for sipping@ietf.org; Mon, 10 May 2004 04:58:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 10 May 2004 09:38:43 +0100 Message-ID: Thread-Topic: Parking and retrieving calls Thread-Index: AcQ2aitVGjgPpiU5Sg64kUTJlDhcOA== From: "Michael Procter" To: Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Parking and retrieving calls Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 have been working on a call park/retrieve implementation, based upon = the example given in the Service Examples. In particular, I want to = solve the problem of identifying the parked call for retrieval by some = mechanism other than the dialog id. I have written up my ideas in an ID: http://www.ietf.org/internet-drafts/draft-procter-sipping-call-park-exten= sion-00.txt Has anyone else tried to solve this problem? What do people think of = this approach? What changes can be made to make the approach better? Regards, Michael Procter _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 10 07:24:57 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25471 for ; Mon, 10 May 2004 07:24:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8ly-0005Mr-Di for sipping-archive@odin.ietf.org; Mon, 10 May 2004 07:16:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ABGcEx020634 for sipping-archive@odin.ietf.org; Mon, 10 May 2004 07:16:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8l2-0005Fg-LV for sipping-web-archive@optimus.ietf.org; Mon, 10 May 2004 07:15:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24977 for ; Mon, 10 May 2004 07:15:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN8l2-0005CQ-58 for sipping-web-archive@ietf.org; Mon, 10 May 2004 07:15:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN8kG-0004uE-00 for sipping-web-archive@ietf.org; Mon, 10 May 2004 07:14:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN8jd-0004bl-00 for sipping-web-archive@ietf.org; Mon, 10 May 2004 07:14:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8bk-0003tk-6H; Mon, 10 May 2004 07:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8YZ-0003RV-10 for sipping@optimus.ietf.org; Mon, 10 May 2004 07:02:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24187 for ; Mon, 10 May 2004 07:02:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN8YU-00012j-Pb for sipping@ietf.org; Mon, 10 May 2004 07:02:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN8Xc-0000h0-00 for sipping@ietf.org; Mon, 10 May 2004 07:01:49 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 1BN8Wa-0000Lg-00 for sipping@ietf.org; Mon, 10 May 2004 07:00:45 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id NAA11677 for ; Mon, 10 May 2004 13:05:39 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma011367; Mon, 10 May 04 13:04:28 +0200 Received: from IVD-Message_Server by gw-server.viataal.nl with Novell_GroupWise; Mon, 10 May 2004 13:00:21 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Mon, 10 May 2004 13:00:04 +0200 From: "A vWijk" To: , Cc: , , , Subject: Betr.: Re: [Sipping] Re: WGLC for draft-ietf-sipping-transc-3pcc-00 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Indeed. The transcoding draft can asume that the UAS somehow know that it = is a call that needs a relay and that the service needs to be invoked. The framework draft should address how and when there is a need for a = relay invocation. And which type (text, signlanguage etc). 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 >>> Paul Kyzivat 05-05-04 17:11 >>> Gonzalo Camarillo wrote: > Paul, >=20 > We can add discussions on the issues you are mentioning to the = framework=20 > document. They are interesting issues. I believe they belong to the=20 > framework document and not to the document we are WGLCing. This = document=20 > deals with how to invoke a transcoder; not with the reasons that led = you=20 > to decide to invoke it or with how to avoid using it. OK. Based on my "pondering", I did conclude that the UAS can know what=20 to offer based on the contact address used. So moving the rest to the=20 framework works. Paul > Thanks, >=20 > Gonzalo >=20 > Paul Kyzivat wrote: >=20 >> >> >> Dean Willis wrote: >> >>> >>> Paul pondered: >> >> >> >> `:-) >> >>>> I suppose you could view this as a problem for the human operator = of=20 >>>> the device - to select an appropriate phone feature based on known=20 >>>> capabilities of the callee. But that is pretty much a cop out. And=20 >>>> it doesn't work when the decision has to be made by the callee, = as=20 >>>> when the initial invite has no offer, unless you expect the callee=20 >>>> to select different answer modes depending on who is calling. >>> >>> >>> >>> Would something like a priority-ordered preference/capability set = in=20 >>> caller-preferences/callee caps be a big aid here? >> >> >> >> Well, the normal use of callerprefs is to select among alternative=20 >> advertised contacts. That doesn't seem to be the case here. Of = course=20 >> an endpoint *could* choose to alter its behavior based on callerprefs,= =20 >> but I don't know if we want to suggest that. >> >> However I suppose a variant is possible. An endpoint with these=20 >> capabilities could register multiple contacts, tagged with=20 >> capabilities for voice and text. Depending upon which one was called,=20= >> it could do the right thing. And it could prioritize its native=20 >> capabilities higher, so that a forking proxy would try that first = even=20 >> if the caller expresses no preferences. >> >> If that were done, when a call arrives at the contact associated = with=20 >> text, only text would be offered. When a call arrives at the contact=20 >> associated with voice then all the games described in this draft = would=20 >> be carried out. >> >> That sounds like an interesting approach. >> >> Paul >=20 >=20 _______________________________________________ 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 Mon May 10 17:53: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 RAA08922 for ; Mon, 10 May 2004 17:53:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNIaF-0003Wn-9s for sipping-archive@odin.ietf.org; Mon, 10 May 2004 17:45:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ALjBhu013543 for sipping-archive@odin.ietf.org; Mon, 10 May 2004 17:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNILo-0000Fd-2d for sipping-web-archive@optimus.ietf.org; Mon, 10 May 2004 17:30:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07575 for ; Mon, 10 May 2004 17:30:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNILl-0006Ug-Lv for sipping-web-archive@ietf.org; Mon, 10 May 2004 17:30:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNIJJ-0005b6-00 for sipping-web-archive@ietf.org; Mon, 10 May 2004 17:27:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNIG7-0004dR-00 for sipping-web-archive@ietf.org; Mon, 10 May 2004 17:24:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNI7H-0003kh-Sc; Mon, 10 May 2004 17:15:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNHj6-0002J6-Pi for sipping@optimus.ietf.org; Mon, 10 May 2004 16:50:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02875 for ; Mon, 10 May 2004 16:50:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNHj4-0007T0-Ox for sipping@ietf.org; Mon, 10 May 2004 16:50:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNHi7-00072t-00 for sipping@ietf.org; Mon, 10 May 2004 16:49:15 -0400 Received: from natsmtp00.rzone.de ([81.169.145.165]) by ietf-mx with esmtp (Exim 4.12) id 1BNHgx-0006fF-00 for sipping@ietf.org; Mon, 10 May 2004 16:48:03 -0400 Received: from sip (pD9E79918.dip.t-dialin.net [217.231.153.24]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i4AKm1pt019569; Mon, 10 May 2004 22:48:01 +0200 (MEST) From: "Christian Stredicke" To: "'Michael Procter'" Cc: Subject: RE: [Sipping] Parking and retrieving calls Date: Mon, 10 May 2004 22:48:05 +0200 Message-ID: <03a401c436d0$18814900$0b01a8c0@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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 I think it's a feature to park a call on a specific server; otherwise it would be difficult to shout through the police department "hey dude, can = you pick up line 2?" For attendant transfer (currently the only to generate proper music on hold!) however it does make sense to have a fabric that automatically allocates a park orbit. But in this case it's possible to pick up = exactly that call again because the user agent has all the information to pick exactly that call up (e.g. call-id). No need to shout through the office = in this case! All that your media server needs to support is multiple calls = on the same orbit. Christian > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf = Of > Michael Procter > Sent: Monday, May 10, 2004 10:39 AM > To: sipping@ietf.org > Subject: [Sipping] Parking and retrieving calls >=20 > I have been working on a call park/retrieve implementation, based upon = the > example given in the Service Examples. In particular, I want to solve = the > problem of identifying the parked call for retrieval by some mechanism > other than the dialog id. >=20 > I have written up my ideas in an ID: > http://www.ietf.org/internet-drafts/draft-procter-sipping-call-park- > extension-00.txt >=20 > Has anyone else tried to solve this problem? What do people think of = this > approach? What changes can be made to make the approach better? >=20 > Regards, >=20 > Michael Procter >=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 Mon May 10 18:30:05 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12404 for ; Mon, 10 May 2004 18:30:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJAH-0002WF-JW for sipping-archive@odin.ietf.org; Mon, 10 May 2004 18:22:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AMMPMB009651 for sipping-archive@odin.ietf.org; Mon, 10 May 2004 18:22:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJ0M-0005nq-Dg for sipping-web-archive@optimus.ietf.org; Mon, 10 May 2004 18:12:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11038 for ; Mon, 10 May 2004 18:12:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNJ0J-0005wM-Jv for sipping-web-archive@ietf.org; Mon, 10 May 2004 18:12:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNIzI-0005aR-00 for sipping-web-archive@ietf.org; Mon, 10 May 2004 18:11:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNIyG-00056A-00 for sipping-web-archive@ietf.org; Mon, 10 May 2004 18:10:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNIpa-0007S9-04; Mon, 10 May 2004 18:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNIbU-000459-Go for sipping@optimus.ietf.org; Mon, 10 May 2004 17:46:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08627 for ; Mon, 10 May 2004 17:46:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNIbR-0004Ug-QY for sipping@ietf.org; Mon, 10 May 2004 17:46:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNIaR-00048B-00 for sipping@ietf.org; Mon, 10 May 2004 17:45:24 -0400 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 1BNIZf-0003jP-00 for sipping@ietf.org; Mon, 10 May 2004 17:44:35 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 10 May 2004 13:48:11 +0000 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 i4ALi3W9016718; Mon, 10 May 2004 14:44:04 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATA94793; Mon, 10 May 2004 14:43:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5D3BA2BA-A2B1-11D8-813A-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: Rohan Mahy From: Rohan Mahy Date: Mon, 10 May 2004 14:39:26 -0400 To: sipping (E-mail) X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Subject: [Sipping] interactivity caller preferences parameter -- for the 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.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Folks, Back in Korea, I presented a proposed solution to the dialog package "hold" discussion which I never described on the list. It has been several months now, but I would like to describe this proposal now. I am extremely sorry and embarrassed that I have taken so long to send this out. The proposal is to add a new caller preferences parameter (these are formally called "media feature parameters" in caller prefs). The interactivity parameter indicates if a device is capable of responding to media received during a session in an interactive manner and if necessary terminating a session in which the UA is no longer interested in participating. For example: - If you are in a session with an automaton that does not respond to media nor run call timers (for example a simple recording service, or the "time of day" service in Tokyo Japan), your peer is non-interactive - If you are in a session with an IVR-style application or an application with a media inactivity timeout, your peer is interactive. - If you are in a session with a human user who just put you "on hold", your peer is non-interactive. - If you are in a active session with a human call center agent in most call centers, your peer is interactive. - If you are in a normal session with another human, you don't (and can't) know if your peer is interactive or non-interactive. [This property is quite normal for caller preferences and does not diminish the usefulness of this parameter when you do know its value. For example, it is unwise to assume that a peer is not an automata, just because the automata parameter is not set; the automata/human status is unknown.] What can you do with this information? (Note that in many cases positive knowledge that a peer is non-interactive has a more immediate effect than positive knowledge that a peer in interactive) - This information can be conveyed in the dialog package and used as part of a shared-line implementation. For example, if a group of phones have all subscribed to the dialog package for the same address of record, they will receive notifications whenever the local contact address changes in any of the dialogs for this address of record. Implementations could use the non-interactive parameter on a phone or a "parking lot" application as a way to indicate that a shared line is "holding" or "parked". - This proposed property is also incredibly useful in conferencing scenarios. A focus can include in the termination policy of an adhoc conference, the interactivity status of the participants. For example, if the only participants in a conference are non-interactive, an adhoc conference is unlikely to be especially interesting (ex: a recording bot and a human who placed the conference on-hold). I believe this satisfies all the requirements for indicating if a user is on hold, but captures a more fundamental and generic mechanism/primitive. I believe that also maintains the "maximum orthogonality among attributes" property of most of the other caller preferences media feature parameters. Please comment. 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 Mon May 10 20:41:12 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19133 for ; Mon, 10 May 2004 20:41:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLDg-0005qw-GH for sipping-archive@odin.ietf.org; Mon, 10 May 2004 20:34:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B0Y4kL022475 for sipping-archive@odin.ietf.org; Mon, 10 May 2004 20:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNL4C-0003hK-0p for sipping-web-archive@optimus.ietf.org; Mon, 10 May 2004 20:24:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18348 for ; Mon, 10 May 2004 20:24:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNL49-000527-QW for sipping-web-archive@ietf.org; Mon, 10 May 2004 20:24:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNL3F-0004hI-00 for sipping-web-archive@ietf.org; Mon, 10 May 2004 20:23:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNL2G-0004LE-00 for sipping-web-archive@ietf.org; Mon, 10 May 2004 20:22:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNKsL-0000uM-LF; Mon, 10 May 2004 20:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNKko-0007LX-P5 for sipping@optimus.ietf.org; Mon, 10 May 2004 20:04:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17584 for ; Mon, 10 May 2004 20:04:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNKkm-00067s-N0 for sipping@ietf.org; Mon, 10 May 2004 20:04:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNKjq-0005oK-00 for sipping@ietf.org; Mon, 10 May 2004 20:03:15 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1BNKj3-0005B6-00 for sipping@ietf.org; Mon, 10 May 2004 20:02:25 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4B01dK12966; Mon, 10 May 2004 19:01:39 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 May 2004 17:01:39 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20FFA8B6D@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Rohan Mahy'" , "'sipping'" Subject: RE: [Sipping] interactivity caller preferences parameter -- for t he dialog package Date: Mon, 10 May 2004 17:01:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C436EB.214F571E" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_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_01C436EB.214F571E Content-Type: text/plain Hi Rohan, I think such an interactivity indication would be very valuable. One area where it would be useful is in a Call Center situation. For example, after a certain amount of time of non-interactivity listening to elevator music, the call is pushed to a free agent (through REFER or 3rd party call control for example). It can also be used for statistics to know how long it takes to answer customer inquires, to monitor your agents' efficiency and so forth. > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Monday, May 10, 2004 11:39 > To: sipping > Cc: Rohan Mahy > Subject: [Sipping] interactivity caller preferences parameter > -- for the dialog package > > > Hi Folks, > > Back in Korea, I presented a proposed solution to the dialog package > "hold" discussion which I never described on the list. It has been > several months now, but I would like to describe this proposal now. I > am extremely sorry and embarrassed that I have taken so long to send > this out. > > The proposal is to add a new caller preferences parameter (these are > formally called "media feature parameters" in caller prefs). The > interactivity parameter indicates if a device is capable of > responding > to media received during a session in an interactive manner and if > necessary terminating a session in which the UA is no longer > interested > in participating. > > For example: > > - If you are in a session with an automaton that does not respond to > media nor run call timers (for example a simple recording service, or > the "time of day" service in Tokyo Japan), your peer is > non-interactive > - If you are in a session with an IVR-style application or an > application with a media inactivity timeout, your peer is interactive. > - If you are in a session with a human user who just put you > "on hold", > your peer is non-interactive. > - If you are in a active session with a human call center > agent in most > call centers, your peer is interactive. > - If you are in a normal session with another human, you don't (and > can't) know if your peer is interactive or non-interactive. [This > property is quite normal for caller preferences and does not diminish > the usefulness of this parameter when you do know its value. For > example, it is unwise to assume that a peer is not an automata, just > because the automata parameter is not set; the automata/human > status is > unknown.] > > What can you do with this information? (Note that in many cases > positive knowledge that a peer is non-interactive has a more > immediate > effect than positive knowledge that a peer in interactive) > > - This information can be conveyed in the dialog package and used as > part of a shared-line implementation. For example, if a group of > phones have all subscribed to the dialog package for the same address > of record, they will receive notifications whenever the local contact > address changes in any of the dialogs for this address of record. > Implementations could use the non-interactive parameter on a > phone or a > "parking lot" application as a way to indicate that a shared line is > "holding" or "parked". > > - This proposed property is also incredibly useful in conferencing > scenarios. A focus can include in the termination policy of an adhoc > conference, the interactivity status of the participants. > For example, > if the only participants in a conference are non-interactive, > an adhoc > conference is unlikely to be especially interesting (ex: a recording > bot and a human who placed the conference on-hold). > > I believe this satisfies all the requirements for indicating > if a user > is on hold, but captures a more fundamental and generic > mechanism/primitive. I believe that also maintains the "maximum > orthogonality among attributes" property of most of the other caller > preferences media feature parameters. > > Please comment. > > 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 > ------_=_NextPart_001_01C436EB.214F571E Content-Type: text/html RE: [Sipping] interactivity caller preferences parameter -- for the dialog package

Hi Rohan,

I think such an interactivity indication would be very valuable.

One area where it would be useful is in a Call Center situation.
For example, after a certain amount of time of non-interactivity
listening to elevator music, the call is pushed to a free agent
(through REFER or 3rd party call control for example). It can
also be used for statistics to know how long it takes to
answer customer inquires, to monitor your agents' efficiency and
so forth.


> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: Monday, May 10, 2004 11:39
> To: sipping
> Cc: Rohan Mahy
> Subject: [Sipping] interactivity caller preferences parameter
> -- for the dialog package
>
>
> Hi Folks,
>
> Back in Korea, I presented a proposed solution to the dialog package
> "hold" discussion which I never described on the list.  It has been
> several months now, but I would like to describe this proposal now. I
> am extremely sorry and embarrassed that I have taken so long to send
> this out.
>
> The proposal is to add a new caller preferences parameter (these are
> formally called "media feature parameters" in caller prefs).  The
> interactivity parameter indicates if a device is capable of
> responding
> to media received during a session in an interactive manner and if
> necessary terminating a session in which the UA is no longer
> interested
> in participating.
>
> For example:
>
> - If you are in a session with an automaton that does not respond to
> media nor run call timers (for example a simple recording service, or
> the "time of day" service in Tokyo Japan), your peer is
> non-interactive
> - If you are in a session with an IVR-style application or an
> application with a media inactivity timeout, your peer is interactive.
> - If you are in a session with a human user who just put you
> "on hold",
> your peer is non-interactive.
> - If you are in a active session with a human call center
> agent in most
> call centers, your peer is interactive.
> - If you are in a normal session with another human, you don't (and
> can't) know if your peer is interactive or non-interactive.  [This
> property is quite normal for caller preferences and does not diminish
> the usefulness of this parameter when you do know its value.  For
> example, it is unwise to assume that a peer is not an automata, just
> because the automata parameter is not set; the automata/human
> status is
> unknown.]
>
> What can you do with this information?  (Note that in many cases
> positive knowledge that a peer is non-interactive has a more
> immediate
> effect than positive knowledge that a peer in interactive)
>
> - This information can be conveyed in the dialog package and used as
> part of a shared-line implementation.  For example, if a group of
> phones have all subscribed to the dialog package for the same address
> of record, they will receive notifications whenever the local contact
> address changes in any of the dialogs for this address of record.
> Implementations could use the non-interactive parameter on a
> phone or a
> "parking lot" application as a way to indicate that a shared line is
> "holding" or "parked".
>
> - This proposed property is also incredibly useful in conferencing
> scenarios.  A focus can include in the termination policy of an adhoc
> conference, the interactivity status of the participants. 
> For example,
> if the only participants in a conference are non-interactive,
> an adhoc
> conference is unlikely to be especially interesting (ex: a recording
> bot and a human who placed the conference on-hold).
>
> I believe this satisfies all the requirements for indicating
> if a user
> is on hold, but captures a more fundamental and generic
> mechanism/primitive.  I believe that also maintains the "maximum
> orthogonality among attributes" property of most of the other caller
> preferences media feature parameters.
>
> Please comment.
>
> 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
>

------_=_NextPart_001_01C436EB.214F571E-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 11 03:16:38 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07699 for ; Tue, 11 May 2004 03:16:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNRPj-0000Dj-89 for sipping-archive@odin.ietf.org; Tue, 11 May 2004 03:10:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B7AtFx000836 for sipping-archive@odin.ietf.org; Tue, 11 May 2004 03:10:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNRAL-00056d-1n for sipping-web-archive@optimus.ietf.org; Tue, 11 May 2004 02:55:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06901 for ; Tue, 11 May 2004 02:54:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNRAH-0002dO-8x for sipping-web-archive@ietf.org; Tue, 11 May 2004 02:54:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNR97-0002B8-00 for sipping-web-archive@ietf.org; Tue, 11 May 2004 02:53:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNR7q-0001fR-00 for sipping-web-archive@ietf.org; Tue, 11 May 2004 02:52:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNQwC-0001js-JI; Tue, 11 May 2004 02:40:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNQrV-0000XI-R5 for sipping@optimus.ietf.org; Tue, 11 May 2004 02:35:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05889 for ; Tue, 11 May 2004 02:35:30 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNQrS-0003Bh-2N for sipping@ietf.org; Tue, 11 May 2004 02:35:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNQqY-0002qd-00 for sipping@ietf.org; Tue, 11 May 2004 02:34:34 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BNQq8-0002VZ-00 for sipping@ietf.org; Tue, 11 May 2004 02:34:08 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4B6Y8v20078 for ; Tue, 11 May 2004 09:34:08 +0300 (EET DST) X-Scanned: Tue, 11 May 2004 09:34:04 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4B6Y400028805 for ; Tue, 11 May 2004 09:34:04 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00aByIRo; Tue, 11 May 2004 09:34:03 EEST 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 i4B6Y3H25686 for ; Tue, 11 May 2004 09:34:03 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 May 2004 09:34:02 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 May 2004 09:34:02 +0300 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, 11 May 2004 09:34:02 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A96@esebe019.ntc.nokia.com> Thread-Topic: Deadline for internet drafts submission before interim Thread-Index: AcQ3IfLjM5AhW2GqTSe+UcotRoQVjQ== To: X-OriginalArrivalTime: 11 May 2004 06:34:02.0784 (UTC) FILETIME=[F341CA00:01C43721] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Deadline for internet drafts submission before interim Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 The Deadline for submitting internet drafts for discussion at the = interim meeting is Monday 17th May. This hopefully gives attendees = enough time to read the IDs to enable them to engage in discussions. Regards, Hisham (on behalf of the SIMPLE, SIP, SIPPING and XCON WG chairs) _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 11 04:00: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 EAA09743 for ; Tue, 11 May 2004 04:00:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNRzy-0000w8-RX for sipping-archive@odin.ietf.org; Tue, 11 May 2004 03:48:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B7mMwL003595 for sipping-archive@odin.ietf.org; Tue, 11 May 2004 03:48:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNRtW-0007gM-FQ for sipping-web-archive@optimus.ietf.org; Tue, 11 May 2004 03:41:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08983 for ; Tue, 11 May 2004 03:41:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNRtU-0004J0-6u for sipping-web-archive@ietf.org; Tue, 11 May 2004 03:41:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNRsc-0003v7-00 for sipping-web-archive@ietf.org; Tue, 11 May 2004 03:40:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNRrj-0003Y7-00 for sipping-web-archive@ietf.org; Tue, 11 May 2004 03:39:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNRlA-0005FS-Sl; Tue, 11 May 2004 03:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNRSH-0000kU-Ai for sipping@optimus.ietf.org; Tue, 11 May 2004 03:13:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07617 for ; Tue, 11 May 2004 03:13:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNRSF-0001fR-68 for sipping@ietf.org; Tue, 11 May 2004 03:13:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNRRK-0001Ig-00 for sipping@ietf.org; Tue, 11 May 2004 03:12:34 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BNRQP-0000uq-00 for sipping@ietf.org; Tue, 11 May 2004 03:11:37 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4B7BWB10117; Tue, 11 May 2004 10:11:33 +0300 (EET DST) X-Scanned: Tue, 11 May 2004 10:11:22 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4B7BM3X030283; Tue, 11 May 2004 10:11:22 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00x4lEpp; Tue, 11 May 2004 10:10:06 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4B7A6H13022; Tue, 11 May 2004 10:10:06 +0300 (EET DST) Received: from nokia.com ([10.162.14.12]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 May 2004 10:10:02 +0300 Message-ID: <40A07C49.7090608@nokia.com> Date: Tue, 11 May 2004 10:10:01 +0300 From: Miguel Garcia 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, es-es MIME-Version: 1.0 To: SIPPING mailing list CC: Gonzalo Camarillo Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 May 2004 07:10:02.0709 (UTC) FILETIME=[FAAC3050:01C43726] Content-Transfer-Encoding: 7bit Subject: [Sipping] MESSAGE exploder draft Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 have just submitted a new version of the MESSAGE exploder draft, now targetting the SIPPING WG rather than SIMPLE. This version has got comments we got in the mailing list discussion. Changes from the previous version (draft-garcia-simple-message-exploder-00.txt): The MESSAGE exploder may or may not copy the URI list body to the outgoing MESSAGE request. This allows to extend the mechanism with a Reply-to-all feature. It is clarified that the MESSAGE exploder must not include a list in the outgoing MESSAGE requests. This avoids loops or requires a MESSAGE exploder functionality in the next hop. The MESSAGE exploder must remove the multipart/mixed wrapper if there is only one body left in the outgoing MESSAGE request. The document will be (hopefully) available soon in the I-D repository. In the meantime, you can download a copy from: http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-message-exploder-00.txt http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-message-exploder-00.html Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 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 Wed May 12 03:03:56 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11893 for ; Wed, 12 May 2004 03:03:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNniD-0001Uj-O6 for sipping-archive@odin.ietf.org; Wed, 12 May 2004 02:59:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C6xTub005742 for sipping-archive@odin.ietf.org; Wed, 12 May 2004 02:59:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnae-0007iP-E3 for sipping-web-archive@optimus.ietf.org; Wed, 12 May 2004 02:51:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10986 for ; Wed, 12 May 2004 02:51:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNnaa-0007B5-Kw for sipping-web-archive@ietf.org; Wed, 12 May 2004 02:51:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNnZk-0006kA-00 for sipping-web-archive@ietf.org; Wed, 12 May 2004 02:50:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNnYx-0006Jw-00 for sipping-web-archive@ietf.org; Wed, 12 May 2004 02:49:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnLf-0003a1-DU; Wed, 12 May 2004 02:36:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnEw-0001LC-Cd for sipping@optimus.ietf.org; Wed, 12 May 2004 02:29:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28605 for ; Wed, 12 May 2004 02:29:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNnEs-00042d-60 for sipping@ietf.org; Wed, 12 May 2004 02:29:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNnDt-0003Wb-00 for sipping@ietf.org; Wed, 12 May 2004 02:28:10 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BNnCp-00031D-00 for sipping@ietf.org; Wed, 12 May 2004 02:27:03 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4C6Qqus029397; Wed, 12 May 2004 02:26:53 -0400 (EDT) Message-ID: <40A1C38D.7050107@dynamicsoft.com> Date: Wed, 12 May 2004 02:26:21 -0400 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: De Leo Walter CC: sipping@ietf.org, Veiga Jorge Subject: Re: [Sipping] Service Discovery Mechanism using 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 SIP isn't in the business of service discovery. The service location protocol (SLP), RFC 2608, is an ietf protocol for this function. There are also many proprietary protocols. -Jonathan R. De Leo Walter wrote: > Is there some work or plan to define a Service Discovery mechanismo > using SIP? > > I elaborate: > > Suppose there is some AS providing a set of services. Is there a > mechanism for: > > a) The AS publicize the services it provides. > b) The UA access to a list of AS providing the service its user need. > > I find it very like a Presence Service but where the resource is not a > user but a Service. > That is a Service "Presence" Server would maintain a list of Service-AS > presence status to which a user could subscribe. > > Is any work in this line of thought or interest in developing that > mechanism? > > Or is there some other approach for this task? > > Regards. > > > ______________________________________________________ > > Walter D. De Leo > > Defensa 390 Piso 1 (C1065AAF) Buenos Aires. Argentina > > Tel: 54 11 4332-5027 Fax: 54 11 4303-5586 Int 2302 > email: _deleow@telefonica.com.ar_ > > -- 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 May 12 09:01:09 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29536 for ; Wed, 12 May 2004 09:01:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNtCX-00025Q-DJ for sipping-archive@odin.ietf.org; Wed, 12 May 2004 08:51:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CCp9x2008018 for sipping-archive@odin.ietf.org; Wed, 12 May 2004 08:51:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNt6d-0000rx-NQ for sipping-web-archive@optimus.ietf.org; Wed, 12 May 2004 08:45:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28647 for ; Wed, 12 May 2004 08:45:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNt6c-0000HP-D2 for sipping-web-archive@ietf.org; Wed, 12 May 2004 08:45:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNt5g-0007Z4-00 for sipping-web-archive@ietf.org; Wed, 12 May 2004 08:44:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNt4h-00072g-00 for sipping-web-archive@ietf.org; Wed, 12 May 2004 08:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNsxu-0007IE-5F; Wed, 12 May 2004 08:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNsvs-0006w1-PE for sipping@optimus.ietf.org; Wed, 12 May 2004 08:33:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28048 for ; Wed, 12 May 2004 08:33:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNsvr-0001qF-Iw for sipping@ietf.org; Wed, 12 May 2004 08:33:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNsuD-0000o7-00 for sipping@ietf.org; Wed, 12 May 2004 08:32:14 -0400 Received: from smtp6.clb.oleane.net ([213.56.31.26]) by ietf-mx with esmtp (Exim 4.12) id 1BNstP-0000Ed-00 for sipping@ietf.org; Wed, 12 May 2004 08:31:23 -0400 Received: from Pavillonquatre ([194.206.151.59]) by smtp6.clb.oleane.net with ESMTP id i4CCUqua015501 for ; Wed, 12 May 2004 14:30:52 +0200 Message-Id: <200405121230.i4CCUqua015501@smtp6.clb.oleane.net> From: "Peter" To: Date: Wed, 12 May 2004 14:30:43 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01C4382D.B5361240" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQ4HPE67KehW0ZESfK7kNfA0HiZAQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: [Sipping] International SIP 2005 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_UNKNOWN,HTML_MESSAGE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_003E_01C4382D.B5361240 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit International SIP 2005 will take place in Paris on January 25 to 28. Upper Side is expecting more than 400 delegates. The conference will be jointly organized with TVoDSL 05, another worldwide success. Therefore, the SIP conference will represent the VoIP side of this Triple Play event. In all, Upper side expects more than 800 participants. The call for proposals dead line has been extended to June 11. Please get all details at: http://www.upperside.fr/intersip05/sip2005cfp.htm ------=_NextPart_000_003E_01C4382D.B5361240 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

International SIP = 2005 will take place in Paris on January 25 to 28. Upper Side is expecting more than 400 = delegates.
The conference will be jointly = organized with TVoDSL 05, another worldwide success. Therefore, = the SIP conference will represent the VoIP side of this Triple Play event. In all, Upper side expects more than 800 = participants.

 

The call for proposals dead line has been = extended to June 11.

Please get all details = at:

http://www.upperside.fr/intersip05/sip2005cfp.htm=

 

------=_NextPart_000_003E_01C4382D.B5361240-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 12 11:32:25 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17731 for ; Wed, 12 May 2004 11:32:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvOZ-00034n-85 for sipping-archive@odin.ietf.org; Wed, 12 May 2004 11:11:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CFBhVw011823 for sipping-archive@odin.ietf.org; Wed, 12 May 2004 11:11:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNugi-0001TW-OK for sipping-web-archive@optimus.ietf.org; Wed, 12 May 2004 10:26:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08772 for ; Wed, 12 May 2004 10:26:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNugg-0006bE-E9 for sipping-web-archive@ietf.org; Wed, 12 May 2004 10:26:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNuSU-0005MU-00 for sipping-web-archive@ietf.org; Wed, 12 May 2004 10:11:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNuQP-0004Fz-00 for sipping-web-archive@ietf.org; Wed, 12 May 2004 10:09:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNuEI-0001qu-0B; Wed, 12 May 2004 09:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNtrO-0002Lt-RB for sipping@optimus.ietf.org; Wed, 12 May 2004 09:33:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02013 for ; Wed, 12 May 2004 09:33:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNtrN-0002QR-3M for sipping@ietf.org; Wed, 12 May 2004 09:33:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNtqU-0001um-00 for sipping@ietf.org; Wed, 12 May 2004 09:32:27 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1BNtpb-0001Nn-00 for sipping@ietf.org; Wed, 12 May 2004 09:31:31 -0400 Received: from disco.cs.columbia.edu (disco.cs.columbia.edu [128.59.16.7]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i4CDVO1r012044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 May 2004 09:31:26 -0400 (EDT) Received: from disco.cs.columbia.edu (localhost [127.0.0.1]) by disco.cs.columbia.edu (8.12.10/8.12.6) with ESMTP id i4CDVOgO028518; Wed, 12 May 2004 09:31:24 -0400 (EDT) Received: from localhost (xiaotaow@localhost) by disco.cs.columbia.edu (8.12.10/8.12.10/Submit) with ESMTP id i4CDVIlx028514; Wed, 12 May 2004 09:31:23 -0400 (EDT) X-Authentication-Warning: disco.cs.columbia.edu: xiaotaow owned process doing -bs Date: Wed, 12 May 2004 09:31:18 -0400 (EDT) From: Xiaotao Wu cc: De Leo Walter , , Veiga Jorge Subject: Re: [Sipping] Service Discovery Mechanism using SIP In-Reply-To: <40A1C38D.7050107@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.11.100443 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='X_AUTH_WARNING 0, __IN_REP_TO 0, __HAS_MSGID 0, __SANE_MSGID 0, __MIME_VERSION 0, __CT_TEXT_PLAIN 0, __CT 0, MISSING_HEADERS 0.000, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, TO_MALFORMED 0.000, IN_REP_TO 0' Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 On Wed, 12 May 2004, Jonathan Rosenberg wrote: > SIP isn't in the business of service discovery. The service location > protocol (SLP), RFC 2608, is an ietf protocol for this function. There There are some SLP templates for SIP services. You may take a look at ftp://ftp.isi.edu/in-notes/iana/assignments/svrloc-templates/ sip.1.0.en sipproxy.1.0.en sipregistrar.1.0.en -Xiaotao > are also many proprietary protocols. > > -Jonathan R. > > De Leo Walter wrote: > > > Is there some work or plan to define a Service Discovery mechanismo > > using SIP? > > > > I elaborate: > > > > Suppose there is some AS providing a set of services. Is there a > > mechanism for: > > > > a) The AS publicize the services it provides. > > b) The UA access to a list of AS providing the service its user need. > > > > I find it very like a Presence Service but where the resource is not a > > user but a Service. > > That is a Service "Presence" Server would maintain a list of Service-AS > > presence status to which a user could subscribe. > > > > Is any work in this line of thought or interest in developing that > > mechanism? > > > > Or is there some other approach for this task? > > > > Regards. > > > > > > ______________________________________________________ > > > > Walter D. De Leo > > > > Defensa 390 Piso 1 (C1065AAF) Buenos Aires. Argentina > > > > Tel: 54 11 4332-5027 Fax: 54 11 4303-5586 Int 2302 > > email: _deleow@telefonica.com.ar_ > > > > > > -- > 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 May 12 16:27: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 QAA08929 for ; Wed, 12 May 2004 16:27:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzyy-0003Jw-5l for sipping-archive@odin.ietf.org; Wed, 12 May 2004 16:05:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CK5aQk012764 for sipping-archive@odin.ietf.org; Wed, 12 May 2004 16:05:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzwD-0002TN-Vc for sipping-web-archive@optimus.ietf.org; Wed, 12 May 2004 16:02:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07728 for ; Wed, 12 May 2004 16:02:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNzwC-0004JL-Ef for sipping-web-archive@ietf.org; Wed, 12 May 2004 16:02:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNzvC-0003mR-00 for sipping-web-archive@ietf.org; Wed, 12 May 2004 16:01:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNzu5-000368-00 for sipping-web-archive@ietf.org; Wed, 12 May 2004 16:00:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzms-00084C-EN; Wed, 12 May 2004 15:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzgz-0006Ru-1d for sipping@optimus.ietf.org; Wed, 12 May 2004 15:47:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02985 for ; Wed, 12 May 2004 14:57:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNyvV-0001rK-Ql for sipping@ietf.org; Wed, 12 May 2004 14:57:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNyuL-0001JX-00 for sipping@ietf.org; Wed, 12 May 2004 14:56:45 -0400 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 1BNytN-0000Lf-00 for sipping@ietf.org; Wed, 12 May 2004 14:55:45 -0400 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 i4CIt2Sw026057; Wed, 12 May 2004 11:55:13 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIK22494; Wed, 12 May 2004 14:55:02 -0400 (EDT) Message-ID: <40A27309.10809@cisco.com> Date: Wed, 12 May 2004 14:55:05 -0400 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: Rohan Mahy CC: "sipping (E-mail)" Subject: Re: [Sipping] interactivity caller preferences parameter -- for the dialog package References: <5D3BA2BA-A2B1-11D8-813A-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, There was lots of discussion on something like this long ago, and there were problems getting proper semantics nailed. What you have proposed here feels right to me. Paul Rohan Mahy wrote: > Hi Folks, > > Back in Korea, I presented a proposed solution to the dialog package > "hold" discussion which I never described on the list. It has been > several months now, but I would like to describe this proposal now. I am > extremely sorry and embarrassed that I have taken so long to send this out. > > The proposal is to add a new caller preferences parameter (these are > formally called "media feature parameters" in caller prefs). The > interactivity parameter indicates if a device is capable of responding > to media received during a session in an interactive manner and if > necessary terminating a session in which the UA is no longer interested > in participating. > > For example: > > - If you are in a session with an automaton that does not respond to > media nor run call timers (for example a simple recording service, or > the "time of day" service in Tokyo Japan), your peer is non-interactive > - If you are in a session with an IVR-style application or an > application with a media inactivity timeout, your peer is interactive. > - If you are in a session with a human user who just put you "on hold", > your peer is non-interactive. > - If you are in a active session with a human call center agent in most > call centers, your peer is interactive. > - If you are in a normal session with another human, you don't (and > can't) know if your peer is interactive or non-interactive. [This > property is quite normal for caller preferences and does not diminish > the usefulness of this parameter when you do know its value. For > example, it is unwise to assume that a peer is not an automata, just > because the automata parameter is not set; the automata/human status is > unknown.] > > What can you do with this information? (Note that in many cases > positive knowledge that a peer is non-interactive has a more immediate > effect than positive knowledge that a peer in interactive) > > - This information can be conveyed in the dialog package and used as > part of a shared-line implementation. For example, if a group of phones > have all subscribed to the dialog package for the same address of > record, they will receive notifications whenever the local contact > address changes in any of the dialogs for this address of record. > Implementations could use the non-interactive parameter on a phone or a > "parking lot" application as a way to indicate that a shared line is > "holding" or "parked". > > - This proposed property is also incredibly useful in conferencing > scenarios. A focus can include in the termination policy of an adhoc > conference, the interactivity status of the participants. For example, > if the only participants in a conference are non-interactive, an adhoc > conference is unlikely to be especially interesting (ex: a recording bot > and a human who placed the conference on-hold). > > I believe this satisfies all the requirements for indicating if a user > is on hold, but captures a more fundamental and generic > mechanism/primitive. I believe that also maintains the "maximum > orthogonality among attributes" property of most of the other caller > preferences media feature parameters. > > Please comment. > > 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 Thu May 13 14: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 OAA04385 for ; Thu, 13 May 2004 14:38:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOL16-0000gM-Q6 for sipping-archive@odin.ietf.org; Thu, 13 May 2004 14:33:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DIXCcb002623 for sipping-archive@odin.ietf.org; Thu, 13 May 2004 14:33:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOKpR-0003j1-Fu for sipping-web-archive@optimus.ietf.org; Thu, 13 May 2004 14:21:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02310 for ; Thu, 13 May 2004 14:21:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOKpP-00022Q-2B for sipping-web-archive@ietf.org; Thu, 13 May 2004 14:21:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOKmz-0000rd-00 for sipping-web-archive@ietf.org; Thu, 13 May 2004 14:18:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOKk0-00074y-00 for sipping-web-archive@ietf.org; Thu, 13 May 2004 14:15:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJzI-0005gG-QK; Thu, 13 May 2004 13:27:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJcQ-0005HR-JI for sipping@optimus.ietf.org; Thu, 13 May 2004 13:03:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23702; Thu, 13 May 2004 13:03:34 -0400 (EDT) Message-Id: <200405131703.NAA23702@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 13 May 2004 13:03:34 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-e2m-sec-reqs-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.5 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 End-to-middle Security for the Session Initiation Protocol (SIP) Author(s) : K. Ono, S. Tachimoto Filename : draft-ietf-sipping-e2m-sec-reqs-02.txt Pages : 17 Date : 2004-5-12 A SIP User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/ or headers from intermediaries except those that provide services based on its content. This situation requires a mechanism called 'end-to-middle security' to secure information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-e2m-sec-reqs-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-e2m-sec-reqs-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-e2m-sec-reqs-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-5-13131935.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-e2m-sec-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-e2m-sec-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-13131935.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 May 14 02:14:24 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28212 for ; Fri, 14 May 2004 02:14:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOVsy-0004ke-QC for sipping-archive@odin.ietf.org; Fri, 14 May 2004 02:09:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E69WVX018261 for sipping-archive@odin.ietf.org; Fri, 14 May 2004 02:09:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOVqN-00037D-3T for sipping-web-archive@optimus.ietf.org; Fri, 14 May 2004 02:06:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21718 for ; Fri, 14 May 2004 02:06:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOVqJ-0002Iw-MF for sipping-web-archive@ietf.org; Fri, 14 May 2004 02:06:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOVpR-0001mT-00 for sipping-web-archive@ietf.org; Fri, 14 May 2004 02:05:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOVok-0001FF-00 for sipping-web-archive@ietf.org; Fri, 14 May 2004 02:05:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOVjt-0007Ze-3L; Fri, 14 May 2004 02:00:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOVia-0007DL-3f for sipping@optimus.ietf.org; Fri, 14 May 2004 01:58:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14730 for ; Fri, 14 May 2004 01:58:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOViW-0005iV-Kk for sipping@ietf.org; Fri, 14 May 2004 01:58:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOVhZ-0005AI-00 for sipping@ietf.org; Fri, 14 May 2004 01:57:46 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BOVgb-00044j-00 for sipping@ietf.org; Fri, 14 May 2004 01:56:45 -0400 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4E5uPbo001313; Fri, 14 May 2004 01:56:26 -0400 (EDT) Message-ID: <40A45F66.3040807@dynamicsoft.com> Date: Fri, 14 May 2004 01:55:50 -0400 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 (E-mail)" Subject: Re: [Sipping] interactivity caller preferences parameter -- for the dialog package References: <5D3BA2BA-A2B1-11D8-813A-0003938AF740@cisco.com> In-Reply-To: <5D3BA2BA-A2B1-11D8-813A-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, The definition of this continues to feel vague to me, and in fact blends two statements which I think are different: 1. this is an automata that will never generate a BYE on its own, 2. this call has been placed on "hold" by a user, but media is still being received The first of these is a characteristic of the UA. It is not dynamic, doesnt change during a call, and is easy to determine whether its true or not. It only applies to automata. This is the parameter you had in mind for your first and second cases. I think this is a fine callee capability and I have no problem with it. I'm not sure its terribly useful, though. You're worried about cases where a UA brings an automata into a conference, and then the conference ends, but the automata remains, and since it never hangs up, the conference persists. Normally, the entity that brings in the automata should know to kick it out when the conference ends, so we're only talking about cases where the UA or user that brought in the automata leaves bfore the conference ends. I think this is mostly a corner case. That said, its a valid case, and so I am OK with this. For the second one, I recall asking at the meeting (thought perhaps I just thought it and didnt ask it) what the difference was between this and the sendonly or inactive SDP attribute, which we've traditionally used for call hold. The fact that I'm not receiving media any more is something that is easy to determine and define, and would by definition make me "non interactive" since I'm not receiving your media in order to make a decision. I think you are concerned about cases where an endpoint has put a call on hold, and has not bothered to disable reception of media. So, my question is, why do that? To answer my own question, the main case I can think of is actually nat traversal. If you stop receiving and sending media, you may end up causing timeouts in nat bindings in NATs. You need to keep packets flowing to keep those open for the whole duration of the call. As such, a fine solution is to use an alternative codec for "hold" periods, which causes low packet rates, but enough to keep the bindings open. A no-op RTP payload format has been proposed for this; comfort noise would also do. In such a case, you no longer can use the sendonly/inactive as an indicator of hold, either to your peer or in the dialog event package, of the call being "on hold", and in that case you would need a replacement to signal it. In such a case, its not clear to me that its actually a callee capability parameter. Those are meant to be more static in nature, and are defined as UA capabilities and characteristics. This is neither, its more like a state for a media stream, perhaps even closer to an indication of usage of a particular codec. Indeed, it would seem to me to be possible to be 'on hold' for some media streams and not others (for example, I still receive your video but not your audio), which would make this hard to do as a callee capabilitiy parameter. Indeed, my "interactivity" would be hard to define in such a case. Thanks, Jonathan R. Rohan Mahy wrote: > Hi Folks, > > Back in Korea, I presented a proposed solution to the dialog package > "hold" discussion which I never described on the list. It has been > several months now, but I would like to describe this proposal now. I am > extremely sorry and embarrassed that I have taken so long to send this out. > > The proposal is to add a new caller preferences parameter (these are > formally called "media feature parameters" in caller prefs). The > interactivity parameter indicates if a device is capable of responding > to media received during a session in an interactive manner and if > necessary terminating a session in which the UA is no longer interested > in participating. > > For example: > > - If you are in a session with an automaton that does not respond to > media nor run call timers (for example a simple recording service, or > the "time of day" service in Tokyo Japan), your peer is non-interactive > - If you are in a session with an IVR-style application or an > application with a media inactivity timeout, your peer is interactive. > - If you are in a session with a human user who just put you "on hold", > your peer is non-interactive. > - If you are in a active session with a human call center agent in most > call centers, your peer is interactive. > - If you are in a normal session with another human, you don't (and > can't) know if your peer is interactive or non-interactive. [This > property is quite normal for caller preferences and does not diminish > the usefulness of this parameter when you do know its value. For > example, it is unwise to assume that a peer is not an automata, just > because the automata parameter is not set; the automata/human status is > unknown.] > > What can you do with this information? (Note that in many cases > positive knowledge that a peer is non-interactive has a more immediate > effect than positive knowledge that a peer in interactive) > > - This information can be conveyed in the dialog package and used as > part of a shared-line implementation. For example, if a group of phones > have all subscribed to the dialog package for the same address of > record, they will receive notifications whenever the local contact > address changes in any of the dialogs for this address of record. > Implementations could use the non-interactive parameter on a phone or a > "parking lot" application as a way to indicate that a shared line is > "holding" or "parked". > > - This proposed property is also incredibly useful in conferencing > scenarios. A focus can include in the termination policy of an adhoc > conference, the interactivity status of the participants. For example, > if the only participants in a conference are non-interactive, an adhoc > conference is unlikely to be especially interesting (ex: a recording bot > and a human who placed the conference on-hold). > > I believe this satisfies all the requirements for indicating if a user > is on hold, but captures a more fundamental and generic > mechanism/primitive. I believe that also maintains the "maximum > orthogonality among attributes" property of most of the other caller > preferences media feature parameters. > > Please comment. > > 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 > -- 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 Fri May 14 09:12:01 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20003 for ; Fri, 14 May 2004 09:12:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOcPZ-0007Ga-8D for sipping-archive@odin.ietf.org; Fri, 14 May 2004 09:07:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ED7bbA027927 for sipping-archive@odin.ietf.org; Fri, 14 May 2004 09:07:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOcKE-0006EJ-HA for sipping-web-archive@optimus.ietf.org; Fri, 14 May 2004 09:02:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19504 for ; Fri, 14 May 2004 09:02:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOcKD-0007aD-0F for sipping-web-archive@ietf.org; Fri, 14 May 2004 09:02:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOcJI-000760-00 for sipping-web-archive@ietf.org; Fri, 14 May 2004 09:01:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOcIp-0006bi-00 for sipping-web-archive@ietf.org; Fri, 14 May 2004 09:00:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOcCP-0004h7-NG; Fri, 14 May 2004 08:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOc7i-0003g9-Lk for sipping@optimus.ietf.org; Fri, 14 May 2004 08:49:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18827 for ; Fri, 14 May 2004 08:49:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOc7h-00016S-7Q for sipping@ietf.org; Fri, 14 May 2004 08:49:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOc6i-0000aY-00 for sipping@ietf.org; Fri, 14 May 2004 08:48:09 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BOc5p-0007St-00 for sipping@ietf.org; Fri, 14 May 2004 08:47:13 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i4ECkeLc029956 for ; Fri, 14 May 2004 07:46:41 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.196]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQWLQF2J; Fri, 14 May 2004 07:46:15 -0500 Message-ID: <40A4BFB1.6060001@ericsson.com> Date: Fri, 14 May 2004 15:46:41 +0300 X-Sybari-Trust: 145938de 08d63d2e 09a997dd 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 Content-Transfer-Encoding: 7bit Subject: [Sipping] Exploders drafts Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 have just submitted the following draft. Until it appears in the archives, you can fetch it from: http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-exploders-03.txt It describes the exploders' requirements and a framework to meet them. The framework includes references to the following documents, which will be discussed in the interim as well: http://www.ietf.org/internet-drafts/draft-camarillo-sipping-uri-list-02.txt http://www.ietf.org/internet-drafts/draft-camarillo-sipping-adhoc-conferencing-00.txt http://www.ietf.org/internet-drafts/draft-camarillo-sipping-adhoc-simple-00.txt http://www.ietf.org/internet-drafts/draft-garcia-sipping-message-exploder-00.txt Best regards, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 15 15:35:16 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07835 for ; Sat, 15 May 2004 15:35:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP4qQ-0004SU-WF for sipping-archive@odin.ietf.org; Sat, 15 May 2004 15:29:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4FJTEBo017138 for sipping-archive@odin.ietf.org; Sat, 15 May 2004 15:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP4nV-00040D-PA for sipping-web-archive@optimus.ietf.org; Sat, 15 May 2004 15:26:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07421 for ; Sat, 15 May 2004 15:26:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP4nU-00056v-8D for sipping-web-archive@ietf.org; Sat, 15 May 2004 15:26:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP4mW-0004hb-00 for sipping-web-archive@ietf.org; Sat, 15 May 2004 15:25:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BP4lW-0004IC-00 for sipping-web-archive@ietf.org; Sat, 15 May 2004 15:24:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP4bh-0000du-4W; Sat, 15 May 2004 15:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP4Z7-0008J3-OS for sipping@optimus.ietf.org; Sat, 15 May 2004 15:11:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06198 for ; Sat, 15 May 2004 15:11:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP4Z4-0006d3-LV for sipping@ietf.org; Sat, 15 May 2004 15:11:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP4YF-0006El-00 for sipping@ietf.org; Sat, 15 May 2004 15:10:28 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BP4XT-0005kK-00 for sipping@ietf.org; Sat, 15 May 2004 15:09:39 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 15 May 2004 12:08:33 -0700 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 i4FJ96Su026187; Sat, 15 May 2004 12:09:07 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATF29932; Sat, 15 May 2004 12:08:13 -0700 (PDT) In-Reply-To: <40A45F66.3040807@dynamicsoft.com> References: <5D3BA2BA-A2B1-11D8-813A-0003938AF740@cisco.com> <40A45F66.3040807@dynamicsoft.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "sipping (E-mail)" , Rohan Mahy From: Rohan Mahy Subject: Re: [Sipping] interactivity caller preferences parameter -- for the dialog package Date: Sat, 15 May 2004 08:59:04 -1000 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.613) 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 May 13, 2004, at 7:55 PM, Jonathan Rosenberg wrote: > Rohan, > > The definition of this continues to feel vague to me, and in fact > blends two statements which I think are different: > > 1. this is an automata that will never generate a BYE on its own, > 2. this call has been placed on "hold" by a user, but media is still > being received > > The first of these is a characteristic of the UA. It is not dynamic, > doesnt change during a call, and is easy to determine whether its true > or not. It only applies to automata. First of all the assertion that this characteristic can't/doesn't change during a call is false. If I have a call center IVR which then plays hold music, the interactivity status changes mid-call. This is a very common application. Likewise most dial-in conference services have this property. Second, I described the distinction between the interactivity status being unknown and being set to a specific value, and provided examples with humans where the value could be unknown (most calls), interactive (live call center agent), or non-interactive (on-hold). > This is the parameter you had in mind for your first and second cases. > I think this is a fine callee capability and I have no problem with > it. I'm not sure its terribly useful, though. You're worried about > cases where a UA brings an automata into a conference, and then the > conference ends, but the automata remains, and since it never hangs > up, the conference persists. Normally, the entity that brings in the > automata should know to kick it out when the conference ends, so we're > only talking about cases where the UA or user that brought in the > automata leaves bfore the conference ends. I think this is mostly a > corner case. That said, its a valid case, and so I am OK with this. > > For the second one, I recall asking at the meeting (thought perhaps I > just thought it and didnt ask it) what the difference was between this > and the sendonly or inactive SDP attribute, which we've traditionally > used for call hold. The fact that I'm not receiving media any more is > something that is easy to determine and define, and would by > definition make me "non interactive" since I'm not receiving your > media in order to make a decision. certainly knowing that all media are inactive or sendonly is a good hint that your peer is non-interactive. However, there are a number of pitfalls associated with this line of reasoning: - many 3pcc and offer/answer/counter-offer/counter-answer scenarios set all media to inactive until they know their ports. however the peer is typically not "non-interactive" at this point. - this indicator exists per media type, and is embedded in the SDP. An arbitrary peer subscribing to the dialog package would need to request session descriptions that they are unlikely to need otherwise. in addition, since the session description itself may contains keys, private IP addresses, and other sensitive information, the subscriber might not be authorized to receive it. - to prevent media clipping and to facilitate NAT and FW traversal some UAs don't signal sendonly or inactive. - it is not unreasonable for me to have a software UA on my PC with a built-in recording function. On such a UA, I can continue to record the conference I am in, while I receive or place another call. My UA is not strictly an automaton (because both human and automaton use this UA). However it is very clear that my status is non-interactive while taking the other call, and reverts to unknown when I return. My UA still needs to receive media while I am taking the other call to continue recording. > I think you are concerned about cases where an endpoint has put a call > on hold, and has not bothered to disable reception of media. So, my > question is, why do that? to prevent media clipping among other things. > To answer my own question, the main case I can think of is actually > nat traversal. If you stop receiving and sending media, you may end up > causing timeouts in nat bindings in NATs. You need to keep packets > flowing to keep those open for the whole duration of the call. As > such, a fine solution is to use an alternative codec for "hold" > periods, which causes low packet rates, but enough to keep the > bindings open. A no-op RTP payload format has been proposed for this; > comfort noise would also do. > > In such a case, you no longer can use the sendonly/inactive as an > indicator of hold, either to your peer or in the dialog event package, > of the call being "on hold", and in that case you would need a > replacement to signal it. Yes. > In such a case, its not clear to me that its actually a callee > capability parameter. Those are meant to be more static in nature, and > are defined as UA capabilities and characteristics. But other callee capabilities change during a call as well. For example, the SIP conferencing framework describes adding the ;isfocus parameter dynamically. > This is neither, its more like a state for a media stream, perhaps > even closer to an indication of usage of a particular codec. Indeed, > it would seem to me to be possible to be 'on hold' for some media > streams and not others (for example, I still receive your video but > not your audio), which would make this hard to do as a callee > capabilitiy parameter. Indeed, my "interactivity" would be hard to > define in such a case. I disagree. The definition I used for the interactivity parameter would effectively require all the interesting media in a session to be inactive in the hold case to qualify as positively "non-interactive". The UA gets to decide what constitutes "interesting". The key benefit here in the context of the dialog package and conferencing is that the UA gets to assert its intent explicitly. We don't descend the slippery slope of individual subscribers of the dialog package subscribing to session descriptions (that they might not be authorized to see) and implicitly interpreting the results. I summary, I believe that the approach I described technically works, causes no harm, has a number of benefits, and is consistent with other callee caps parameters (especially ;isfocus). thanks, -rohan > > Thanks, > Jonathan R. > > > > Rohan Mahy wrote: > >> Hi Folks, >> Back in Korea, I presented a proposed solution to the dialog package >> "hold" discussion which I never described on the list. It has been >> several months now, but I would like to describe this proposal now. I >> am extremely sorry and embarrassed that I have taken so long to send >> this out. >> The proposal is to add a new caller preferences parameter (these are >> formally called "media feature parameters" in caller prefs). The >> interactivity parameter indicates if a device is capable of >> responding to media received during a session in an interactive >> manner and if necessary terminating a session in which the UA is no >> longer interested in participating. >> For example: >> - If you are in a session with an automaton that does not respond to >> media nor run call timers (for example a simple recording service, or >> the "time of day" service in Tokyo Japan), your peer is >> non-interactive >> - If you are in a session with an IVR-style application or an >> application with a media inactivity timeout, your peer is >> interactive. >> - If you are in a session with a human user who just put you "on >> hold", your peer is non-interactive. >> - If you are in a active session with a human call center agent in >> most call centers, your peer is interactive. >> - If you are in a normal session with another human, you don't (and >> can't) know if your peer is interactive or non-interactive. [This >> property is quite normal for caller preferences and does not diminish >> the usefulness of this parameter when you do know its value. For >> example, it is unwise to assume that a peer is not an automata, just >> because the automata parameter is not set; the automata/human status >> is unknown.] >> What can you do with this information? (Note that in many cases >> positive knowledge that a peer is non-interactive has a more >> immediate effect than positive knowledge that a peer in interactive) >> - This information can be conveyed in the dialog package and used as >> part of a shared-line implementation. For example, if a group of >> phones have all subscribed to the dialog package for the same address >> of record, they will receive notifications whenever the local contact >> address changes in any of the dialogs for this address of record. >> Implementations could use the non-interactive parameter on a phone or >> a "parking lot" application as a way to indicate that a shared line >> is "holding" or "parked". >> - This proposed property is also incredibly useful in conferencing >> scenarios. A focus can include in the termination policy of an adhoc >> conference, the interactivity status of the participants. For >> example, if the only participants in a conference are >> non-interactive, an adhoc conference is unlikely to be especially >> interesting (ex: a recording bot and a human who placed the >> conference on-hold). >> I believe this satisfies all the requirements for indicating if a >> user is on hold, but captures a more fundamental and generic >> mechanism/primitive. I believe that also maintains the "maximum >> orthogonality among attributes" property of most of the other caller >> preferences media feature parameters. >> Please comment. >> 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 > > -- > 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 May 17 09:20: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 JAA20999 for ; Mon, 17 May 2004 09:20:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPi0h-0003eJ-8s for sipping-archive@odin.ietf.org; Mon, 17 May 2004 09:18:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HDIRrJ014025 for sipping-archive@odin.ietf.org; Mon, 17 May 2004 09:18:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhsm-0002db-9j for sipping-web-archive@optimus.ietf.org; Mon, 17 May 2004 09:10:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20558 for ; Mon, 17 May 2004 09:10:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPhsk-0001qV-JZ for sipping-web-archive@ietf.org; Mon, 17 May 2004 09:10:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPhrZ-0001SE-00 for sipping-web-archive@ietf.org; Mon, 17 May 2004 09:09:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPhqU-000137-00 for sipping-web-archive@ietf.org; Mon, 17 May 2004 09:07:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhht-0000wD-2S; Mon, 17 May 2004 08:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhdw-0000Rd-QB for sipping@optimus.ietf.org; Mon, 17 May 2004 08:54:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19793 for ; Mon, 17 May 2004 08:54:54 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPhdv-0004bl-CT for sipping@ietf.org; Mon, 17 May 2004 08:54:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPhd0-0004J5-00 for sipping@ietf.org; Mon, 17 May 2004 08:53:59 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BPhc9-00040V-00 for sipping@ietf.org; Mon, 17 May 2004 08:53:06 -0400 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 i4HCque14468; Mon, 17 May 2004 15:52:56 +0300 (EET DST) X-Scanned: Mon, 17 May 2004 15:51:52 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4HCpqQp014897; Mon, 17 May 2004 15:51:52 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 004gzAXs; Mon, 17 May 2004 15:51:52 EEST 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 i4HCpZH14433; Mon, 17 May 2004 15:51:35 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 May 2004 15:51:24 +0300 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] Poll: Consensus on adoption of the URI-list work Date: Mon, 17 May 2004 15:51:24 +0300 Message-ID: Thread-Topic: [Sipping] Poll: Consensus on adoption of the URI-list work Thread-Index: AcQyBg1HBMyXG0avSU2blmadC9+laAKBv9Ig To: , Cc: , , X-OriginalArrivalTime: 17 May 2004 12:51:24.0433 (UTC) FILETIME=[A935C010:01C43C0D] 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, Has there been a resolution for this or for the other poll about MESSAGE = exploder? There were a few persons in favour (it seems you never get = much more activity on these lists), and I did not see anyone objecting, = so I guess this should be clear? At least to me it seems that people = working on this have done a lot of work with quite rapid progress, so I = don't think there is a risk that this would be one of those = almost-never-finishing activities that SIP/SIPPING/SIMPLE are quite full = of. Markus > -----Original Message----- > From: sipping-admin@ietf.org=20 > [mailto:sipping-admin@ietf.org]On Behalf Of > ext Dean Willis > Sent: 04 May, 2004 21:14 > To: sipping@ietf.org > Cc: Gonzalo Camarillo; Rohan Mahy; Allison Mankin > Subject: [Sipping] Poll: Consensus on adoption of the URI-list work >=20 >=20 >=20 > See: draft-camarillo-sipping-uri-list-02.txt >=20 > It seems that the URI-list stuff is becoming important for its use in=20 > ad-hoc list requests. I've heard of several other groups that are=20 > referring to it in their specifications, and wish for us to=20 > conclude on=20 > the specification ASAP. >=20 > The current draft is fairly mature, and we seem to have a=20 > constituency=20 > for the specification. >=20 > Consequently, I'd like to suggest that the SIPPING group consider=20 > adopting this draft as a working group effort, targeted for=20 > informational RFC, with an estimated delivery date to IESG of=20 > June, 2004. >=20 > Please respond, aye or nay, if you care. The chairs will, as usual,=20 > judge consensus and report the recommendation (for or=20 > against) to the AD=20 > for consideration. >=20 > Thanks, >=20 > -- > Dean Willis > SIPPING co-chair >=20 >=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 >=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 May 17 12:00: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 MAA00822 for ; Mon, 17 May 2004 12:00:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkTB-0007hp-Qd for sipping-archive@odin.ietf.org; Mon, 17 May 2004 11:56:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HFu1wh029615 for sipping-archive@odin.ietf.org; Mon, 17 May 2004 11:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkNa-0006h0-L6 for sipping-web-archive@optimus.ietf.org; Mon, 17 May 2004 11:50:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00072 for ; Mon, 17 May 2004 11:50:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPkNZ-0000Kw-8G for sipping-web-archive@ietf.org; Mon, 17 May 2004 11:50:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPkMY-0007nO-00 for sipping-web-archive@ietf.org; Mon, 17 May 2004 11:49:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPkLd-0007TA-00 for sipping-web-archive@ietf.org; Mon, 17 May 2004 11:48:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkCl-0005TZ-Ar; Mon, 17 May 2004 11:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPk1M-0003Se-VT for sipping@optimus.ietf.org; Mon, 17 May 2004 11:27:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28313 for ; Mon, 17 May 2004 11:27:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPk1M-0000CI-1S for sipping@ietf.org; Mon, 17 May 2004 11:27:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPk0R-0007fG-00 for sipping@ietf.org; Mon, 17 May 2004 11:26:20 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BPjzu-0007KN-00 for sipping@ietf.org; Mon, 17 May 2004 11:25:46 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i4HFOnLc017687; Mon, 17 May 2004 10:24:49 -0500 (CDT) Received: from ericsson.com (rvi2-92-229.sw.ericsson.se [153.88.92.229]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQWL4Q0P; Mon, 17 May 2004 10:24:19 -0500 Message-ID: <40A8D93F.3060600@ericsson.com> Date: Mon, 17 May 2004 18:24:47 +0300 X-Sybari-Trust: bbef1b7b 08d63d2e 09a997dd 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: Markus.Isomaki@nokia.com CC: dean.willis@softarmor.com, sipping@ietf.org, rohan@cisco.com, mankin@psg.com Subject: Re: [Sipping] Poll: Consensus on adoption of the URI-list work 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 Hi, as an individual, I also believe that this work has raised enough interest and that the technical solution is quite estable at this point. So, I would support making those documents WG items. In addition, I would like to see discussions on the only important open issue we have: security. The security considerations section of the requirements and framework for SIP exploders talks about the security implications of this work. It would be great if the community, including chairs and ADs, had a look at it and express their opinions. Thanks, Gonzalo Markus.Isomaki@nokia.com wrote: > Hi, > > Has there been a resolution for this or for the other poll about MESSAGE exploder? There were a few persons in favour (it seems you never get much more activity on these lists), and I did not see anyone objecting, so I guess this should be clear? At least to me it seems that people working on this have done a lot of work with quite rapid progress, so I don't think there is a risk that this would be one of those almost-never-finishing activities that SIP/SIPPING/SIMPLE are quite full of. > > Markus > > >>-----Original Message----- >>From: sipping-admin@ietf.org >>[mailto:sipping-admin@ietf.org]On Behalf Of >>ext Dean Willis >>Sent: 04 May, 2004 21:14 >>To: sipping@ietf.org >>Cc: Gonzalo Camarillo; Rohan Mahy; Allison Mankin >>Subject: [Sipping] Poll: Consensus on adoption of the URI-list work >> >> >> >>See: draft-camarillo-sipping-uri-list-02.txt >> >>It seems that the URI-list stuff is becoming important for its use in >>ad-hoc list requests. I've heard of several other groups that are >>referring to it in their specifications, and wish for us to >>conclude on >>the specification ASAP. >> >>The current draft is fairly mature, and we seem to have a >>constituency >>for the specification. >> >>Consequently, I'd like to suggest that the SIPPING group consider >>adopting this draft as a working group effort, targeted for >>informational RFC, with an estimated delivery date to IESG of >>June, 2004. >> >>Please respond, aye or nay, if you care. The chairs will, as usual, >>judge consensus and report the recommendation (for or >>against) to the AD >>for consideration. >> >>Thanks, >> >>-- >>Dean Willis >>SIPPING co-chair >> >> >> >> >> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the 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 May 17 13:03:13 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05263 for ; Mon, 17 May 2004 13:03:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlGg-0001ND-4L for sipping-archive@odin.ietf.org; Mon, 17 May 2004 12:47:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HGlA1Q005274 for sipping-archive@odin.ietf.org; Mon, 17 May 2004 12:47:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPl7Q-0007tw-3G for sipping-web-archive@optimus.ietf.org; Mon, 17 May 2004 12:37:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03697 for ; Mon, 17 May 2004 12:37:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPl7O-0001V9-Hw for sipping-web-archive@ietf.org; Mon, 17 May 2004 12:37:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPl6D-00018M-00 for sipping-web-archive@ietf.org; Mon, 17 May 2004 12:36:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPl5F-0000nH-00 for sipping-web-archive@ietf.org; Mon, 17 May 2004 12:35:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPky9-0006C6-QZ; Mon, 17 May 2004 12:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkjK-0002Jt-CC for sipping@optimus.ietf.org; Mon, 17 May 2004 12:12:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01682 for ; Mon, 17 May 2004 12:12:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPkjJ-0000EU-12 for sipping@ietf.org; Mon, 17 May 2004 12:12:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPki7-0007dU-00 for sipping@ietf.org; Mon, 17 May 2004 12:11:28 -0400 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 1BPkhF-0007DJ-00 for sipping@ietf.org; Mon, 17 May 2004 12:10:33 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 May 2004 08:15:27 +0000 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 i4HG9vSw010536; Mon, 17 May 2004 09:09:59 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIN29850; Mon, 17 May 2004 12:09:56 -0400 (EDT) Message-ID: <40A8E3DA.20002@cisco.com> Date: Mon, 17 May 2004 12:10:02 -0400 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: Markus.Isomaki@nokia.com, dean.willis@softarmor.com, sipping@ietf.org, rohan@cisco.com, mankin@psg.com Subject: Re: [Sipping] Poll: Consensus on adoption of the URI-list work References: <40A8D93F.3060600@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: > Hi, > > as an individual, I also believe that this work has raised enough > interest and that the technical solution is quite estable at this point. > So, I would support making those documents WG items. I agree with making this a WG item. > In addition, I would like to see discussions on the only important open > issue we have: security. The security considerations section of the > requirements and framework for SIP exploders talks about the security > implications of this work. It would be great if the community, including > chairs and ADs, had a look at it and express their opinions. I don't agree this is the only issue we have. I think how the list is specified is still an issue. Use of a uri parameter is still potentially a problem. (See the ongoing discussion on uri parameters and proxy translation of the request uri.) But these are solvable issues, and I think it is clear that as a group we need this capability. 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 May 17 16:38: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 QAA24505 for ; Mon, 17 May 2004 16:38:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPoEA-0002V8-Lk for sipping-archive@odin.ietf.org; Mon, 17 May 2004 15:56:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HJukAY009614 for sipping-archive@odin.ietf.org; Mon, 17 May 2004 15:56:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnzK-0004Je-Ng for sipping-web-archive@optimus.ietf.org; Mon, 17 May 2004 15:41:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18977 for ; Mon, 17 May 2004 15:41:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPnzJ-000598-BV for sipping-web-archive@ietf.org; Mon, 17 May 2004 15:41:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPnyP-0004ow-00 for sipping-web-archive@ietf.org; Mon, 17 May 2004 15:40:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPnxT-0004UP-00 for sipping-web-archive@ietf.org; Mon, 17 May 2004 15:39:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnax-0005pl-Gz; Mon, 17 May 2004 15:16:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnEL-0005Pw-3Z for sipping@optimus.ietf.org; Mon, 17 May 2004 14:52:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14324 for ; Mon, 17 May 2004 14:52:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPnEI-00037t-BG for sipping@ietf.org; Mon, 17 May 2004 14:52:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPnCy-0002iL-00 for sipping@ietf.org; Mon, 17 May 2004 14:51:29 -0400 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1BPnCR-0002M6-00 for sipping@ietf.org; Mon, 17 May 2004 14:50:55 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4HInL120768; Mon, 17 May 2004 11:49:22 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 May 2004 11:49:22 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2101E854B@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Jonathan Rosenberg'" , "'Rohan Mahy'" Cc: "'sipping (E-mail)'" Subject: RE: [Sipping] interactivity caller preferences parameter -- for t he dialog package Date: Mon, 17 May 2004 11:49:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43C3F.A911EA0A" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_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_01C43C3F.A911EA0A Content-Type: text/plain Jonathan, The "interactivity" is not the same thing as the sendonly/inactive SDP. First, the application that needs to know the interactivity status of a UA may not have access to the SDP information (S/MIME, etc.). Second, it is not related to the presence of media or not. A user may be "on-hold" at a Call Center, being fed music or an announcement. A Call Center application may subscribe to an Agent interactivity status (I personally think a "non-interactivity" status makes more sense). The Call Center application may be required to monitor the amount of time a customer spends on hold, and take action accordingly. Evaluate the service provided by the agents, re-route calls dynamically, etc. I agree with Rohan that the interactivity status is on a per dialog basis, and NOT on a per individual media stream. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, May 13, 2004 22:56 > To: Rohan Mahy > Cc: sipping (E-mail) > Subject: Re: [Sipping] interactivity caller preferences > parameter -- for the dialog package > > For the second one, I recall asking at the meeting (thought perhaps I > just thought it and didnt ask it) what the difference was > between this > and the sendonly or inactive SDP attribute, which we've traditionally > used for call hold. The fact that I'm not receiving media any more is > something that is easy to determine and define, and would by > definition > make me "non interactive" since I'm not receiving your media > in order to > make a decision. I think you are concerned about cases where > an endpoint > has put a call on hold, and has not bothered to disable reception of > media. So, my question is, why do that? > > To answer my own question, the main case I can think of is > actually nat > traversal. If you stop receiving and sending media, you may end up > causing timeouts in nat bindings in NATs. You need to keep packets > flowing to keep those open for the whole duration of the > call. As such, > a fine solution is to use an alternative codec for "hold" > periods, which > causes low packet rates, but enough to keep the bindings > open. A no-op > RTP payload format has been proposed for this; comfort noise > would also do. > > In such a case, you no longer can use the sendonly/inactive as an > indicator of hold, either to your peer or in the dialog event > package, > of the call being "on hold", and in that case you would need a > replacement to signal it. > > In such a case, its not clear to me that its actually a callee > capability parameter. Those are meant to be more static in > nature, and > are defined as UA capabilities and characteristics. This is > neither, its > more like a state for a media stream, perhaps even closer to an > indication of usage of a particular codec. Indeed, it would > seem to me > to be possible to be 'on hold' for some media streams and not others > (for example, I still receive your video but not your audio), which > would make this hard to do as a callee capabilitiy parameter. > Indeed, my > "interactivity" would be hard to define in such a case. > > Thanks, > Jonathan R. ------_=_NextPart_001_01C43C3F.A911EA0A Content-Type: text/html RE: [Sipping] interactivity caller preferences parameter -- for the dialog package

Jonathan,

The "interactivity" is not the same thing as the sendonly/inactive SDP.

First, the application that needs to know the interactivity status of
a UA may not have access to the SDP information (S/MIME, etc.).

Second, it is not related to the presence of media or not. A
user may be "on-hold" at a Call Center, being fed music or an
announcement.

A Call Center application may subscribe to an Agent interactivity status
(I personally think a "non-interactivity" status makes more sense).

The Call Center application may be required to monitor the amount of time a
customer spends on hold, and take action accordingly. Evaluate the
service provided by the agents, re-route calls dynamically, etc.

I agree with Rohan that the interactivity status is on a per dialog
basis, and NOT on a per individual media stream.


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Thursday, May 13, 2004 22:56
> To: Rohan Mahy
> Cc: sipping (E-mail)
> Subject: Re: [Sipping] interactivity caller preferences
> parameter -- for the dialog package
>
> For the second one, I recall asking at the meeting (thought perhaps I
> just thought it and didnt ask it) what the difference was
> between this
> and the sendonly or inactive SDP attribute, which we've traditionally
> used for call hold. The fact that I'm not receiving media any more is
> something that is easy to determine and define, and would by
> definition
> make me "non interactive" since I'm not receiving your media
> in order to
> make a decision. I think you are concerned about cases where
> an endpoint
> has put a call on hold, and has not bothered to disable reception of
> media. So, my question is, why do that?
>
> To answer my own question, the main case I can think of is
> actually nat
> traversal. If you stop receiving and sending media, you may end up
> causing timeouts in nat bindings in NATs. You need to keep packets
> flowing to keep those open for the whole duration of the
> call. As such,
> a fine solution is to use an alternative codec for "hold"
> periods, which
> causes low packet rates, but enough to keep the bindings
> open. A no-op
> RTP payload format has been proposed for this; comfort noise
> would also do.
>
> In such a case, you no longer can use the sendonly/inactive as an
> indicator of hold, either to your peer or in the dialog event
> package,
> of the call being "on hold", and in that case you would need a
> replacement to signal it.
>
> In such a case, its not clear to me that its actually a callee
> capability parameter. Those are meant to be more static in
> nature, and
> are defined as UA capabilities and characteristics. This is
> neither, its
> more like a state for a media stream, perhaps even closer to an
> indication of usage of a particular codec. Indeed, it would
> seem to me
> to be possible to be 'on hold' for some media streams and not others
> (for example, I still receive your video but not your audio), which
> would make this hard to do as a callee capabilitiy parameter.
> Indeed, my
> "interactivity" would be hard to define in such a case.
>
> Thanks,
> Jonathan R.

------_=_NextPart_001_01C43C3F.A911EA0A-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 17 18:14:14 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07844 for ; Mon, 17 May 2004 18:14:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPq9O-000188-TV for sipping-archive@odin.ietf.org; Mon, 17 May 2004 17:59:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HLxwNu004344 for sipping-archive@odin.ietf.org; Mon, 17 May 2004 17:59:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpzU-0003Qn-5D for sipping-web-archive@optimus.ietf.org; Mon, 17 May 2004 17:49:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04244 for ; Mon, 17 May 2004 17:49:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPpzR-0007j6-KY for sipping-web-archive@ietf.org; Mon, 17 May 2004 17:49:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPpuR-0006KN-00 for sipping-web-archive@ietf.org; Mon, 17 May 2004 17:44:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPpp9-0004ud-00 for sipping-web-archive@ietf.org; Mon, 17 May 2004 17:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpUK-0003uh-Q3; Mon, 17 May 2004 17:17:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPofK-00050U-Iw for sipping@optimus.ietf.org; Mon, 17 May 2004 16:24:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22983 for ; Mon, 17 May 2004 16:24:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPofI-0005ok-Ky for sipping@ietf.org; Mon, 17 May 2004 16:24:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPodi-00055A-00 for sipping@ietf.org; Mon, 17 May 2004 16:23:11 -0400 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 1BPocW-0004WB-00; Mon, 17 May 2004 16:21:56 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 17 May 2004 12:26:54 +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 i4HKLOW9011162; Mon, 17 May 2004 13:21:24 -0700 (PDT) Received: from [128.107.170.98] ([128.107.170.98]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id APA11375; Mon, 17 May 2004 13:21:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Jon Peterson From: Cullen Jennings Date: Mon, 17 May 2004 13:21:22 -0700 To: sip@ietf.org, sipping@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Subject: [Sipping] New identity and certs draft Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 Jon and I have submitted new version of the Identity and Certs drafts. Until they show up in the repository, you can find them at: http://www.employees.org/~fluffy/ietf/draft-ietf-sip-identity-02.txt http://www.employees.org/~fluffy/ietf/draft-jennings-sipping-certs -03.txt These are significant updates from pervious versions. Thanks, 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 May 18 02:13:16 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15951 for ; Tue, 18 May 2004 02:13:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPxmk-0006Mw-IE for sipping-archive@odin.ietf.org; Tue, 18 May 2004 02:09:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I696E9024476 for sipping-archive@odin.ietf.org; Tue, 18 May 2004 02:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPxdr-00019l-UC for sipping-web-archive@optimus.ietf.org; Tue, 18 May 2004 01:59:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02700 for ; Tue, 18 May 2004 01:59:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPxdo-0000vi-L9 for sipping-web-archive@ietf.org; Tue, 18 May 2004 01:59:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPxcn-0000WA-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 01:58:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPxbo-00007j-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 01:57:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPxWD-0007g0-Cx; Tue, 18 May 2004 01:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPxRI-0006xi-Hs for sipping@optimus.ietf.org; Tue, 18 May 2004 01:46:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02269 for ; Tue, 18 May 2004 01:46:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPxRF-0003pN-9p for sipping@ietf.org; Tue, 18 May 2004 01:46:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPxQP-0003Rq-00 for sipping@ietf.org; Tue, 18 May 2004 01:46:01 -0400 Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx with esmtp (Exim 4.12) id 1BPxPc-00032T-00 for sipping@ietf.org; Tue, 18 May 2004 01:45:13 -0400 Received: from pingtel.com (h00d01e004cd0.ne.client2.attbi.com[66.30.203.15]) by comcast.net (rwcrmhc11) with SMTP id <2004051805444301300a32fee> (Authid: dgpetrie); Tue, 18 May 2004 05:44:43 +0000 Message-ID: <40A9A2C6.E5311B7C@pingtel.com> Date: Tue, 18 May 2004 01:44:38 -0400 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: sipping@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] draft-ietf-sipping-config-framework-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 This update has been submitted to the IETF secretariat. In the mean time before it is availble on the IETF web site, you can get a copy from: http://www.pingtel.com/docs/draft-ietf-sipping-config-framework-03.txt Abstract This document defines the application of a set of protocols for providing profile data to SIP user agents. The objective is to define a means for automatically providing profile data a user agent needs to be functional without user or administrative intervention. The framework for discovery, delivery, notification and updates of user agent profile data is defined here. As part of this framework a new SIP event package is defined here for the notification of profile changes. This framework is also intended to ease ongoing administration and upgrading of large scale deployments of SIP user agents. The contents and format of the profile data to be defined is outside the scope of 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 From exim@www1.ietf.org Tue May 18 02:32:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17778 for ; Tue, 18 May 2004 02:32:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPy35-0006ga-Qc for sipping-archive@odin.ietf.org; Tue, 18 May 2004 02:26:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I6PxdK025701 for sipping-archive@odin.ietf.org; Tue, 18 May 2004 02:25:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPy1C-0005YH-A1 for sipping-web-archive@optimus.ietf.org; Tue, 18 May 2004 02:24:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17225 for ; Tue, 18 May 2004 02:23:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPy18-0002SK-Ip for sipping-web-archive@ietf.org; Tue, 18 May 2004 02:23:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPy0E-000242-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 02:23:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPxzb-0001fn-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 02:22:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPxok-00078Q-4a; Tue, 18 May 2004 02:11:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPxiY-0003Oz-5n for sipping@optimus.ietf.org; Tue, 18 May 2004 02:04:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07740 for ; Tue, 18 May 2004 02:04:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPxiU-0002qb-Au for sipping@ietf.org; Tue, 18 May 2004 02:04:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPxhX-0002TY-00 for sipping@ietf.org; Tue, 18 May 2004 02:03:44 -0400 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 1BPxgd-0001kC-00 for sipping@ietf.org; Tue, 18 May 2004 02:02:47 -0400 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 i4I62GSu025104; Mon, 17 May 2004 23:02:16 -0700 (PDT) Received: from [10.0.1.3] (sjc-vpn3-479.cisco.com [10.21.65.223]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id APA55092; Mon, 17 May 2004 23:02:15 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 17 May 2004 23:00:25 -0700 Subject: Re: [Sipping] Exploders drafts From: Cullen Jennings To: , sipping Message-ID: In-Reply-To: <40A4BFB1.6060001@ericsson.com> 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: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 Few comments on these. On draft-camarillo-sipping-exploders-03.txt section 1 - para 2. This nicely points out the requirements for exploders - I like it. It does seem like a reasonable compression scheme would solve this requirement equally well. Other explained to me this does not work due to inadequacies in sigcomp but might be worth pointing this out. You might make an argument that a solution that took all the final exploded messages and sent them over an appropriately compressed link uses no more bandwidth on behalf of the sender than this and resulted in the same bandwidth usage on the receivers part and therefore the scheme proposed here was no worse a DOS attack problem than say compressed access links are. I imagine recommending logging as a solution for SPAM with exploders is going to, ah, raise some concerns about the desirability of this scheme. In the section on saying users must agree to receive stuff from an exploder, it would be nice to say that users must be able to easy revoke this. Having an explicit SIP mechanism for a user to grant permission to receive explosions, and more importantly, remove that permission grant, would make this better. It's interesting, in many ways the exploders is similar to publish but publish did not seem to have the same range of concerns about amplification, DOS, and message relay. Might want to figure out how to make it have the security properties more like publish. On draft-garcia-sipping-message-exploder-00.txt The embedded headers in the URI are nice but raise lots of issues. For example, if I insert a P-Asserted-Identity header with a fake name, will it be used? Or perhaps a Route header that caused the message to go to someone that had not agreed to receive exploded messages. The " The MESSAGE exploder MUST NOT copy any security body (such as an S/MIME signed body) addressed to the MESSAGE exploder to the outgoing MESSAGE request. This includes, e.g., security bodies signed with the public key of the exploder." This confuses me. If it was signed, it would be signed with the public key of the UA sending the request to the exploder? I'm just not sure what you are getting at with this. Is this the exploder must not relay any S/MIME body? In the security section - last paragraph. Not sure what you are proposing here. If I wanted to send an encrypted message to A and B, what would I do. I assume encrypt the List A,B with the public key of the exploder then provide a copy of the message that was encrypted with a content encryption key (call it the CEK) then encrypt the CEK with the public key of A and separately with B then bundle this all up somehow and send it. You mention integrity protection with S/MIME too - are you assuming that the exploder knows the public key of the UA sending the request? If the exploder has authenticated the sender, perhaps it should put the identity of the sender in the From of the messages it sends. This raises issues with trying to be Anonymous and user an exploder but perhaps this is a feature not a bug. I don't feel strongly about these drafts one way or another so I hope these comments get somewhat discounted as casual passer by - I know others have thought about it much more. Perhaps the amplification issue in this B2BUA based solution can be justified as no worse than the alternative solution to the problem using compression with a proxy. Cullen On 5/14/04 5:46 AM, "Gonzalo Camarillo" wrote: > Folks, > > I have just submitted the following draft. Until it appears in the > archives, you can fetch it from: > > http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-exploders > -03.txt > > It describes the exploders' requirements and a framework to meet them. > The framework includes references to the following documents, which will > be discussed in the interim as well: > > http://www.ietf.org/internet-drafts/draft-camarillo-sipping-uri-list-02.txt > http://www.ietf.org/internet-drafts/draft-camarillo-sipping-adhoc-conferencing > -00.txt > http://www.ietf.org/internet-drafts/draft-camarillo-sipping-adhoc-simple-00.tx> t > http://www.ietf.org/internet-drafts/draft-garcia-sipping-message-exploder-00.t > xt > > Best regards, > > Gonzalo > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 May 18 04:49:31 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25193 for ; Tue, 18 May 2004 04:49:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0FW-0007I4-5g for sipping-archive@odin.ietf.org; Tue, 18 May 2004 04:46:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I8kvNp028021 for sipping-archive@odin.ietf.org; Tue, 18 May 2004 04:46:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ06j-0005jE-RR for sipping-web-archive@optimus.ietf.org; Tue, 18 May 2004 04:37:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24551 for ; Tue, 18 May 2004 04:37:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ06g-0000i9-Vh for sipping-web-archive@ietf.org; Tue, 18 May 2004 04:37:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ05j-0000Jp-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 04:36:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ04i-0007it-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 04:35:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzz9-0003aa-IU; Tue, 18 May 2004 04:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzwB-0002qh-SZ for sipping@optimus.ietf.org; Tue, 18 May 2004 04:26:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23521 for ; Tue, 18 May 2004 04:26:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPzw9-00041Y-1f for sipping@ietf.org; Tue, 18 May 2004 04:26:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPzvB-0003dJ-00 for sipping@ietf.org; Tue, 18 May 2004 04:25:57 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1BPzuQ-000357-00 for sipping@ietf.org; Tue, 18 May 2004 04:25:10 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 52F4C37DDB for ; Tue, 18 May 2004 10:24:41 +0200 (CEST) Received: from [163.117.139.95] (cimborrio.it.uc3m.es [163.117.139.95]) by smtp01.uc3m.es (Postfix) with ESMTP id 39C8737CF4 for ; Tue, 18 May 2004 10:24:41 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: sipping@ietf.org Date: Tue, 18 May 2004 10:24:29 +0200 User-Agent: KMail/1.6 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200405181024.29768.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Subject: [Sipping] Question about the usage of REFER Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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, I wonder if you can send a REFER message to the correspondant node to make it refer to yourself. I think this could be useful to re-establish the connection when you change of location (IP address change). Does this makes sense ? Thanks. -- ****** JFRH ****** 3 syncs represent the trinity - init, the child and the eternal zombie process. In doing 3, you're paying homage to each and I think such traditions are important in this shallow, mercurial business we find ourselves in. -- Jordan K. Hubbard _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 18 08:17:58 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08395 for ; Tue, 18 May 2004 08:17:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3Mu-0006uR-SA for sipping-archive@odin.ietf.org; Tue, 18 May 2004 08:06:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IC6mCN026536 for sipping-archive@odin.ietf.org; Tue, 18 May 2004 08:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3LG-0006E6-A2 for sipping-web-archive@optimus.ietf.org; Tue, 18 May 2004 08:05:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07890 for ; Tue, 18 May 2004 08:05:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ3LF-0000ux-CL for sipping-web-archive@ietf.org; Tue, 18 May 2004 08:05:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ3KI-0000We-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 08:04:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ3JL-00008f-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 08:03:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ37g-0002CM-DJ; Tue, 18 May 2004 07:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ30z-0000fG-07 for sipping@optimus.ietf.org; Tue, 18 May 2004 07:44:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06921 for ; Tue, 18 May 2004 07:44:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ30y-0000pC-8Z for sipping@ietf.org; Tue, 18 May 2004 07:44:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ308-0000QN-00 for sipping@ietf.org; Tue, 18 May 2004 07:43:16 -0400 Received: from mxout3.netvision.net.il ([194.90.9.24]) by ietf-mx with esmtp (Exim 4.12) id 1BQ2z9-0007Pw-00; Tue, 18 May 2004 07:42:15 -0400 Received: from mailvision.com ([212.143.127.195]) by mxout3.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0HXW00G8PR5EPL@mxout3.netvision.net.il>; Tue, 18 May 2004 14:41:39 +0300 (IDT) Date: Tue, 18 May 2004 13:41:38 +0200 From: Diego B To: sip@ietf.org, sipping Cc: Cullen Jennings Message-id: <40A9F672.6090008@mailvision.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) Content-Transfer-Encoding: 7BIT Subject: [Sipping] SIP Forward, Who pays the bill ? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-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,ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi; My question is regarding billing a forwarded sip call. Lets take the exmple from draft-ietf-sipping-service-examples 2.7 Alice calls Bob, and Bob has all his incomming calls forwarded to the PSTN. Let say that calls from ALice to Bob in the same domain are free (same office, or same ITSP), but calls to the PSTN are not free. Who pays for Alice call to Bob ?? In a normal situacion, Alice knows that the call is for free becuase she is calling Bob's sip number. But the gateweay may create CDR from the From header of the SIP message and at the end of the month Alice may have to pay for the call. I see this kind of examples in several other drafts/RFC related to SIP services and call forward. I belive forward is a very important feature, but this issue may be resolved. The question is if it is a standard way to make Bob pays for the second leg of the call like in PSTN forward. Maybe changing the From header where applicable and adding a new one to "remember" that the call is from, in my example, Alice. The diversion header (Diversion Indication in SIP draft-levy-sip-diversion-07.txt)" may be a solution if the PSTN gateway or the SIP Billing server support it and knows that they have to bill the sip-uri in the diversion header ( this is right ??? ). Regards; -- Diego B MailVision Ltd. Tel. : +972-4-8500505 ext 13 e-mail: diegob@mailvision.com web : http://www.mailvision.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 May 18 09:23:33 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13262 for ; Tue, 18 May 2004 09:23:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4N7-0004Xr-Qq for sipping-archive@odin.ietf.org; Tue, 18 May 2004 09:11:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IDB5Yg017467 for sipping-archive@odin.ietf.org; Tue, 18 May 2004 09:11:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4Ap-0000cq-Ip for sipping-web-archive@optimus.ietf.org; Tue, 18 May 2004 08:58:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11619 for ; Tue, 18 May 2004 08:58:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ4Ao-00072U-9e for sipping-web-archive@ietf.org; Tue, 18 May 2004 08:58:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ49p-0006cl-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 08:57:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ490-0006E7-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 08:56:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3qF-00020D-3h; Tue, 18 May 2004 08:37:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3lz-0008Az-G8 for sipping@optimus.ietf.org; Tue, 18 May 2004 08:32:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09682 for ; Tue, 18 May 2004 08:32:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ3ly-00049t-AK for sipping@ietf.org; Tue, 18 May 2004 08:32:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ3km-0003fQ-00 for sipping@ietf.org; Tue, 18 May 2004 08:31:29 -0400 Received: from [207.164.160.106] (helo=PLUTO.LEAPSTONE.COM) by ietf-mx with esmtp (Exim 4.12) id 1BQ3jb-0002nY-00; Tue, 18 May 2004 08:30:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 May 2004 08:29:54 -0400 Message-ID: <74C307FA4137884EA234B26DE84C00340CD721@PLUTO.LEAPSTONE.COM> Thread-Topic: [Sip] SIP Forward, Who pays the bill ? Thread-Index: AcQ8z38nHoVSng0PTFaWEyGD1i20YwAA4++w From: "Fred Hasle" To: "Diego B" , , "sipping" Cc: "Cullen Jennings" Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 Hello Diego, My understanding is the Diversion Header will be replaced with the Request History Information (http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-02.txt) Fred. ---- Fred Hasle. Leapstone Systems www.leapstone.com -----Original Message----- From: Diego B [mailto:diegob@mailvision.com]=20 Sent: Tuesday, May 18, 2004 7:42 AM To: sip@ietf.org; sipping Cc: Cullen Jennings Subject: [Sip] SIP Forward, Who pays the bill ? Hi; My question is regarding billing a forwarded sip call. Lets take the exmple from draft-ietf-sipping-service-examples 2.7 Alice calls Bob, and Bob has all his incomming calls forwarded to the PSTN. Let say that calls from ALice to Bob in the same domain are free (same=20 office, or same ITSP), but calls to the PSTN are not free. Who pays for Alice call to Bob ?? In a normal situacion, Alice knows that the call is for free becuase she is calling Bob's sip number. But the gateweay may create CDR from the=20 From header of the SIP message and at the end of the month Alice may=20 have to pay for the call. I see this kind of examples in several other drafts/RFC related to SIP=20 services and call forward. I belive forward is a very important feature, but this issue may be=20 resolved. The question is if it is a standard way to make Bob pays for=20 the second leg of the call like in PSTN forward. Maybe changing the From header where applicable and adding a new one to=20 "remember" that the call is from, in my example, Alice. The diversion header (Diversion Indication in SIP=20 draft-levy-sip-diversion-07.txt)" may be a solution if the PSTN gateway=20 or the SIP Billing server support it and knows that they have to bill=20 the sip-uri in the diversion header ( this is right ??? ). Regards; --=20 Diego B MailVision Ltd. Tel. : +972-4-8500505 ext 13 e-mail: diegob@mailvision.com web : http://www.mailvision.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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 18 09:38:27 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14415 for ; Tue, 18 May 2004 09:38:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4kX-0004Kt-NY for sipping-archive@odin.ietf.org; Tue, 18 May 2004 09:35:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IDZHXm016667 for sipping-archive@odin.ietf.org; Tue, 18 May 2004 09:35:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4Xk-0000Rt-Iw for sipping-web-archive@optimus.ietf.org; Tue, 18 May 2004 09:22:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13168 for ; Tue, 18 May 2004 09:22:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ4Xi-0000uf-N4 for sipping-web-archive@ietf.org; Tue, 18 May 2004 09:22:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ4Wl-0000WA-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 09:21:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ4Vp-000080-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 09:20:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4FJ-0002IK-E5; Tue, 18 May 2004 09:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3et-00049C-8v for sipping@optimus.ietf.org; Tue, 18 May 2004 08:25:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08900 for ; Tue, 18 May 2004 08:25:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ3er-0000uV-Oh for sipping@ietf.org; Tue, 18 May 2004 08:25:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ3dl-0000Qs-00 for sipping@ietf.org; Tue, 18 May 2004 08:24:13 -0400 Received: from smtp003.bizmail.yahoo.com ([216.136.130.195]) by ietf-mx with smtp (Exim 4.12) id 1BQ3ck-000005-00 for sipping@ietf.org; Tue, 18 May 2004 08:23:10 -0400 Received: from unknown (HELO BaruchLaptop) (baruch@kayote.com@208.170.170.247 with login) by smtp003.bizmail.yahoo.com with SMTP; 18 May 2004 12:23:07 -0000 Reply-To: From: "Baruch Sterman" To: "'Diego B'" , , "'sipping'" Cc: "'Cullen Jennings'" Date: Tue, 18 May 2004 08:22:50 -0400 Message-ID: <003701c43cd2$daee8540$f7aaaad0@BaruchLaptop> 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <40A9F672.6090008@mailvision.com> Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 In the systems that we implemented, two cdrs are created: the first for the incoming leg (Alice to Bob's non-forwarded location) and a second for the forward to Bob's forwarded location. Alice would pay for the first leg, and Bob pays for the second. Furthermore, it may be the case that Bob pays for the first leg as well. If, for example, Bob has a toll free number where he pays per minute charges for the inbound leg (in this case, Alice is on the PSTN). Either way, multiple CDRs is the way we came up with to handle this. Care has to be taken that the key to any CDR database is NOT the call-ID, because this is the same across the two CDRs. Baruch -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Diego B Sent: Tuesday, May 18, 2004 7:42 AM To: sip@ietf.org; sipping Cc: Cullen Jennings Subject: [Sip] SIP Forward, Who pays the bill ? Hi; My question is regarding billing a forwarded sip call. Lets take the exmple from draft-ietf-sipping-service-examples 2.7 Alice calls Bob, and Bob has all his incomming calls forwarded to the PSTN. Let say that calls from ALice to Bob in the same domain are free (same office, or same ITSP), but calls to the PSTN are not free. Who pays for Alice call to Bob ?? In a normal situacion, Alice knows that the call is for free becuase she is calling Bob's sip number. But the gateweay may create CDR from the From header of the SIP message and at the end of the month Alice may have to pay for the call. I see this kind of examples in several other drafts/RFC related to SIP services and call forward. I belive forward is a very important feature, but this issue may be resolved. The question is if it is a standard way to make Bob pays for the second leg of the call like in PSTN forward. Maybe changing the From header where applicable and adding a new one to "remember" that the call is from, in my example, Alice. The diversion header (Diversion Indication in SIP draft-levy-sip-diversion-07.txt)" may be a solution if the PSTN gateway or the SIP Billing server support it and knows that they have to bill the sip-uri in the diversion header ( this is right ??? ). Regards; -- Diego B MailVision Ltd. Tel. : +972-4-8500505 ext 13 e-mail: diegob@mailvision.com web : http://www.mailvision.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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 18 10:59:12 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21237 for ; Tue, 18 May 2004 10:59:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5uL-0008F6-Jp for sipping-archive@odin.ietf.org; Tue, 18 May 2004 10:49:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IEnTPF031684 for sipping-archive@odin.ietf.org; Tue, 18 May 2004 10:49:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5nJ-0005SS-Rm for sipping-web-archive@optimus.ietf.org; Tue, 18 May 2004 10:42:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19927 for ; Tue, 18 May 2004 10:42:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ5nH-0006Y0-DK for sipping-web-archive@ietf.org; Tue, 18 May 2004 10:42:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ5mN-0006T6-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 10:41:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ5li-0006Oz-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 10:40:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5Yi-0000UY-4d; Tue, 18 May 2004 10:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5O9-0003Mj-2g for sipping@optimus.ietf.org; Tue, 18 May 2004 10:16:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16848 for ; Tue, 18 May 2004 10:16:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ5O6-0006Mw-NA for sipping@ietf.org; Tue, 18 May 2004 10:16:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ5NA-0005zy-00 for sipping@ietf.org; Tue, 18 May 2004 10:15:12 -0400 Received: from mxout5.netvision.net.il ([194.90.9.29]) by ietf-mx with esmtp (Exim 4.12) id 1BQ5Mg-0005dS-00; Tue, 18 May 2004 10:14:42 -0400 Received: from mailvision.com ([212.143.127.195]) by mxout5.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0HXW00HHFY7LQC@mxout5.netvision.net.il>; Tue, 18 May 2004 17:14:11 +0300 (IDT) Date: Tue, 18 May 2004 16:14:09 +0200 From: Diego B In-reply-to: <003701c43cd2$daee8540$f7aaaad0@BaruchLaptop> To: baruch@kayote.com Cc: sip@ietf.org, "'sipping'" , "'Cullen Jennings'" Message-id: <40AA1A31.3050207@mailvision.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: <003701c43cd2$daee8540$f7aaaad0@BaruchLaptop> Content-Transfer-Encoding: 7BIT Subject: [Sipping] Re: [Sip] SIP Forward, Who pays the bill ? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-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,ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Baruch; Thanks for your answer. I belive that you are implementing a proprietary solution to deal with it. I'm looking more to a standarize way to deal with the second-leg issue. I'm agree that Alice has to pay for the first leg and Bob for the second, but if the Proxy that is doing the forward is not a biling entity ( local calls are free, outbound call are not free and billed by an external real-time billing system connected to the GW using RADIUS or similar), the PSTN gateway will have to know that this call may be billed to Bob and not to Alice ( she apears in the From header ). Thanks Baruch Sterman wrote: > In the systems that we implemented, two cdrs are created: the first for > the incoming leg (Alice to Bob's non-forwarded location) and a second > for the forward to Bob's forwarded location. > > Alice would pay for the first leg, and Bob pays for the second. > > Furthermore, it may be the case that Bob pays for the first leg as well. > If, for example, Bob has a toll free number where he pays per minute > charges for the inbound leg (in this case, Alice is on the PSTN). > > Either way, multiple CDRs is the way we came up with to handle this. > Care has to be taken that the key to any CDR database is NOT the > call-ID, because this is the same across the two CDRs. > > Baruch > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Diego > B > Sent: Tuesday, May 18, 2004 7:42 AM > To: sip@ietf.org; sipping > Cc: Cullen Jennings > Subject: [Sip] SIP Forward, Who pays the bill ? > > Hi; > My question is regarding billing a forwarded sip call. > > Lets take the exmple from draft-ietf-sipping-service-examples > 2.7 > > Alice calls Bob, and Bob has all his incomming calls forwarded to the > PSTN. > > Let say that calls from ALice to Bob in the same domain are free (same > office, or same ITSP), but calls to the PSTN are not free. > > Who pays for Alice call to Bob ?? > In a normal situacion, Alice knows that the call is for free becuase she > > is calling Bob's sip number. But the gateweay may create CDR from the > From header of the SIP message and at the end of the month Alice may > have to pay for the call. > > I see this kind of examples in several other drafts/RFC related to SIP > services and call forward. > > I belive forward is a very important feature, but this issue may be > resolved. The question is if it is a standard way to make Bob pays for > the second leg of the call like in PSTN forward. > > Maybe changing the From header where applicable and adding a new one to > "remember" that the call is from, in my example, Alice. > > The diversion header (Diversion Indication in SIP > draft-levy-sip-diversion-07.txt)" may be a solution if the PSTN gateway > or the SIP Billing server support it and knows that they have to bill > the sip-uri in the diversion header ( this is right ??? ). > > Regards; > > > > > -- Diego B MailVision Ltd. Tel. : +972-4-8500505 ext 13 e-mail: diegob@mailvision.com web : http://www.mailvision.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 May 18 11:50: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 LAA23950 for ; Tue, 18 May 2004 11:50:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ6m0-0006Ye-Vm for sipping-archive@odin.ietf.org; Tue, 18 May 2004 11:44:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IFiuQY025203 for sipping-archive@odin.ietf.org; Tue, 18 May 2004 11:44:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ6kO-00062H-OZ for sipping-web-archive@optimus.ietf.org; Tue, 18 May 2004 11:43:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23613 for ; Tue, 18 May 2004 11:43:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ6kN-0002ms-Mm for sipping-web-archive@ietf.org; Tue, 18 May 2004 11:43:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ6ja-0002iy-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 11:42:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ6im-0002ew-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 11:41:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ6Xp-00027E-VI; Tue, 18 May 2004 11:30:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ6Qn-0000KD-0l for sipping@optimus.ietf.org; Tue, 18 May 2004 11:23:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22513 for ; Tue, 18 May 2004 11:22:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ6Qm-0001dm-3u for sipping@ietf.org; Tue, 18 May 2004 11:23:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ6Pt-0001cH-00 for sipping@ietf.org; Tue, 18 May 2004 11:22:05 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BQ6Pa-0001aT-00 for sipping@ietf.org; Tue, 18 May 2004 11:21:46 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i4IFKPLc006084; Tue, 18 May 2004 10:20:25 -0500 (CDT) Received: from ericsson.com (rvi2-93-21.sw.ericsson.se [153.88.93.21]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQWLXLG0; Tue, 18 May 2004 10:19:54 -0500 Message-ID: <40AA29B6.7040702@ericsson.com> Date: Tue, 18 May 2004 18:20:22 +0300 X-Sybari-Trust: 5a0fb975 08d63d2e 09a997dd 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: Markus.Isomaki@nokia.com, dean.willis@softarmor.com, sipping@ietf.org, rohan@cisco.com, mankin@psg.com Subject: Re: [Sipping] Poll: Consensus on adoption of the URI-list work References: <40A8D93F.3060600@ericsson.com> <40A8E3DA.20002@cisco.com> In-Reply-To: <40A8E3DA.20002@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 Paul, > I agree with making this a WG item. Good. > >> In addition, I would like to see discussions on the only important >> open issue we have: security. The security considerations section of >> the requirements and framework for SIP exploders talks about the >> security implications of this work. It would be great if the >> community, including chairs and ADs, had a look at it and express >> their opinions. > > > I don't agree this is the only issue we have. > > I think how the list is specified is still an issue. Use of a uri > parameter is still potentially a problem. (See the ongoing discussion on > uri parameters and proxy translation of the request uri.) > > But these are solvable issues, and I think it is clear that as a group > we need this capability. Yes, I agree that this is a solvable issue. Based on several conversations during the last two IETF meetings, I believe that we have rough consensus on going ahead with the URI parameter, but we can definitively discuss this in the interim during the exploders' time slot. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 18 12:35: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 MAA26059 for ; Tue, 18 May 2004 12:35:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7Rz-0003zY-Hl for sipping-archive@odin.ietf.org; Tue, 18 May 2004 12:28:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IGSJAY015345 for sipping-archive@odin.ietf.org; Tue, 18 May 2004 12:28:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ79J-0006jp-T0 for sipping-web-archive@optimus.ietf.org; Tue, 18 May 2004 12:09:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24861 for ; Tue, 18 May 2004 12:08:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ79I-0004AN-Gj for sipping-web-archive@ietf.org; Tue, 18 May 2004 12:09:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ78N-00048I-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 12:08:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ77V-00046G-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 12:07:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ6zf-0003i9-BP; Tue, 18 May 2004 11:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ6o6-0000VO-04 for sipping@optimus.ietf.org; Tue, 18 May 2004 11:47:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23842 for ; Tue, 18 May 2004 11:47:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ6o4-00030Z-TD for sipping@ietf.org; Tue, 18 May 2004 11:47:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ6n5-0002wj-00 for sipping@ietf.org; Tue, 18 May 2004 11:46:04 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BQ6m3-0002rV-00 for sipping@ietf.org; Tue, 18 May 2004 11:44:59 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i4IFhmLc012494; Tue, 18 May 2004 10:43:48 -0500 (CDT) Received: from ericsson.com (rvi2-93-21.sw.ericsson.se [153.88.93.21]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQWLXM6G; Tue, 18 May 2004 10:43:16 -0500 Message-ID: <40AA2F33.2060305@ericsson.com> Date: Tue, 18 May 2004 18:43:47 +0300 X-Sybari-Trust: abf90250 08d63d2e 09a997dd 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 , Miguel Garcia Subject: Re: [Sipping] Exploders drafts 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 Cullen, Thanks for the comments. Inline: Cullen Jennings wrote: > Few comments on these. > > On draft-camarillo-sipping-exploders-03.txt section 1 - para 2. > > This nicely points out the requirements for exploders - I like it. It does > seem like a reasonable compression scheme would solve this requirement > equally well. Other explained to me this does not work due to inadequacies > in sigcomp but might be worth pointing this out. > > You might make an argument that a solution that took all the final exploded > messages and sent them over an appropriately compressed link uses no more > bandwidth on behalf of the sender than this and resulted in the same > bandwidth usage on the receivers part and therefore the scheme proposed here > was no worse a DOS attack problem than say compressed access links are. Good point. > I imagine recommending logging as a solution for SPAM with exploders is > going to, ah, raise some concerns about the desirability of this scheme. In my opinion, having the exploder assert the identity of the sender would be enough, but some folks had some concerns regarding privacy. That is, the sender does not want the exploder to disclose his identity... we may mention that logging should be used in this case to avoid anonymous spammers, but that in other cases is not needed... > In the section on saying users must agree to receive stuff from an exploder, > it would be nice to say that users must be able to easy revoke this. Having > an explicit SIP mechanism for a user to grant permission to receive > explosions, and more importantly, remove that permission grant, would make > this better. It's interesting, in many ways the exploders is similar to > publish but publish did not seem to have the same range of concerns about > amplification, DOS, and message relay. Might want to figure out how to make > it have the security properties more like publish. I am not sure if we need a *SIP* mechanism for this. Using an out-of-band mechanism such as a web page would work fine. > > On draft-garcia-sipping-message-exploder-00.txt > > The embedded headers in the URI are nice but raise lots of issues. For > example, if I insert a P-Asserted-Identity header with a fake name, will it > be used? Or perhaps a Route header that caused the message to go to someone > that had not agreed to receive exploded messages. > These issues are already described in RFC 3261 talking about clients finding a SIP URI somewhere (e.g., in a web page) and using it. RFC 3261 advices not to populate potentially dangerous headers... the same should apply here. > The " The MESSAGE exploder MUST NOT copy any security body (such as an > S/MIME signed body) addressed to the MESSAGE exploder to the > outgoing MESSAGE request. This includes, e.g., security bodies > signed with the public key of the exploder." > This confuses me. If it was signed, it would be signed with the public key > of the UA sending the request to the exploder? I'm just not sure what you > are getting at with this. Is this the exploder must not relay any S/MIME > body? Yes, it is confusing. The intention of that paragraph was to point out that the exploder should not populate information intended for it (the exploder). We'll rephrase it. > In the security section - last paragraph. Not sure what you are proposing > here. If I wanted to send an encrypted message to A and B, what would I do. > I assume encrypt the List A,B with the public key of the exploder then > provide a copy of the message that was encrypted with a content encryption > key (call it the CEK) then encrypt the CEK with the public key of A and > separately with B then bundle this all up somehow and send it. Yes, that would be the idea. I agree that we need to clarify that. In any case, I have not added mot text to the security considerations sections of all these drafts because I want to have face-to-face discussions before I document the details of the solutions. Once we agree on the way we want to go, I will take care of documenting these types of details. You mention > integrity protection with S/MIME too - are you assuming that the exploder > knows the public key of the UA sending the request? When it comes to integrity protect the contents of the list between the client and the exploder, yes, the exploder would need to know it. > > If the exploder has authenticated the sender, perhaps it should put the > identity of the sender in the From of the messages it sends. This raises > issues with trying to be Anonymous and user an exploder but perhaps this is > a feature not a bug. I agree that privacy should be mentioned in the draft. Thanks for your comments, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 18 14:45:25 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04909 for ; Tue, 18 May 2004 14:45:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9TT-0002BP-Nr for sipping-archive@odin.ietf.org; Tue, 18 May 2004 14:38:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IIbx2T008391 for sipping-archive@odin.ietf.org; Tue, 18 May 2004 14:37:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9Jv-0000tT-TB for sipping-web-archive@optimus.ietf.org; Tue, 18 May 2004 14:28:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03769 for ; Tue, 18 May 2004 14:28:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9Jt-0005Ni-CQ for sipping-web-archive@ietf.org; Tue, 18 May 2004 14:28:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9J4-0005ME-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 14:27:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9Im-0005K4-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 14:26:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ93V-0003yy-0N; Tue, 18 May 2004 14:11:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8tt-0001eF-Gk for sipping@optimus.ietf.org; Tue, 18 May 2004 14:01:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01823 for ; Tue, 18 May 2004 14:01:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ8tr-0003VH-02 for sipping@ietf.org; Tue, 18 May 2004 14:01:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ8t4-0003SW-00 for sipping@ietf.org; Tue, 18 May 2004 14:00:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BQ8s5-0003Li-00 for sipping@ietf.org; Tue, 18 May 2004 13:59:22 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 18 May 2004 10:59:06 -0700 X-BrightmailFiltered: true 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 i4IHwgpM002798; Tue, 18 May 2004 13:58:46 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIO50510; Tue, 18 May 2004 13:58:42 -0400 (EDT) Message-ID: <40AA4ED9.5060603@cisco.com> Date: Tue, 18 May 2004 13:58:49 -0400 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: Markus.Isomaki@nokia.com, dean.willis@softarmor.com, sipping@ietf.org, rohan@cisco.com, mankin@psg.com Subject: Re: [Sipping] Poll: Consensus on adoption of the URI-list work References: <40A8D93F.3060600@ericsson.com> <40A8E3DA.20002@cisco.com> <40AA29B6.7040702@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: > >> I think how the list is specified is still an issue. Use of a uri >> parameter is still potentially a problem. (See the ongoing discussion >> on uri parameters and proxy translation of the request uri.) >> >> But these are solvable issues, and I think it is clear that as a group >> we need this capability. > > Yes, I agree that this is a solvable issue. Based on several > conversations during the last two IETF meetings, I believe that we have > rough consensus on going ahead with the URI parameter, but we can > definitively discuss this in the interim during the exploders' time slot. I think we may have had rough concensus, but it may not have been informed consent. Based on the recent discussions around uri parameters, I don't know how many people realized that they aren't automatically passed along when an address is translated by a proxy. I personally was grudgingly going along on the assumption that you just couldn't use addresses that are subject to proxy translation when you want to use a list. I don't consider that ideal, but have been trying to ignore that. But I would like to be confident that everybody understands that limitation. Alternatively, the draft may need to have language that ammends the functioning of proxies so that the 'list' parameter is passed in translation. But I don't think that is a good idea. 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 May 18 17:07:29 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18465 for ; Tue, 18 May 2004 17:07:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBZ8-0004PH-Er for sipping-archive@odin.ietf.org; Tue, 18 May 2004 16:51:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IKpwsO016939 for sipping-archive@odin.ietf.org; Tue, 18 May 2004 16:51:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBMb-000739-Vh for sipping-web-archive@optimus.ietf.org; Tue, 18 May 2004 16:39:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15646 for ; Tue, 18 May 2004 16:38:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQBMa-0000xx-6I for sipping-web-archive@ietf.org; Tue, 18 May 2004 16:39:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQBL8-0000jj-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 16:37:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQBJI-0000S8-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 16:35:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAUW-0006pV-OF; Tue, 18 May 2004 15:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAPG-0004G2-9V for sipping@optimus.ietf.org; Tue, 18 May 2004 15:37:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09587; Tue, 18 May 2004 15:37:40 -0400 (EDT) Message-Id: <200405181937.PAA09587@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 18 May 2004 15:37:40 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-config-framework-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.5 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 Session Initiation Protocol User Agent Profile Delivery Author(s) : D. Petrie Filename : draft-ietf-sipping-config-framework-03.txt Pages : 23 Date : 2004-5-18 This document defines the application of a set of protocols for providing profile data to SIP user agents. The objective is to define a means for automatically providing profile data a user agent needs to be functional without user or administrative intervention. The framework for discovery, delivery, notification and updates of user agent profile data is defined here. As part of this framework a new SIP event package is defined here for the notification of profile changes. This framework is also intended to ease ongoing administration and upgrading of large scale deployments of SIP user agents. The contents and format of the profile 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-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-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-config-framework-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-5-18155918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-config-framework-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-config-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-18155918.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 May 18 18:30: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 SAA25009 for ; Tue, 18 May 2004 18:30:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCwV-0006qB-Gj for sipping-archive@odin.ietf.org; Tue, 18 May 2004 18:20:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IMKBmI026294 for sipping-archive@odin.ietf.org; Tue, 18 May 2004 18:20:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCpm-0003Gy-He for sipping-web-archive@optimus.ietf.org; Tue, 18 May 2004 18:13:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23643 for ; Tue, 18 May 2004 18:13:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQCpj-0001Wi-QJ for sipping-web-archive@ietf.org; Tue, 18 May 2004 18:13:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQCoi-0001Sr-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 18:12:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQCnv-0001Qp-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 18:11:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCVI-0002gX-R5; Tue, 18 May 2004 17:52:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCQe-0001Ra-Qv for sipping@optimus.ietf.org; Tue, 18 May 2004 17:47:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21031 for ; Tue, 18 May 2004 17:47:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQCQc-0007K9-9h for sipping@ietf.org; Tue, 18 May 2004 17:47:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQCPi-0007Hv-00 for sipping@ietf.org; Tue, 18 May 2004 17:46:18 -0400 Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BQCPA-0007F2-00 for sipping@ietf.org; Tue, 18 May 2004 17:45:44 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i4ILj03x027815 for ; Tue, 18 May 2004 17:45:13 -0400 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh5i.attrh.att.com (6.5.032) id 40A7916900090E97 for sipping@ietf.org; Tue, 18 May 2004 17:45:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.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: [Sipping] draft-dolly-sipping-config-content-00.txt Date: Tue, 18 May 2004 16:45:12 -0500 Message-ID: <28F05913385EAC43AF019413F674A01708145C84@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Sipping] draft-dolly-sipping-config-content-00.txt Thread-Index: AcQ9IWXahTmge+5ERrC0aS0ehJgtZQ== From: "Dolly, Martin C, ALABS" To: 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 This draft has been submitted to the IETF secretariat. In the mean time before it is availble on the IETF web site, you can get a copy = from: ftp://ftp.research.att.com/dist/wtm/draft-dolly-sipping-config-content-00= .txt Absract This document defines the data content for providing profile data to SIP user agents in support of the framework defined in I-D.ietf-sipping-config-framework-02.txt. The profile content format will be defined in a later version of this document or in a separate 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 Tue May 18 18:31: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 SAA25301 for ; Tue, 18 May 2004 18:31:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQD2u-0000Vd-MP for sipping-archive@odin.ietf.org; Tue, 18 May 2004 18:26:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IMQmZH001955 for sipping-archive@odin.ietf.org; Tue, 18 May 2004 18:26:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCqq-0003x4-Mp for sipping-web-archive@optimus.ietf.org; Tue, 18 May 2004 18:14:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23792 for ; Tue, 18 May 2004 18:14:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQCqn-0001c3-Sy for sipping-web-archive@ietf.org; Tue, 18 May 2004 18:14:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQCpv-0001YV-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 18:13:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQCpM-0001Uf-00 for sipping-web-archive@ietf.org; Tue, 18 May 2004 18:12:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCeC-0004Pm-L1; Tue, 18 May 2004 18:01:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCUV-0002OO-TX for sipping@optimus.ietf.org; Tue, 18 May 2004 17:51:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21182 for ; Tue, 18 May 2004 17:51:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQCUT-0007YG-CG for sipping@ietf.org; Tue, 18 May 2004 17:51:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQCTk-0007VY-00 for sipping@ietf.org; Tue, 18 May 2004 17:50:28 -0400 Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BQCSz-0007QJ-00 for sipping@ietf.org; Tue, 18 May 2004 17:49:41 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i4ILmswm019759 for ; Tue, 18 May 2004 16:49:11 -0500 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh5i.attrh.att.com (6.5.032) id 40A7916900091242 for sipping@ietf.org; Tue, 18 May 2004 17:49:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.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: [SIPPING] draft-ietf-sipping-kpml-03 Date: Tue, 18 May 2004 16:49:08 -0500 Message-ID: <28F05913385EAC43AF019413F674A01708145C85@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [SIPPING] draft-ietf-sipping-kpml-03 Thread-Index: AcQ9IfIsNgSIPrRcSTyqJP70HviVBQ== From: "Dolly, Martin C, ALABS" To: 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 This update has been submitted to the IETF secretariat. In the mean time before it is availble on the IETF web site, you can get a copy = from: ftp://ftp.research.att.com/dist/wtm/draft-ietf-sipping-kpml-03.txt Abstract The Key Press Stimulus Event Package is a component of the Applications Interaction Framework for the Session Initiation Protocol (SIP). The event package defines a Key Press Markup Language (KPML) that describes filter specifications for reporting key presses entered at a presentation-free user interface SIP User Agent (UA). The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers). We recommend using VoiceXML or MSCML, as described in the Applications Interaction Framework, for building interactive voice response applications. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 19 01:27:51 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14179 for ; Wed, 19 May 2004 01:27:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQJZC-00051x-DY for sipping-archive@odin.ietf.org; Wed, 19 May 2004 01:24:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J5OYjA019319 for sipping-archive@odin.ietf.org; Wed, 19 May 2004 01:24:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQJSX-0004LX-9F for sipping-web-archive@optimus.ietf.org; Wed, 19 May 2004 01:17:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13757 for ; Wed, 19 May 2004 01:17:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQJSU-0007fG-AJ for sipping-web-archive@ietf.org; Wed, 19 May 2004 01:17:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQJRf-0007XA-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 01:16:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQJQf-0007Ph-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 01:15:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQJM8-0003Pt-7v; Wed, 19 May 2004 01:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQJDp-00017G-B6 for sipping@optimus.ietf.org; Wed, 19 May 2004 01:02:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12905 for ; Wed, 19 May 2004 01:02:27 -0400 (EDT) From: sayan.chowdhury@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQJDm-0005m3-ED for sipping@ietf.org; Wed, 19 May 2004 01:02:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQJCo-0005e0-00 for sipping@ietf.org; Wed, 19 May 2004 01:01:26 -0400 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1BQJBy-0005QN-00; Wed, 19 May 2004 01:00:35 -0400 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 i4J4xuMP028373; Wed, 19 May 2004 10:29:58 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Wed, 19 May 2004 10:29:56 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 May 2004 10:29:55 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43D5E.1FDF7C01" Date: Wed, 19 May 2004 10:29:54 +0530 Message-ID: Thread-Topic: [Sip] SIP Forward, Who pays the bill ? Thread-Index: AcQ85ntCQ3lv2SdwTcebQ0ykeNambQAdPKre To: , Cc: , , X-OriginalArrivalTime: 19 May 2004 04:59:55.0657 (UTC) FILETIME=[209C9790:01C43D5E] Subject: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C43D5E.1FDF7C01 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxzbyAsIEFsaWNlIG1pZ2h0IGJlIHNlbmRpbmcgdGhlIHJlLWludml0ZSB0byBvbiByZWNlaXB0 IG9mIGEgMzAyIGZyb20gQm9iLiBTbyB0aGUgc2V0IG9mIHByb3hpZXMgaW52bG92ZWQgaW4gdGhl IGZpcnN0IGxlZyBvZiB0aGUgY2FsbCBtYXkgbm90IGJlIGludm9sdmVkIGluIHRoZSBzZWNvbmQg Pw0KU29sdXR1aW9uIHRvIHRoaXMgd2lsbCBiZSBvbiB0aGUgUFNUTiBnYXRld2F5IHNpZGUuDQpU aGUgUFNUTiBnYXRld2F5IHNob3VsZCBsb29rIGZvciBhbmQgYmlsbCBmcm9tIERpdmVyc2lvbi9S ZXF1ZXN0IEhpc3RvcnkvcmVtb3RlIFBhcnQgSGVhZGVyIGluZm9ybWF0aW9uIGluIHByZWZlcmVu Y2UgdG8gdGhlIGZyb20gaGVhZGVyIHdoaWNoIGlzIHVucmVsaWFibGUgYW55IHdheS4NCkhvd2V2 ZXIgLCBJIGRvIG5vdCBrbm93IG9mIGFueSBzdGFuZGFyZHMgd2hpY2ggZXhwbGljaXRseSBtZW50 aW9ucyB0aGF0IC4uDQogDQpSZWdhcmRzICwNClNheWFuDQogDQoNCgktLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLSANCglGcm9tOiBzaXAtYWRtaW5AaWV0Zi5vcmcgb24gYmVoYWxmIG9mIERpZWdv IEIgDQoJU2VudDogVHVlIDUvMTgvMjAwNCA3OjQ0IFBNIA0KCVRvOiBiYXJ1Y2hAa2F5b3RlLmNv bSANCglDYzogc2lwQGlldGYub3JnOyAnc2lwcGluZyc7ICdDdWxsZW4gSmVubmluZ3MnIA0KCVN1 YmplY3Q6IFJlOiBbU2lwXSBTSVAgRm9yd2FyZCwgV2hvIHBheXMgdGhlIGJpbGwgPw0KCQ0KCQ0K DQoJSGkgQmFydWNoOw0KCVRoYW5rcyBmb3IgeW91ciBhbnN3ZXIuDQoJSSBiZWxpdmUgdGhhdCB5 b3UgYXJlIGltcGxlbWVudGluZyBhIHByb3ByaWV0YXJ5IHNvbHV0aW9uIHRvIGRlYWwgd2l0aCBp dC4NCglJJ20gbG9va2luZyBtb3JlIHRvIGEgc3RhbmRhcml6ZSB3YXkgdG8gZGVhbCB3aXRoIHRo ZSBzZWNvbmQtbGVnIGlzc3VlLg0KCQ0KCUknbSBhZ3JlZSB0aGF0IEFsaWNlIGhhcyB0byBwYXkg Zm9yIHRoZSBmaXJzdCBsZWcgYW5kIEJvYiBmb3IgdGhlDQoJc2Vjb25kLCBidXQgaWYgdGhlIFBy b3h5IHRoYXQgaXMgZG9pbmcgdGhlIGZvcndhcmQgaXMgbm90IGEgYmlsaW5nDQoJZW50aXR5ICgg bG9jYWwgY2FsbHMgYXJlIGZyZWUsIG91dGJvdW5kIGNhbGwgYXJlIG5vdCBmcmVlIGFuZCBiaWxs ZWQgYnkNCglhbiBleHRlcm5hbCByZWFsLXRpbWUgYmlsbGluZyBzeXN0ZW0gY29ubmVjdGVkIHRv IHRoZSBHVyB1c2luZyBSQURJVVMgb3INCglzaW1pbGFyKSwgdGhlIFBTVE4gZ2F0ZXdheSB3aWxs IGhhdmUgdG8ga25vdyB0aGF0IHRoaXMgY2FsbCBtYXkgYmUNCgliaWxsZWQgdG8gQm9iIGFuZCBu b3QgdG8gQWxpY2UgKCBzaGUgYXBlYXJzIGluIHRoZSBGcm9tIGhlYWRlciApLg0KCQ0KCVRoYW5r cw0KCQ0KCUJhcnVjaCBTdGVybWFuIHdyb3RlOg0KCQ0KCT4gSW4gdGhlIHN5c3RlbXMgdGhhdCB3 ZSBpbXBsZW1lbnRlZCwgdHdvIGNkcnMgYXJlIGNyZWF0ZWQ6IHRoZSBmaXJzdCBmb3INCgk+IHRo ZSBpbmNvbWluZyBsZWcgKEFsaWNlIHRvIEJvYidzIG5vbi1mb3J3YXJkZWQgbG9jYXRpb24pIGFu ZCBhIHNlY29uZA0KCT4gZm9yIHRoZSBmb3J3YXJkIHRvIEJvYidzIGZvcndhcmRlZCBsb2NhdGlv bi4NCgk+DQoJPiBBbGljZSB3b3VsZCBwYXkgZm9yIHRoZSBmaXJzdCBsZWcsIGFuZCBCb2IgcGF5 cyBmb3IgdGhlIHNlY29uZC4NCgk+DQoJPiBGdXJ0aGVybW9yZSwgaXQgbWF5IGJlIHRoZSBjYXNl IHRoYXQgQm9iIHBheXMgZm9yIHRoZSBmaXJzdCBsZWcgYXMgd2VsbC4NCgk+IElmLCBmb3IgZXhh bXBsZSwgQm9iIGhhcyBhIHRvbGwgZnJlZSBudW1iZXIgd2hlcmUgaGUgcGF5cyBwZXIgbWludXRl DQoJPiBjaGFyZ2VzIGZvciB0aGUgaW5ib3VuZCBsZWcgKGluIHRoaXMgY2FzZSwgQWxpY2UgaXMg b24gdGhlIFBTVE4pLg0KCT4NCgk+IEVpdGhlciB3YXksIG11bHRpcGxlIENEUnMgaXMgdGhlIHdh eSB3ZSBjYW1lIHVwIHdpdGggdG8gaGFuZGxlIHRoaXMuDQoJPiBDYXJlIGhhcyB0byBiZSB0YWtl biB0aGF0IHRoZSBrZXkgdG8gYW55IENEUiBkYXRhYmFzZSBpcyBOT1QgdGhlDQoJPiBjYWxsLUlE LCBiZWNhdXNlIHRoaXMgaXMgdGhlIHNhbWUgYWNyb3NzIHRoZSB0d28gQ0RScy4NCgk+DQoJPiBC YXJ1Y2gNCgk+DQoJPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCT4gRnJvbTogc2lwLWFk bWluQGlldGYub3JnIFttYWlsdG86c2lwLWFkbWluQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGll Z28NCgk+IEINCgk+IFNlbnQ6IFR1ZXNkYXksIE1heSAxOCwgMjAwNCA3OjQyIEFNDQoJPiBUbzog c2lwQGlldGYub3JnOyBzaXBwaW5nDQoJPiBDYzogQ3VsbGVuIEplbm5pbmdzDQoJPiBTdWJqZWN0 OiBbU2lwXSBTSVAgRm9yd2FyZCwgV2hvIHBheXMgdGhlIGJpbGwgPw0KCT4NCgk+IEhpOw0KCT4g TXkgcXVlc3Rpb24gaXMgcmVnYXJkaW5nIGJpbGxpbmcgYSBmb3J3YXJkZWQgc2lwIGNhbGwuDQoJ Pg0KCT4gTGV0cyB0YWtlIHRoZSBleG1wbGUgZnJvbSBkcmFmdC1pZXRmLXNpcHBpbmctc2Vydmlj ZS1leGFtcGxlcw0KCT4gMi43DQoJPg0KCT4gQWxpY2UgY2FsbHMgQm9iLCBhbmQgQm9iIGhhcyBh bGwgaGlzIGluY29tbWluZyBjYWxscyBmb3J3YXJkZWQgdG8gdGhlDQoJPiBQU1ROLg0KCT4NCgk+ IExldCBzYXkgdGhhdCBjYWxscyBmcm9tIEFMaWNlIHRvIEJvYiBpbiB0aGUgc2FtZSBkb21haW4g YXJlIGZyZWUgKHNhbWUNCgk+IG9mZmljZSwgb3Igc2FtZSBJVFNQKSwgYnV0IGNhbGxzIHRvIHRo ZSBQU1ROIGFyZSBub3QgZnJlZS4NCgk+DQoJPiBXaG8gcGF5cyBmb3IgQWxpY2UgY2FsbCB0byBC b2IgPz8NCgk+IEluIGEgbm9ybWFsIHNpdHVhY2lvbiwgQWxpY2Uga25vd3MgdGhhdCB0aGUgY2Fs bCBpcyBmb3IgZnJlZSBiZWN1YXNlIHNoZQ0KCT4NCgk+IGlzIGNhbGxpbmcgQm9iJ3Mgc2lwIG51 bWJlci4gQnV0IHRoZSBnYXRld2VheSBtYXkgY3JlYXRlIENEUiBmcm9tIHRoZQ0KCT4gIEZyb20g aGVhZGVyIG9mIHRoZSBTSVAgbWVzc2FnZSBhbmQgYXQgdGhlIGVuZCBvZiB0aGUgbW9udGggQWxp Y2UgbWF5DQoJPiBoYXZlIHRvIHBheSBmb3IgdGhlIGNhbGwuDQoJPg0KCT4gSSBzZWUgdGhpcyBr aW5kIG9mIGV4YW1wbGVzIGluIHNldmVyYWwgb3RoZXIgZHJhZnRzL1JGQyByZWxhdGVkIHRvIFNJ UA0KCT4gc2VydmljZXMgYW5kIGNhbGwgZm9yd2FyZC4NCgk+DQoJPiBJIGJlbGl2ZSBmb3J3YXJk IGlzIGEgdmVyeSBpbXBvcnRhbnQgZmVhdHVyZSwgYnV0IHRoaXMgaXNzdWUgbWF5IGJlDQoJPiBy ZXNvbHZlZC4gVGhlIHF1ZXN0aW9uIGlzIGlmIGl0IGlzIGEgc3RhbmRhcmQgd2F5IHRvIG1ha2Ug Qm9iIHBheXMgZm9yDQoJPiB0aGUgc2Vjb25kIGxlZyBvZiB0aGUgY2FsbCBsaWtlIGluIFBTVE4g Zm9yd2FyZC4NCgk+DQoJPiBNYXliZSBjaGFuZ2luZyB0aGUgRnJvbSBoZWFkZXIgd2hlcmUgYXBw bGljYWJsZSBhbmQgYWRkaW5nIGEgbmV3IG9uZSB0bw0KCT4gInJlbWVtYmVyIiB0aGF0IHRoZSBj YWxsIGlzIGZyb20sIGluIG15IGV4YW1wbGUsIEFsaWNlLg0KCT4NCgk+IFRoZSBkaXZlcnNpb24g aGVhZGVyIChEaXZlcnNpb24gSW5kaWNhdGlvbiBpbiBTSVANCgk+IGRyYWZ0LWxldnktc2lwLWRp dmVyc2lvbi0wNy50eHQpIiBtYXkgYmUgYSBzb2x1dGlvbiBpZiB0aGUgUFNUTiBnYXRld2F5DQoJ PiBvciB0aGUgU0lQIEJpbGxpbmcgc2VydmVyIHN1cHBvcnQgaXQgYW5kIGtub3dzIHRoYXQgdGhl eSBoYXZlIHRvIGJpbGwNCgk+IHRoZSBzaXAtdXJpIGluIHRoZSBkaXZlcnNpb24gaGVhZGVyICgg dGhpcyBpcyByaWdodCA/Pz8gKS4NCgk+DQoJPiBSZWdhcmRzOw0KCT4NCgk+DQoJPg0KCT4NCgk+ DQoJDQoJLS0NCglEaWVnbyBCDQoJTWFpbFZpc2lvbiBMdGQuDQoJVGVsLiAgOiDvnr00LTg1MDA1 MDUgZXh0IDEzDQoJZS1tYWlsOiBkaWVnb2JAbWFpbHZpc2lvbi5jb20NCgl3ZWIgICA6IGh0dHA6 Ly93d3cubWFpbHZpc2lvbi5jb20gPGh0dHBzOi8vZ2F0ZXdheS1pbmRpYS53aXByby5jb20vLERh bmFJbmZvPXd3dy5tYWlsdmlzaW9uLmNvbT4gDQoJDQoJDQoJDQoJX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCglTaXAgbWFpbGluZyBsaXN0ICBodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAgPGh0dHBzOi8vZ2F0ZXdheS1pbmRp YS53aXByby5jb20vbWFpbG1hbi9saXN0aW5mby9zaXAsRGFuYUluZm89d3d3MS5pZXRmLm9yZyxT U0w+IA0KCVRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQ cm90b2NvbA0KCVVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rp b25zIG9uIGN1cnJlbnQgc2lwDQoJVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9w bWVudHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIHNpcA0KCQ0KDQo= ------_=_NextPart_001_01C43D5E.1FDF7C01 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8v RU4iPg0KPEhUTUw+DQo8SEVBRD4NCg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5UPSJN UyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA2LjAuNjUyMS4wIj4NCjxUSVRMRT5SZTogW1NpcF0g U0lQIEZvcndhcmQsIFdobyBwYXlzIHRoZSBiaWxsID88L1RJVExFPg0KPC9IRUFEPg0KPEJPRFkg ZGlyPWx0cj4NCjxESVY+QWxzbyAsIEFsaWNlIG1pZ2h0IGJlIHNlbmRpbmcgdGhlIHJlLWludml0 ZSB0byBvbiByZWNlaXB0IG9mIGEgMzAyIGZyb20gDQpCb2IuIFNvIHRoZSBzZXQgb2YgcHJveGll cyBpbnZsb3ZlZCBpbiB0aGUgZmlyc3QgbGVnIG9mIHRoZSBjYWxsIG1heSBub3QgYmUgDQppbnZv bHZlZCBpbiB0aGUgc2Vjb25kID88L0RJVj4NCjxESVY+U29sdXR1aW9uIHRvIHRoaXMgd2lsbCBi ZSBvbiB0aGUgUFNUTiBnYXRld2F5IHNpZGUuPC9ESVY+DQo8RElWPlRoZSBQU1ROIGdhdGV3YXkg c2hvdWxkIGxvb2sgZm9yIGFuZCBiaWxsIGZyb20gRGl2ZXJzaW9uL1JlcXVlc3QgDQpIaXN0b3J5 L3JlbW90ZSBQYXJ0IEhlYWRlciBpbmZvcm1hdGlvbiBpbiBwcmVmZXJlbmNlIHRvIHRoZSBmcm9t IGhlYWRlciB3aGljaCBpcyANCnVucmVsaWFibGUgYW55IHdheS48L0RJVj4NCjxESVY+SG93ZXZl ciAsIEkgZG8gbm90IGtub3cgb2YgYW55IHN0YW5kYXJkcyB3aGljaCBleHBsaWNpdGx5IG1lbnRp b25zIHRoYXQgDQouLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+UmVnYXJkcyAsPC9E SVY+DQo8RElWPlNheWFuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPEJMT0NLUVVPVEUgZGly PWx0ciBzdHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWPjxGT05UIHNpemU9Mj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSA8QlI+PEI+RnJvbTo8L0I+IA0KICBzaXAtYWRtaW5AaWV0 Zi5vcmcmbmJzcDtvbiBiZWhhbGYgb2YmbmJzcDtEaWVnbyBCIDxCUj48Qj5TZW50OjwvQj4gVHVl IA0KICA1LzE4LzIwMDQgNzo0NCBQTSA8QlI+PEI+VG86PC9CPiBiYXJ1Y2hAa2F5b3RlLmNvbSA8 QlI+PEI+Q2M6PC9CPiANCiAgc2lwQGlldGYub3JnOyAnc2lwcGluZyc7ICdDdWxsZW4gSmVubmlu Z3MnIDxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtTaXBdIFNJUCANCiAgRm9yd2FyZCwgV2hvIHBh eXMgdGhlIGJpbGwgPzxCUj48QlI+PC9GT05UPjwvRElWPg0KICA8UD48Rk9OVCBzaXplPTI+SGkg QmFydWNoOzxCUj5UaGFua3MgZm9yIHlvdXIgYW5zd2VyLjxCUj5JIGJlbGl2ZSB0aGF0IHlvdSBh cmUgDQogIGltcGxlbWVudGluZyBhIHByb3ByaWV0YXJ5IHNvbHV0aW9uIHRvIGRlYWwgd2l0aCBp dC48QlI+SSdtIGxvb2tpbmcgbW9yZSB0byBhIA0KICBzdGFuZGFyaXplIHdheSB0byBkZWFsIHdp dGggdGhlIHNlY29uZC1sZWcgaXNzdWUuPEJSPjxCUj5JJ20gYWdyZWUgdGhhdCBBbGljZSANCiAg aGFzIHRvIHBheSBmb3IgdGhlIGZpcnN0IGxlZyBhbmQgQm9iIGZvciB0aGU8QlI+c2Vjb25kLCBi dXQgaWYgdGhlIFByb3h5IHRoYXQgDQogIGlzIGRvaW5nIHRoZSBmb3J3YXJkIGlzIG5vdCBhIGJp bGluZzxCUj5lbnRpdHkgKCBsb2NhbCBjYWxscyBhcmUgZnJlZSwgDQogIG91dGJvdW5kIGNhbGwg YXJlIG5vdCBmcmVlIGFuZCBiaWxsZWQgYnk8QlI+YW4gZXh0ZXJuYWwgcmVhbC10aW1lIGJpbGxp bmcgDQogIHN5c3RlbSBjb25uZWN0ZWQgdG8gdGhlIEdXIHVzaW5nIFJBRElVUyBvcjxCUj5zaW1p bGFyKSwgdGhlIFBTVE4gZ2F0ZXdheSB3aWxsIA0KICBoYXZlIHRvIGtub3cgdGhhdCB0aGlzIGNh bGwgbWF5IGJlPEJSPmJpbGxlZCB0byBCb2IgYW5kIG5vdCB0byBBbGljZSAoIHNoZSANCiAgYXBl YXJzIGluIHRoZSBGcm9tIGhlYWRlciApLjxCUj48QlI+VGhhbmtzPEJSPjxCUj5CYXJ1Y2ggU3Rl cm1hbiANCiAgd3JvdGU6PEJSPjxCUj4mZ3Q7IEluIHRoZSBzeXN0ZW1zIHRoYXQgd2UgaW1wbGVt ZW50ZWQsIHR3byBjZHJzIGFyZSBjcmVhdGVkOiANCiAgdGhlIGZpcnN0IGZvcjxCUj4mZ3Q7IHRo ZSBpbmNvbWluZyBsZWcgKEFsaWNlIHRvIEJvYidzIG5vbi1mb3J3YXJkZWQgbG9jYXRpb24pIA0K ICBhbmQgYSBzZWNvbmQ8QlI+Jmd0OyBmb3IgdGhlIGZvcndhcmQgdG8gQm9iJ3MgZm9yd2FyZGVk IA0KICBsb2NhdGlvbi48QlI+Jmd0OzxCUj4mZ3Q7IEFsaWNlIHdvdWxkIHBheSBmb3IgdGhlIGZp cnN0IGxlZywgYW5kIEJvYiBwYXlzIGZvciANCiAgdGhlIHNlY29uZC48QlI+Jmd0OzxCUj4mZ3Q7 IEZ1cnRoZXJtb3JlLCBpdCBtYXkgYmUgdGhlIGNhc2UgdGhhdCBCb2IgcGF5cyBmb3IgDQogIHRo ZSBmaXJzdCBsZWcgYXMgd2VsbC48QlI+Jmd0OyBJZiwgZm9yIGV4YW1wbGUsIEJvYiBoYXMgYSB0 b2xsIGZyZWUgbnVtYmVyIA0KICB3aGVyZSBoZSBwYXlzIHBlciBtaW51dGU8QlI+Jmd0OyBjaGFy Z2VzIGZvciB0aGUgaW5ib3VuZCBsZWcgKGluIHRoaXMgY2FzZSwgDQogIEFsaWNlIGlzIG9uIHRo ZSBQU1ROKS48QlI+Jmd0OzxCUj4mZ3Q7IEVpdGhlciB3YXksIG11bHRpcGxlIENEUnMgaXMgdGhl IHdheSB3ZSANCiAgY2FtZSB1cCB3aXRoIHRvIGhhbmRsZSB0aGlzLjxCUj4mZ3Q7IENhcmUgaGFz IHRvIGJlIHRha2VuIHRoYXQgdGhlIGtleSB0byBhbnkgDQogIENEUiBkYXRhYmFzZSBpcyBOT1Qg dGhlPEJSPiZndDsgY2FsbC1JRCwgYmVjYXVzZSB0aGlzIGlzIHRoZSBzYW1lIGFjcm9zcyB0aGUg DQogIHR3byBDRFJzLjxCUj4mZ3Q7PEJSPiZndDsgQmFydWNoPEJSPiZndDs8QlI+Jmd0OyAtLS0t LU9yaWdpbmFsIA0KICBNZXNzYWdlLS0tLS08QlI+Jmd0OyBGcm9tOiBzaXAtYWRtaW5AaWV0Zi5v cmcgWzxBIA0KICBocmVmPSJtYWlsdG86c2lwLWFkbWluQGlldGYub3JnIj5tYWlsdG86c2lwLWFk bWluQGlldGYub3JnPC9BPl0gT24gQmVoYWxmIE9mIA0KICBEaWVnbzxCUj4mZ3Q7IEI8QlI+Jmd0 OyBTZW50OiBUdWVzZGF5LCBNYXkgMTgsIDIwMDQgNzo0MiBBTTxCUj4mZ3Q7IFRvOiANCiAgc2lw QGlldGYub3JnOyBzaXBwaW5nPEJSPiZndDsgQ2M6IEN1bGxlbiBKZW5uaW5nczxCUj4mZ3Q7IFN1 YmplY3Q6IFtTaXBdIFNJUCANCiAgRm9yd2FyZCwgV2hvIHBheXMgdGhlIGJpbGwgPzxCUj4mZ3Q7 PEJSPiZndDsgSGk7PEJSPiZndDsgTXkgcXVlc3Rpb24gaXMgDQogIHJlZ2FyZGluZyBiaWxsaW5n IGEgZm9yd2FyZGVkIHNpcCBjYWxsLjxCUj4mZ3Q7PEJSPiZndDsgTGV0cyB0YWtlIHRoZSBleG1w bGUgDQogIGZyb20gZHJhZnQtaWV0Zi1zaXBwaW5nLXNlcnZpY2UtZXhhbXBsZXM8QlI+Jmd0OyAy Ljc8QlI+Jmd0OzxCUj4mZ3Q7IEFsaWNlIA0KICBjYWxscyBCb2IsIGFuZCBCb2IgaGFzIGFsbCBo aXMgaW5jb21taW5nIGNhbGxzIGZvcndhcmRlZCB0byB0aGU8QlI+Jmd0OyANCiAgUFNUTi48QlI+ Jmd0OzxCUj4mZ3Q7IExldCBzYXkgdGhhdCBjYWxscyBmcm9tIEFMaWNlIHRvIEJvYiBpbiB0aGUg c2FtZSBkb21haW4gDQogIGFyZSBmcmVlIChzYW1lPEJSPiZndDsgb2ZmaWNlLCBvciBzYW1lIElU U1ApLCBidXQgY2FsbHMgdG8gdGhlIFBTVE4gYXJlIG5vdCANCiAgZnJlZS48QlI+Jmd0OzxCUj4m Z3Q7IFdobyBwYXlzIGZvciBBbGljZSBjYWxsIHRvIEJvYiA/PzxCUj4mZ3Q7IEluIGEgbm9ybWFs IA0KICBzaXR1YWNpb24sIEFsaWNlIGtub3dzIHRoYXQgdGhlIGNhbGwgaXMgZm9yIGZyZWUgYmVj dWFzZSBzaGU8QlI+Jmd0OzxCUj4mZ3Q7IA0KICBpcyBjYWxsaW5nIEJvYidzIHNpcCBudW1iZXIu IEJ1dCB0aGUgZ2F0ZXdlYXkgbWF5IGNyZWF0ZSBDRFIgZnJvbSANCiAgdGhlPEJSPiZndDsmbmJz cDsgRnJvbSBoZWFkZXIgb2YgdGhlIFNJUCBtZXNzYWdlIGFuZCBhdCB0aGUgZW5kIG9mIHRoZSBt b250aCANCiAgQWxpY2UgbWF5PEJSPiZndDsgaGF2ZSB0byBwYXkgZm9yIHRoZSBjYWxsLjxCUj4m Z3Q7PEJSPiZndDsgSSBzZWUgdGhpcyBraW5kIG9mIA0KICBleGFtcGxlcyBpbiBzZXZlcmFsIG90 aGVyIGRyYWZ0cy9SRkMgcmVsYXRlZCB0byBTSVA8QlI+Jmd0OyBzZXJ2aWNlcyBhbmQgY2FsbCAN CiAgZm9yd2FyZC48QlI+Jmd0OzxCUj4mZ3Q7IEkgYmVsaXZlIGZvcndhcmQgaXMgYSB2ZXJ5IGlt cG9ydGFudCBmZWF0dXJlLCBidXQgDQogIHRoaXMgaXNzdWUgbWF5IGJlPEJSPiZndDsgcmVzb2x2 ZWQuIFRoZSBxdWVzdGlvbiBpcyBpZiBpdCBpcyBhIHN0YW5kYXJkIHdheSB0byANCiAgbWFrZSBC b2IgcGF5cyBmb3I8QlI+Jmd0OyB0aGUgc2Vjb25kIGxlZyBvZiB0aGUgY2FsbCBsaWtlIGluIFBT VE4gDQogIGZvcndhcmQuPEJSPiZndDs8QlI+Jmd0OyBNYXliZSBjaGFuZ2luZyB0aGUgRnJvbSBo ZWFkZXIgd2hlcmUgYXBwbGljYWJsZSBhbmQgDQogIGFkZGluZyBhIG5ldyBvbmUgdG88QlI+Jmd0 OyAicmVtZW1iZXIiIHRoYXQgdGhlIGNhbGwgaXMgZnJvbSwgaW4gbXkgZXhhbXBsZSwgDQogIEFs aWNlLjxCUj4mZ3Q7PEJSPiZndDsgVGhlIGRpdmVyc2lvbiBoZWFkZXIgKERpdmVyc2lvbiBJbmRp Y2F0aW9uIGluIA0KICBTSVA8QlI+Jmd0OyBkcmFmdC1sZXZ5LXNpcC1kaXZlcnNpb24tMDcudHh0 KSIgbWF5IGJlIGEgc29sdXRpb24gaWYgdGhlIFBTVE4gDQogIGdhdGV3YXk8QlI+Jmd0OyBvciB0 aGUgU0lQIEJpbGxpbmcgc2VydmVyIHN1cHBvcnQgaXQgYW5kIGtub3dzIHRoYXQgdGhleSBoYXZl IA0KICB0byBiaWxsPEJSPiZndDsgdGhlIHNpcC11cmkgaW4gdGhlIGRpdmVyc2lvbiBoZWFkZXIg KCB0aGlzIGlzIHJpZ2h0ID8/PyANCiAgKS48QlI+Jmd0OzxCUj4mZ3Q7IA0KICBSZWdhcmRzOzxC Uj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+PEJSPi0tPEJSPkRpZWdv IA0KICBCPEJSPk1haWxWaXNpb24gTHRkLjxCUj5UZWwuJm5ic3A7IDog7569NC04NTAwNTA1IGV4 dCAxMzxCUj5lLW1haWw6IA0KICBkaWVnb2JAbWFpbHZpc2lvbi5jb208QlI+d2ViJm5ic3A7Jm5i c3A7IDogPEEgDQogIGhyZWY9Imh0dHBzOi8vZ2F0ZXdheS1pbmRpYS53aXByby5jb20vLERhbmFJ bmZvPXd3dy5tYWlsdmlzaW9uLmNvbSI+aHR0cDovL3d3dy5tYWlsdmlzaW9uLmNvbTwvQT48QlI+ PEJSPjxCUj48QlI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188QlI+U2lwIA0KICBtYWlsaW5nIGxpc3QmbmJzcDsgPEEgDQogIGhyZWY9Imh0dHBzOi8vZ2F0 ZXdheS1pbmRpYS53aXByby5jb20vbWFpbG1hbi9saXN0aW5mby9zaXAsRGFuYUluZm89d3d3MS5p ZXRmLm9yZyxTU0wiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcDwv QT48QlI+VGhpcyANCiAgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJ UCBQcm90b2NvbDxCUj5Vc2UgDQogIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZv ciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXA8QlI+VXNlIA0KICBzaXBwaW5nQGlldGYub3JnIGZv ciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiANCnNpcDxCUj48L0ZPTlQ+ PC9QPjwvQkxPQ0tRVU9URT4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C43D5E.1FDF7C01-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 19 06:02: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 GAA26818 for ; Wed, 19 May 2004 06:02:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNjK-0008Dl-LZ for sipping-archive@odin.ietf.org; Wed, 19 May 2004 05:51:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J9pIqK031601 for sipping-archive@odin.ietf.org; Wed, 19 May 2004 05:51:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNTA-0003Ln-5D for sipping-web-archive@optimus.ietf.org; Wed, 19 May 2004 05:34:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24278 for ; Wed, 19 May 2004 05:34:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQNT5-0003VK-OX for sipping-web-archive@ietf.org; Wed, 19 May 2004 05:34:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQNS6-0003LN-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 05:33:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQNR9-0003Ca-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 05:32:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN5U-0007UW-M4; Wed, 19 May 2004 05:10:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5Ux-0007TH-Ix for sipping@optimus.ietf.org; Tue, 18 May 2004 10:23:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17622 for ; Tue, 18 May 2004 10:23:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ5Uv-0001Dj-7t for sipping@ietf.org; Tue, 18 May 2004 10:23:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ5U0-0000pv-00 for sipping@ietf.org; Tue, 18 May 2004 10:22:16 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BQ5TR-0000SP-00; Tue, 18 May 2004 10:21:41 -0400 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 i4IELeAh022890; Tue, 18 May 2004 16:21:40 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 16:21:40 +0200 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.60]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LFSY489V; Tue, 18 May 2004 16:22:16 +0200 Message-ID: <40AA1BF4.2000908@ericsson.com> Date: Tue, 18 May 2004 16:21:40 +0200 X-Sybari-Trust: 5a5e7d8b 08d63d2e 06b283dd 00000138 From: Magnus Westerlund 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: sv, en-us, en MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2004 14:21:40.0449 (UTC) FILETIME=[6FD1F510:01C43CE3] Content-Transfer-Encoding: 7bit Subject: [Sipping] Soliciting comments on Offer/Answer procedures Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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, Any reply to this mail should be directed to the AVT mailing list. The mail is BCC to MMUSIC, SIP and SIPPING to avoid cross postings. In the RTP payload format for the H.264/AVC video codec, we authors had to write a rather special procedure in the offer/answer. This procedure is there to make the distribution of the video codecs parameter sets work. However we would like to have further review from people knowing SIP and Offer/Answer thoroughly, to ensure that we have not created any problems. Therefore I would be very thankful if you could take a look at: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-06.txt and review the Offer/Answer consideration section (8.2). I wouldn't expect that you will need to read more than some further parts of section 8, and possibly some of the introduction in section 1 for background information. Any comments is desired within two weeks, i.e. before 9th of June. Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.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 May 19 06:03: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 GAA26917 for ; Wed, 19 May 2004 06:03:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNk7-0000Ko-MO for sipping-archive@odin.ietf.org; Wed, 19 May 2004 05:52:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J9q7vT001264 for sipping-archive@odin.ietf.org; Wed, 19 May 2004 05:52:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNYg-0005Wa-Su for sipping-web-archive@optimus.ietf.org; Wed, 19 May 2004 05:40:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24893 for ; Wed, 19 May 2004 05:40:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQNYc-0004jt-Q4 for sipping-web-archive@ietf.org; Wed, 19 May 2004 05:40:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQNXh-0004W7-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 05:39:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQNWl-0004Ic-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 05:38:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN6W-0007fn-Nz; Wed, 19 May 2004 05:11:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQMAw-0008Uc-6D for sipping@optimus.ietf.org; Wed, 19 May 2004 04:11:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20630 for ; Wed, 19 May 2004 04:11:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQMAt-00073V-Gg for sipping@ietf.org; Wed, 19 May 2004 04:11:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQM9t-0006w0-00 for sipping@ietf.org; Wed, 19 May 2004 04:10:38 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BQM9J-0006oO-00 for sipping@ietf.org; Wed, 19 May 2004 04:10:01 -0400 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 i4J89jF26618; Wed, 19 May 2004 11:09:45 +0300 (EET DST) X-Scanned: Wed, 19 May 2004 11:09:13 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i4J89Dsv031482; Wed, 19 May 2004 11:09:13 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00n9zP7F; Wed, 19 May 2004 11:09:12 EEST 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 i4J89BH14310; Wed, 19 May 2004 11:09:11 +0300 (EET DST) Received: from [172.21.81.135] ([172.21.81.135]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 19 May 2004 11:09:10 +0300 Message-ID: <40AB1625.3020909@nokia.com> Date: Wed, 19 May 2004 11:09:09 +0300 From: Aki Niemi Organization: Nokia-M/Espoo User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en MIME-Version: 1.0 To: ext Dean Willis CC: sipping@ietf.org, Gonzalo Camarillo , Rohan Mahy , Allison Mankin Subject: Re: [Sipping] Poll: Consensus on adoption of the URI-list work References: <4097DD67.3060104@softarmor.com> In-Reply-To: <4097DD67.3060104@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2004 08:09:10.0965 (UTC) FILETIME=[90E71650:01C43D78] 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 FWIW, I say "aye" for adopting this draft as SIPPING item. Cheers, Aki ext Dean Willis wrote: > > See: draft-camarillo-sipping-uri-list-02.txt > > It seems that the URI-list stuff is becoming important for its use in > ad-hoc list requests. I've heard of several other groups that are > referring to it in their specifications, and wish for us to conclude on > the specification ASAP. > > The current draft is fairly mature, and we seem to have a constituency > for the specification. > > Consequently, I'd like to suggest that the SIPPING group consider > adopting this draft as a working group effort, targeted for > informational RFC, with an estimated delivery date to IESG of June, 2004. > > Please respond, aye or nay, if you care. The chairs will, as usual, > judge consensus and report the recommendation (for or against) to the AD > for consideration. > > Thanks, > > -- > Dean Willis > SIPPING co-chair > > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 May 19 07:01:20 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00950 for ; Wed, 19 May 2004 07:01:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQObo-0002OM-Mv for sipping-archive@odin.ietf.org; Wed, 19 May 2004 06:47:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JAlaeM009195 for sipping-archive@odin.ietf.org; Wed, 19 May 2004 06:47:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQOXP-0001wh-MP for sipping-web-archive@optimus.ietf.org; Wed, 19 May 2004 06:43:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29622 for ; Wed, 19 May 2004 06:42:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQOXL-00001d-LC for sipping-web-archive@ietf.org; Wed, 19 May 2004 06:42:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQOWU-0007dH-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 06:42:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQOVN-0007S1-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 06:40:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQOMk-0000Dr-38; Wed, 19 May 2004 06:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQOJX-0008B0-Ez for sipping@optimus.ietf.org; Wed, 19 May 2004 06:28:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28557 for ; Wed, 19 May 2004 06:28:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQOJT-0005Qc-IU for sipping@ietf.org; Wed, 19 May 2004 06:28:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQOIX-0005GT-00 for sipping@ietf.org; Wed, 19 May 2004 06:27:42 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BQOHY-00056e-00 for sipping@ietf.org; Wed, 19 May 2004 06:26:40 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4JAQUL27009; Wed, 19 May 2004 13:26:30 +0300 (EET DST) X-Scanned: Wed, 19 May 2004 13:26:29 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4JAQT1Q019970; Wed, 19 May 2004 13:26:29 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00acn8Ni; Wed, 19 May 2004 13:26:27 EEST 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 i4JA7VH01175; Wed, 19 May 2004 13:07:31 +0300 (EET DST) Received: from nokia.com ([172.21.40.187]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 19 May 2004 13:07:26 +0300 Message-ID: <40AB31DE.1010903@nokia.com> Date: Wed, 19 May 2004 13:07:26 +0300 From: Miguel Garcia 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, es-es MIME-Version: 1.0 To: Cullen Jennings CC: Gonzalo.Camarillo@ericsson.com, sipping Subject: Re: [Sipping] Exploders drafts References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2004 10:07:26.0245 (UTC) FILETIME=[1604E550:01C43D89] 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 Cullen Jennings wrote: > On draft-garcia-sipping-message-exploder-00.txt > > The embedded headers in the URI are nice but raise lots of issues. For > example, if I insert a P-Asserted-Identity header with a fake name, will it > be used? Or perhaps a Route header that caused the message to go to someone > that had not agreed to receive exploded messages. First, this issue is applicable not only to the MESSAGE exploder draft, but to any other exploder document. It can happen with INVITE, SUBSCRIBE or REFER as well. Second, the exploder implements a SIP UA functionality, meaning that if implements RFC 3325, it is able to distinguish when the P-Asserted-Identity is trusted or not, as required by the RFC. Based on this trustness of the asserted identity, the exploder may implement local policy to pass the header to the other side or not. > > The " The MESSAGE exploder MUST NOT copy any security body (such as an > S/MIME signed body) addressed to the MESSAGE exploder to the > outgoing MESSAGE request. This includes, e.g., security bodies > signed with the public key of the exploder." > This confuses me. If it was signed, it would be signed with the public key > of the UA sending the request to the exploder? I'm just not sure what you > are getting at with this. Is this the exploder must not relay any S/MIME > body? This is obviously wrong. The text shold speak about an "encrypted body" and "bodies encrypted with the public key of the explodr". The idea is very simple: if the exploder is able to decrypt an encrypted body, it should not copy that encrypted body to the outgoing request, since the receiver will not be able to decrypted. > > In the security section - last paragraph. Not sure what you are proposing > here. If I wanted to send an encrypted message to A and B, what would I do. > I assume encrypt the List A,B with the public key of the exploder then > provide a copy of the message that was encrypted with a content encryption > key (call it the CEK) then encrypt the CEK with the public key of A and > separately with B then bundle this all up somehow and send it. Yes, that is how it should be done. I conquer that the text is not clear enough, we will clarify it. > You mention > integrity protection with S/MIME too - are you assuming that the exploder > knows the public key of the UA sending the request? That is the assumption. > > If the exploder has authenticated the sender, perhaps it should put the > identity of the sender in the From of the messages it sends. This raises > issues with trying to be Anonymous and user an exploder but perhaps this is > a feature not a bug. I don't think that the decision point is whether the user is authenticated or not. I belive the decision point is the user requirements expressed in the Privacy header. That will determine whether to populate the From header with the user ID or something else > I don't feel strongly about these drafts one way or another so I hope these > comments get somewhat discounted as casual passer by - I know others have > thought about it much more. Perhaps the amplification issue in this B2BUA > based solution can be justified as no worse than the alternative solution to > the problem using compression with a proxy. > > Cullen > > > -- Miguel A. Garcia tel:+358-50-4804586 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 Wed May 19 09:08:21 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08830 for ; Wed, 19 May 2004 09:08:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQQlc-0002bE-2v for sipping-archive@odin.ietf.org; Wed, 19 May 2004 09:05:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JD5qTY009993 for sipping-archive@odin.ietf.org; Wed, 19 May 2004 09:05:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQQeB-0007qQ-Qo for sipping-web-archive@optimus.ietf.org; Wed, 19 May 2004 08:58:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07090 for ; Wed, 19 May 2004 08:58:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQQe9-0000Un-RI for sipping-web-archive@ietf.org; Wed, 19 May 2004 08:58:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQQcv-0000E1-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 08:56:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQQcN-00002u-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 08:56:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQQL9-0004FG-Qt; Wed, 19 May 2004 08:38:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQPhy-00007y-FO for sipping@optimus.ietf.org; Wed, 19 May 2004 07:58:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04046 for ; Wed, 19 May 2004 07:58:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQPhx-00059d-Jv for sipping@ietf.org; Wed, 19 May 2004 07:58:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQPhF-0004yz-00 for sipping@ietf.org; Wed, 19 May 2004 07:57:18 -0400 Received: from isozyme66.gprs.suomen2g.fi ([62.78.107.66] helo=localhost) by ietf-mx with esmtp (Exim 4.12) id 1BQPgW-0004mA-00; Wed, 19 May 2004 07:56:33 -0400 Received: from jh by localhost with local (Exim 3.35 #1 (Debian)) id 1BQPen-0000Rl-00; Wed, 19 May 2004 14:54:45 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16555.19205.382814.474986@tutpro.com> Date: Wed, 19 May 2004 14:54:45 +0300 To: Diego B Cc: sip@ietf.org, sipping , Cullen Jennings In-Reply-To: <40A9F672.6090008@mailvision.com> References: <40A9F672.6090008@mailvision.com> X-Mailer: VM 7.17 under Emacs 21.2.1 From: Juha Heinanen Content-Transfer-Encoding: 7bit Subject: [Sipping] [Sip] SIP Forward, Who pays the bill ? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 Diego B writes: > The diversion header (Diversion Indication in SIP > draft-levy-sip-diversion-07.txt)" may be a solution if the PSTN gateway > or the SIP Billing server support it and knows that they have to bill > the sip-uri in the diversion header ( this is right ??? ). yes, your proxy can use diversion header or remote-party-id header to make the forwarder to pay for the second leg. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 19 10:46:07 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16690 for ; Wed, 19 May 2004 10:46:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQSDF-0006Jq-UZ for sipping-archive@odin.ietf.org; Wed, 19 May 2004 10:38:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JEcTI0024291 for sipping-archive@odin.ietf.org; Wed, 19 May 2004 10:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQS8n-0004ha-Qc for sipping-web-archive@optimus.ietf.org; Wed, 19 May 2004 10:33:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15496 for ; Wed, 19 May 2004 10:33:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQS8j-0001Zu-Nm for sipping-web-archive@ietf.org; Wed, 19 May 2004 10:33:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQS7i-0001TO-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 10:32:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQS6l-0001NC-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 10:31:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQRfw-0002kd-BL; Wed, 19 May 2004 10:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQRWy-0007zd-TW for sipping@optimus.ietf.org; Wed, 19 May 2004 09:54:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11546 for ; Wed, 19 May 2004 09:54:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQRWw-0006AF-Ud for sipping@ietf.org; Wed, 19 May 2004 09:54:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQRW3-00068I-00 for sipping@ietf.org; Wed, 19 May 2004 09:53:51 -0400 Received: from imo-d01.mx.aol.com ([205.188.157.33]) by ietf-mx with esmtp (Exim 4.12) id 1BQRVr-00065w-00 for sipping@ietf.org; Wed, 19 May 2004 09:53:39 -0400 Received: from bertculpepper@netscape.net by imo-d01.mx.aol.com (mail_out_v37_r1.3.) id 7.7.d51d616 (16239); Wed, 19 May 2004 09:53:03 -0400 (EDT) Received: from netscape.net (87.67.33.65.cfl.rr.com [65.33.67.87]) by air-in03.mx.aol.com (v99_r4.3) with ESMTP id MAILININ33-3f6f40ab66be365; Wed, 19 May 2004 09:53:03 -0400 Message-ID: <40AB678D.3090608@netscape.net> Date: Wed, 19 May 2004 09:56:29 -0400 From: Bert Culpepper 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: e.burger@ieee.org, mdolly@att.com CC: SIPPING List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 65.33.67.87 X-Mailer: Unknown (No Version) Content-Transfer-Encoding: 7bit Subject: [Sipping] NITS on draft-ietf-sipping-kpml-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I read through the document and found the following. - The last sentence in the second to the last paragraph in section 3.6 reads awkward. I believe the statement pertains to processing of invalid KPML documents, however it's not clear to me. The sentence reads: If there is a loaded KPML document on the dialog (and given event id, if present), the end device unloads the document. I suggest the following: In addition, if there is a loaded KPML document on the dialog (with the given event id, if present), the end device unloads the document. Or the failure processing might be made a paragraph on its own (like the description on success processing in the following paragraph). It might also be helpful to mention that this last part (of processing invalid KPML documents) is equivalent to the processing performed for SUBSCRIBE requests that do not contain a KPML body. - Application is misspelled in the fifth line of the note in section 4.1.1. - inter-digit-timer is repeated in the second to the last paragraph on page 20 in section 4.1.2.1. - typos in last line of 4.1.2.2. - The angle brackets around "request" are wrong in section 4.1.6. - The example in section 10.3 mentions the use of http. - Message F8 in section 11.1 contains a KPML body that should not be present based on section 3.7.1. - Call-id and Cseq lines in message F11 in section 11.1 are incorrect. Regards, Bert _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 19 17:47:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21609 for ; Wed, 19 May 2004 17:47:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQYfy-0002jj-Kd for sipping-archive@odin.ietf.org; Wed, 19 May 2004 17:32:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JLWYvk010519 for sipping-archive@odin.ietf.org; Wed, 19 May 2004 17:32:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQYX5-00059s-7u for sipping-web-archive@optimus.ietf.org; Wed, 19 May 2004 17:23:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18420 for ; Wed, 19 May 2004 17:23:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQYX2-0001zy-R2 for sipping-web-archive@ietf.org; Wed, 19 May 2004 17:23:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQYW7-0001sf-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 17:22:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQYVa-0001l7-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 17:21:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQXbi-0007y9-5f; Wed, 19 May 2004 16:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNhm-0007mb-NL for sipping@optimus.ietf.org; Wed, 19 May 2004 05:49:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25800 for ; Wed, 19 May 2004 05:49:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQNhj-0006d1-0v for sipping@ietf.org; Wed, 19 May 2004 05:49:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQNgs-0006RZ-00 for sipping@ietf.org; Wed, 19 May 2004 05:48:49 -0400 Received: from smtp005.bizmail.sc5.yahoo.com ([66.163.175.82]) by ietf-mx with smtp (Exim 4.12) id 1BQNfp-0006EK-00 for sipping@ietf.org; Wed, 19 May 2004 05:47:41 -0400 Received: from unknown (HELO BaruchLaptop) (baruch@kayote.com@208.170.170.247 with login) by smtp005.bizmail.sc5.yahoo.com with SMTP; 19 May 2004 09:47:26 -0000 Reply-To: From: "Baruch Sterman" To: , Cc: , , Date: Wed, 19 May 2004 05:47:07 -0400 Message-ID: <006d01c43d86$44d46a20$f7aaaad0@BaruchLaptop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006E_01C43D64.BDC2CA20" 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.1409 Importance: Normal In-Reply-To: Subject: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_40_50, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_006E_01C43D64.BDC2CA20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Another avenue that can be explored is an explicit header to deal with = this and other accounting issues. I think that the AAA group has = suggested an ACCOUNTING header. We were thinking of a BILLING header. In = that header you would have a username and type. So as the call = progresses you could add to that header. This would also allow to charge = for various services along the way. Imagine the following. Alice calls = Bob, Bob forwards to Charlie who requires an ENUM lookup to find his IP = =E2=80=93 and you are dealing with a psychotic ITSP that *Charges* for = ENUM listing. Inbound Alice -> Bob Billing: Alice, inbound Forward Bob -> Charlie Billing: Alice, inbound; Bob, outbound ITSP looks up Charlie Billing: Alice, inbound; Bob, outbound; = Charlie, serviceX =20 So when the CDR gets written, the rating engine looks through the = Billing header and applies all the relevant charges to the relevant = accounts. Some may be per minute, some may be fixed charges. =20 The problems are first and foremost, security. No one can add to the = billing header unless they are trusted entities within your system, = because money will be charged based on the information there. Second, = care has to be taken to strip off the header when it leaves the trusted = domain =E2=80=93 out to the UA=E2=80=99s for example. You don=E2=80=99t = want people knowing what is going on in your billing system.=20 =20 But the idea here is very flexible and can take into account many things = that we aren=E2=80=99t thinking about now. For example, we may charge = differently one day calls that require NAT treatment on the RTP level = (where the bandwidth cost to the hosting ITSP is not negligible). When = you find that to be the case, just add it to the Billing header. What = about if calls are forwarded multiple times? Keep adding each leg to the = billing header. =20 What does everyone think about this? =20 Baruch =20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = sayan.chowdhury@wipro.com Sent: Wednesday, May 19, 2004 1:00 AM To: diegob@mailvision.com; baruch@kayote.com Cc: sip@ietf.org; sipping@ietf.org; fluffy@cisco.com Subject: RE: [Sip] SIP Forward, Who pays the bill ? =20 Also , Alice might be sending the re-invite to on receipt of a 302 from = Bob. So the set of proxies invloved in the first leg of the call may not = be involved in the second ? Solutuion to this will be on the PSTN gateway side. The PSTN gateway should look for and bill from Diversion/Request = History/remote Part Header information in preference to the from header = which is unreliable any way. However , I do not know of any standards which explicitly mentions that = .. =20 Regards , Sayan =20 -----Original Message-----=20 From: sip-admin@ietf.org on behalf of Diego B=20 Sent: Tue 5/18/2004 7:44 PM=20 To: baruch@kayote.com=20 Cc: sip@ietf.org; 'sipping'; 'Cullen Jennings'=20 Subject: Re: [Sip] SIP Forward, Who pays the bill ? Hi Baruch; Thanks for your answer. I belive that you are implementing a proprietary solution to deal with = it. I'm looking more to a standarize way to deal with the second-leg issue. I'm agree that Alice has to pay for the first leg and Bob for the second, but if the Proxy that is doing the forward is not a biling entity ( local calls are free, outbound call are not free and billed by an external real-time billing system connected to the GW using RADIUS or similar), the PSTN gateway will have to know that this call may be billed to Bob and not to Alice ( she apears in the From header ). Thanks Baruch Sterman wrote: > In the systems that we implemented, two cdrs are created: the first = for > the incoming leg (Alice to Bob's non-forwarded location) and a second > for the forward to Bob's forwarded location. > > Alice would pay for the first leg, and Bob pays for the second. > > Furthermore, it may be the case that Bob pays for the first leg as = well. > If, for example, Bob has a toll free number where he pays per minute > charges for the inbound leg (in this case, Alice is on the PSTN). > > Either way, multiple CDRs is the way we came up with to handle this. > Care has to be taken that the key to any CDR database is NOT the > call-ID, because this is the same across the two CDRs. > > Baruch > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = Diego > B > Sent: Tuesday, May 18, 2004 7:42 AM > To: sip@ietf.org; sipping > Cc: Cullen Jennings > Subject: [Sip] SIP Forward, Who pays the bill ? > > Hi; > My question is regarding billing a forwarded sip call. > > Lets take the exmple from draft-ietf-sipping-service-examples > 2.7 > > Alice calls Bob, and Bob has all his incomming calls forwarded to the > PSTN. > > Let say that calls from ALice to Bob in the same domain are free (same > office, or same ITSP), but calls to the PSTN are not free. > > Who pays for Alice call to Bob ?? > In a normal situacion, Alice knows that the call is for free becuase = she > > is calling Bob's sip number. But the gateweay may create CDR from the > From header of the SIP message and at the end of the month Alice may > have to pay for the call. > > I see this kind of examples in several other drafts/RFC related to SIP > services and call forward. > > I belive forward is a very important feature, but this issue may be > resolved. The question is if it is a standard way to make Bob pays for > the second leg of the call like in PSTN forward. > > Maybe changing the From header where applicable and adding a new one = to > "remember" that the call is from, in my example, Alice. > > The diversion header (Diversion Indication in SIP > draft-levy-sip-diversion-07.txt)" may be a solution if the PSTN = gateway > or the SIP Billing server support it and knows that they have to bill > the sip-uri in the diversion header ( this is right ??? ). > > Regards; > > > > > -- Diego B MailVision Ltd. Tel. : =EF=9E=BD4-8500505 ext 13 e-mail: diegob@mailvision.com web : http://www.mailvision.com = =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip = =20 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 ------=_NextPart_000_006E_01C43D64.BDC2CA20 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Re: [Sip] SIP Forward, Who pays the bill ?

Another avenue that can be explored = is an explicit header to deal with this and other accounting issues. I think = that the AAA group has suggested an ACCOUNTING header. We were thinking of a = BILLING header. In that header you would have a username and type. So as the = call progresses you could add to that header. This would also allow to charge for various services along the way. = Imagine the following. Alice calls Bob, Bob forwards to Charlie who requires an ENUM = lookup to find his IP =E2=80=93 and you are dealing with a psychotic ITSP that = *Charges* for ENUM = listing.

Inbound = Alice -> Bob=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Billing: Alice, inbound

Forward Bob -> Charlie=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Billing: Alice, inbound; Bob, outbound

ITSP looks up Charlie=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Billing: Alice, inbound; Bob, outbound; Charlie, serviceX

 

So when the CDR gets written, the = rating engine looks through the Billing header and applies all the relevant = charges to the relevant accounts. Some may be per minute, some may be fixed = charges.

 

The problems are first and = foremost, security. No one can add to the billing header unless they are trusted = entities within your system, because money will be charged based on the = information there. Second, care has to be taken to strip off the header when it = leaves the trusted domain =E2=80=93 out to the UA=E2=80=99s for example. You don=E2=80=99t want people knowing what is going on in your billing system. =

 

But the idea here is very flexible = and can take into account many things that we aren=E2=80=99t thinking about now. = For example, we may charge differently one day calls that require NAT treatment on = the RTP level (where the bandwidth cost to the hosting ITSP is not negligible). = When you find that to be the case, just add it to the Billing header. What about = if calls are forwarded multiple times? Keep adding each leg to the billing = header.

 

What does everyone think about = this?

 

Baruch

 

-----Original = Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On = Behalf Of sayan.chowdhury@wipro.com
Sent: Wednesday, May 19, = 2004 1:00 AM
To: = diegob@mailvision.com; baruch@kayote.com
Cc: sip@ietf.org; sipping@ietf.org; fluffy@cisco.com
Subject: RE: [Sip] SIP = Forward, Who pays the bill ?

 

Also , Alice = might be sending the re-invite to on receipt of a 302 from Bob. So the set of = proxies invloved in the first leg of the call may not be involved in the second = ?

Solutuion to = this will be on the PSTN gateway side.

The PSTN = gateway should look for and bill from Diversion/Request History/remote Part Header = information in preference to the from header which is unreliable any = way.

However , I do = not know of any standards which explicitly mentions that = ..

 

Regards = ,

Sayan

 

-----Original Message-----
From: = sip-admin@ietf.org on behalf of Diego B
Sent: Tue 5/18/2004 7:44 = PM
To: baruch@kayote.com =
Cc: sip@ietf.org; = 'sipping'; 'Cullen Jennings'
Subject: Re: [Sip] SIP = Forward, Who pays the bill ?

Hi Baruch;
Thanks for your answer.
I belive that you are implementing a proprietary solution to deal with = it.
I'm looking more to a standarize way to deal with the second-leg = issue.

I'm agree that Alice has to pay for the first leg and Bob for the
second, but if the Proxy that is doing the forward is not a biling
entity ( local calls are free, outbound call are not free and billed = by
an external real-time billing system connected to the GW using RADIUS = or
similar), the PSTN gateway will have to know that this call may be
billed to Bob and not to Alice ( she apears in the From header ).

Thanks

Baruch Sterman wrote:

> In the systems that we implemented, two cdrs are created: the first = for
> the incoming leg (Alice to Bob's non-forwarded location) and a = second
> for the forward to Bob's forwarded location.
>
> Alice would pay for the first leg, and Bob pays for the second.
>
> Furthermore, it may be the case that Bob pays for the first leg as = well.
> If, for example, Bob has a toll free number where he pays per = minute
> charges for the inbound leg (in this case, Alice is on the = PSTN).
>
> Either way, multiple CDRs is the way we came up with to handle = this.
> Care has to be taken that the key to any CDR database is NOT = the
> call-ID, because this is the same across the two CDRs.
>
> Baruch
>
> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Diego
> B
> Sent: Tuesday, May 18, 2004 7:42 AM
> To: sip@ietf.org; sipping
> Cc: Cullen Jennings
> Subject: [Sip] SIP Forward, Who pays the bill ?
>
> Hi;
> My question is regarding billing a forwarded sip call.
>
> Lets take the exmple from draft-ietf-sipping-service-examples
> 2.7
>
> Alice calls Bob, and Bob has all his incomming calls forwarded to = the
> PSTN.
>
> Let say that calls from ALice to Bob in the same domain are free = (same
> office, or same ITSP), but calls to the PSTN are not free.
>
> Who pays for Alice call to Bob ??
> In a normal situacion, Alice knows that the call is for free = becuase she
>
> is calling Bob's sip number. But the gateweay may create CDR from = the
>  From header of the SIP message and at the end of the month = Alice may
> have to pay for the call.
>
> I see this kind of examples in several other drafts/RFC related to = SIP
> services and call forward.
>
> I belive forward is a very important feature, but this issue may = be
> resolved. The question is if it is a standard way to make Bob pays = for
> the second leg of the call like in PSTN forward.
>
> Maybe changing the From header where applicable and adding a new = one to
> "remember" that the call is from, in my example, = Alice.
>
> The diversion header (Diversion Indication in SIP
> draft-levy-sip-diversion-07.txt)" may be a solution if the = PSTN gateway
> or the SIP Billing server support it and knows that they have to = bill
> the sip-uri in the diversion header ( this is right ??? ).
>
> Regards;
>
>
>
>
>

--
Diego B
MailVision Ltd.
Tel.  : =EF=9E=BD4-8500505 ext 13
e-mail: diegob@mailvision.com
web   : h= ttp://www.mailvision.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

------=_NextPart_000_006E_01C43D64.BDC2CA20-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 19 22:23:38 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06319 for ; Wed, 19 May 2004 22:23:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQdBy-0000Vg-HR for sipping-archive@odin.ietf.org; Wed, 19 May 2004 22:21:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K2LsEQ001958 for sipping-archive@odin.ietf.org; Wed, 19 May 2004 22:21:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQd7Q-0007Ni-LF for sipping-web-archive@optimus.ietf.org; Wed, 19 May 2004 22:17:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05989 for ; Wed, 19 May 2004 22:17:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQd7N-0001Cz-Bq for sipping-web-archive@ietf.org; Wed, 19 May 2004 22:17:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQd6P-00012Y-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 22:16:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQd5Q-0000rp-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 22:15:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcrl-0003y4-Nx; Wed, 19 May 2004 22:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcjE-00028g-OB for sipping@optimus.ietf.org; Wed, 19 May 2004 21:52:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04845 for ; Wed, 19 May 2004 21:52:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQcjB-0005Wk-Jp for sipping@ietf.org; Wed, 19 May 2004 21:52:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQciC-0005NG-00 for sipping@ietf.org; Wed, 19 May 2004 21:51:09 -0400 Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BQchD-00057b-00; Wed, 19 May 2004 21:50:07 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i4K1nLCM026583; Wed, 19 May 2004 21:49:37 -0400 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh0i.attrh.att.com (6.5.032) id 40951C4D002063B7; Wed, 19 May 2004 21:49:22 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.6561.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43E0C.B427AD59" Date: Wed, 19 May 2004 21:49:35 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A07217374@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Sip] SIP Forward, Who pays the bill ? Thread-Index: AcQ952Sejgp6iCZISuitb+5TBKGx6gAJM1uA From: "Roy, Radhika R, ALABS" To: , , Cc: , , Subject: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C43E0C.B427AD59 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEJhcnVjaCB0aGF0IEFBQSBncm91cCBpcyB3b3JraW5nIGZvciBhdXRoZW50 aWNhdGlvbiwgYXV0aG9yaXphdGlvbiwgYW5kIGFjY291bnRpbmcgb2YgYXBwbGljYXRpb25zIGlu Y2x1ZGluZyBTSVAsIGFuZCB0aGVyZSBpcyBlbm91Z2ggcm9vbSB0byBidWlsZCBDRFJzL0JpbGxp bmcgYmFzZWQgb24gdGhvc2UgdGhpbmdzLiBTbywgU0lQIFdHIGRvZXMgbm90IG5lZWQgdG8gYmUg d29ycmllZCBmb3IgdGhpcy4NCiANClJhZGhpa2EgUi4gUm95DQpycnJveUBhdHQuY29tDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2lwLWFkbWluQGlldGYub3JnIFttYWlsdG86 c2lwLWFkbWluQGlldGYub3JnXU9uIEJlaGFsZiBPZiBCYXJ1Y2ggU3Rlcm1hbg0KU2VudDogV2Vk bmVzZGF5LCBNYXkgMTksIDIwMDQgNTo0NyBBTQ0KVG86IHNheWFuLmNob3dkaHVyeUB3aXByby5j b207IGRpZWdvYkBtYWlsdmlzaW9uLmNvbQ0KQ2M6IHNpcEBpZXRmLm9yZzsgc2lwcGluZ0BpZXRm Lm9yZzsgZmx1ZmZ5QGNpc2NvLmNvbQ0KU3ViamVjdDogUkU6IFtTaXBdIFNJUCBGb3J3YXJkLCBX aG8gcGF5cyB0aGUgYmlsbCA/DQoNCg0KQW5vdGhlciBhdmVudWUgdGhhdCBjYW4gYmUgZXhwbG9y ZWQgaXMgYW4gZXhwbGljaXQgaGVhZGVyIHRvIGRlYWwgd2l0aCB0aGlzIGFuZCBvdGhlciBhY2Nv dW50aW5nIGlzc3Vlcy4gSSB0aGluayB0aGF0IHRoZSBBQUEgZ3JvdXAgaGFzIHN1Z2dlc3RlZCBh biBBQ0NPVU5USU5HIGhlYWRlci4gV2Ugd2VyZSB0aGlua2luZyBvZiBhIEJJTExJTkcgaGVhZGVy LiBJbiB0aGF0IGhlYWRlciB5b3Ugd291bGQgaGF2ZSBhIHVzZXJuYW1lIGFuZCB0eXBlLiBTbyBh cyB0aGUgY2FsbCBwcm9ncmVzc2VzIHlvdSBjb3VsZCBhZGQgdG8gdGhhdCBoZWFkZXIuIFRoaXMg d291bGQgYWxzbyBhbGxvdyB0byBjaGFyZ2UgZm9yIHZhcmlvdXMgc2VydmljZXMgYWxvbmcgdGhl IHdheS4gSW1hZ2luZSB0aGUgZm9sbG93aW5nLiBBbGljZSBjYWxscyBCb2IsIEJvYiBmb3J3YXJk cyB0byBDaGFybGllIHdobyByZXF1aXJlcyBhbiBFTlVNIGxvb2t1cCB0byBmaW5kIGhpcyBJUCDi gJMgYW5kIHlvdSBhcmUgZGVhbGluZyB3aXRoIGEgcHN5Y2hvdGljIElUU1AgdGhhdCAqQ2hhcmdl cyogZm9yIEVOVU0gbGlzdGluZy4NCkluYm91bmQgQWxpY2UgLT4gQm9iICAgICAgICAgQmlsbGlu ZzogQWxpY2UsIGluYm91bmQNCkZvcndhcmQgQm9iIC0+IENoYXJsaWUgICAgICBCaWxsaW5nOiBB bGljZSwgaW5ib3VuZDsgQm9iLCBvdXRib3VuZA0KSVRTUCBsb29rcyB1cCBDaGFybGllICAgICAg ICBCaWxsaW5nOiBBbGljZSwgaW5ib3VuZDsgQm9iLCBvdXRib3VuZDsgQ2hhcmxpZSwgc2Vydmlj ZVgNCiANClNvIHdoZW4gdGhlIENEUiBnZXRzIHdyaXR0ZW4sIHRoZSByYXRpbmcgZW5naW5lIGxv b2tzIHRocm91Z2ggdGhlIEJpbGxpbmcgaGVhZGVyIGFuZCBhcHBsaWVzIGFsbCB0aGUgcmVsZXZh bnQgY2hhcmdlcyB0byB0aGUgcmVsZXZhbnQgYWNjb3VudHMuIFNvbWUgbWF5IGJlIHBlciBtaW51 dGUsIHNvbWUgbWF5IGJlIGZpeGVkIGNoYXJnZXMuDQogDQpUaGUgcHJvYmxlbXMgYXJlIGZpcnN0 IGFuZCBmb3JlbW9zdCwgc2VjdXJpdHkuIE5vIG9uZSBjYW4gYWRkIHRvIHRoZSBiaWxsaW5nIGhl YWRlciB1bmxlc3MgdGhleSBhcmUgdHJ1c3RlZCBlbnRpdGllcyB3aXRoaW4geW91ciBzeXN0ZW0s IGJlY2F1c2UgbW9uZXkgd2lsbCBiZSBjaGFyZ2VkIGJhc2VkIG9uIHRoZSBpbmZvcm1hdGlvbiB0 aGVyZS4gU2Vjb25kLCBjYXJlIGhhcyB0byBiZSB0YWtlbiB0byBzdHJpcCBvZmYgdGhlIGhlYWRl ciB3aGVuIGl0IGxlYXZlcyB0aGUgdHJ1c3RlZCBkb21haW4g4oCTIG91dCB0byB0aGUgVUHigJlz IGZvciBleGFtcGxlLiBZb3UgZG9u4oCZdCB3YW50IHBlb3BsZSBrbm93aW5nIHdoYXQgaXMgZ29p bmcgb24gaW4geW91ciBiaWxsaW5nIHN5c3RlbS4gDQogDQpCdXQgdGhlIGlkZWEgaGVyZSBpcyB2 ZXJ5IGZsZXhpYmxlIGFuZCBjYW4gdGFrZSBpbnRvIGFjY291bnQgbWFueSB0aGluZ3MgdGhhdCB3 ZSBhcmVu4oCZdCB0aGlua2luZyBhYm91dCBub3cuIEZvciBleGFtcGxlLCB3ZSBtYXkgY2hhcmdl IGRpZmZlcmVudGx5IG9uZSBkYXkgY2FsbHMgdGhhdCByZXF1aXJlIE5BVCB0cmVhdG1lbnQgb24g dGhlIFJUUCBsZXZlbCAod2hlcmUgdGhlIGJhbmR3aWR0aCBjb3N0IHRvIHRoZSBob3N0aW5nIElU U1AgaXMgbm90IG5lZ2xpZ2libGUpLiBXaGVuIHlvdSBmaW5kIHRoYXQgdG8gYmUgdGhlIGNhc2Us IGp1c3QgYWRkIGl0IHRvIHRoZSBCaWxsaW5nIGhlYWRlci4gV2hhdCBhYm91dCBpZiBjYWxscyBh cmUgZm9yd2FyZGVkIG11bHRpcGxlIHRpbWVzPyBLZWVwIGFkZGluZyBlYWNoIGxlZyB0byB0aGUg YmlsbGluZyBoZWFkZXIuDQogDQpXaGF0IGRvZXMgZXZlcnlvbmUgdGhpbmsgYWJvdXQgdGhpcz8N CiANCkJhcnVjaA0KIA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcC1hZG1p bkBpZXRmLm9yZyBbbWFpbHRvOnNpcC1hZG1pbkBpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHNheWFu LmNob3dkaHVyeUB3aXByby5jb20NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDE5LCAyMDA0IDE6MDAg QU0NClRvOiBkaWVnb2JAbWFpbHZpc2lvbi5jb207IGJhcnVjaEBrYXlvdGUuY29tDQpDYzogc2lw QGlldGYub3JnOyBzaXBwaW5nQGlldGYub3JnOyBmbHVmZnlAY2lzY28uY29tDQpTdWJqZWN0OiBS RTogW1NpcF0gU0lQIEZvcndhcmQsIFdobyBwYXlzIHRoZSBiaWxsID8NCiANCkFsc28gLCBBbGlj ZSBtaWdodCBiZSBzZW5kaW5nIHRoZSByZS1pbnZpdGUgdG8gb24gcmVjZWlwdCBvZiBhIDMwMiBm cm9tIEJvYi4gU28gdGhlIHNldCBvZiBwcm94aWVzIGludmxvdmVkIGluIHRoZSBmaXJzdCBsZWcg b2YgdGhlIGNhbGwgbWF5IG5vdCBiZSBpbnZvbHZlZCBpbiB0aGUgc2Vjb25kID8NClNvbHV0dWlv biB0byB0aGlzIHdpbGwgYmUgb24gdGhlIFBTVE4gZ2F0ZXdheSBzaWRlLg0KVGhlIFBTVE4gZ2F0 ZXdheSBzaG91bGQgbG9vayBmb3IgYW5kIGJpbGwgZnJvbSBEaXZlcnNpb24vUmVxdWVzdCBIaXN0 b3J5L3JlbW90ZSBQYXJ0IEhlYWRlciBpbmZvcm1hdGlvbiBpbiBwcmVmZXJlbmNlIHRvIHRoZSBm cm9tIGhlYWRlciB3aGljaCBpcyB1bnJlbGlhYmxlIGFueSB3YXkuDQpIb3dldmVyICwgSSBkbyBu b3Qga25vdyBvZiBhbnkgc3RhbmRhcmRzIHdoaWNoIGV4cGxpY2l0bHkgbWVudGlvbnMgdGhhdCAu Lg0KIA0KUmVnYXJkcyAsDQpTYXlhbg0KIA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQpG cm9tOiBzaXAtYWRtaW5AaWV0Zi5vcmcgb24gYmVoYWxmIG9mIERpZWdvIEIgDQpTZW50OiBUdWUg NS8xOC8yMDA0IDc6NDQgUE0gDQpUbzogYmFydWNoQGtheW90ZS5jb20gDQpDYzogc2lwQGlldGYu b3JnOyAnc2lwcGluZyc7ICdDdWxsZW4gSmVubmluZ3MnIA0KU3ViamVjdDogUmU6IFtTaXBdIFNJ UCBGb3J3YXJkLCBXaG8gcGF5cyB0aGUgYmlsbCA/DQpIaSBCYXJ1Y2g7DQpUaGFua3MgZm9yIHlv dXIgYW5zd2VyLg0KSSBiZWxpdmUgdGhhdCB5b3UgYXJlIGltcGxlbWVudGluZyBhIHByb3ByaWV0 YXJ5IHNvbHV0aW9uIHRvIGRlYWwgd2l0aCBpdC4NCkknbSBsb29raW5nIG1vcmUgdG8gYSBzdGFu ZGFyaXplIHdheSB0byBkZWFsIHdpdGggdGhlIHNlY29uZC1sZWcgaXNzdWUuDQoNCkknbSBhZ3Jl ZSB0aGF0IEFsaWNlIGhhcyB0byBwYXkgZm9yIHRoZSBmaXJzdCBsZWcgYW5kIEJvYiBmb3IgdGhl DQpzZWNvbmQsIGJ1dCBpZiB0aGUgUHJveHkgdGhhdCBpcyBkb2luZyB0aGUgZm9yd2FyZCBpcyBu b3QgYSBiaWxpbmcNCmVudGl0eSAoIGxvY2FsIGNhbGxzIGFyZSBmcmVlLCBvdXRib3VuZCBjYWxs IGFyZSBub3QgZnJlZSBhbmQgYmlsbGVkIGJ5DQphbiBleHRlcm5hbCByZWFsLXRpbWUgYmlsbGlu ZyBzeXN0ZW0gY29ubmVjdGVkIHRvIHRoZSBHVyB1c2luZyBSQURJVVMgb3INCnNpbWlsYXIpLCB0 aGUgUFNUTiBnYXRld2F5IHdpbGwgaGF2ZSB0byBrbm93IHRoYXQgdGhpcyBjYWxsIG1heSBiZQ0K YmlsbGVkIHRvIEJvYiBhbmQgbm90IHRvIEFsaWNlICggc2hlIGFwZWFycyBpbiB0aGUgRnJvbSBo ZWFkZXIgKS4NCg0KVGhhbmtzDQoNCkJhcnVjaCBTdGVybWFuIHdyb3RlOg0KDQo+IEluIHRoZSBz eXN0ZW1zIHRoYXQgd2UgaW1wbGVtZW50ZWQsIHR3byBjZHJzIGFyZSBjcmVhdGVkOiB0aGUgZmly c3QgZm9yDQo+IHRoZSBpbmNvbWluZyBsZWcgKEFsaWNlIHRvIEJvYidzIG5vbi1mb3J3YXJkZWQg bG9jYXRpb24pIGFuZCBhIHNlY29uZA0KPiBmb3IgdGhlIGZvcndhcmQgdG8gQm9iJ3MgZm9yd2Fy ZGVkIGxvY2F0aW9uLg0KPg0KPiBBbGljZSB3b3VsZCBwYXkgZm9yIHRoZSBmaXJzdCBsZWcsIGFu ZCBCb2IgcGF5cyBmb3IgdGhlIHNlY29uZC4NCj4NCj4gRnVydGhlcm1vcmUsIGl0IG1heSBiZSB0 aGUgY2FzZSB0aGF0IEJvYiBwYXlzIGZvciB0aGUgZmlyc3QgbGVnIGFzIHdlbGwuDQo+IElmLCBm b3IgZXhhbXBsZSwgQm9iIGhhcyBhIHRvbGwgZnJlZSBudW1iZXIgd2hlcmUgaGUgcGF5cyBwZXIg bWludXRlDQo+IGNoYXJnZXMgZm9yIHRoZSBpbmJvdW5kIGxlZyAoaW4gdGhpcyBjYXNlLCBBbGlj ZSBpcyBvbiB0aGUgUFNUTikuDQo+DQo+IEVpdGhlciB3YXksIG11bHRpcGxlIENEUnMgaXMgdGhl IHdheSB3ZSBjYW1lIHVwIHdpdGggdG8gaGFuZGxlIHRoaXMuDQo+IENhcmUgaGFzIHRvIGJlIHRh a2VuIHRoYXQgdGhlIGtleSB0byBhbnkgQ0RSIGRhdGFiYXNlIGlzIE5PVCB0aGUNCj4gY2FsbC1J RCwgYmVjYXVzZSB0aGlzIGlzIHRoZSBzYW1lIGFjcm9zcyB0aGUgdHdvIENEUnMuDQo+DQo+IEJh cnVjaA0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXAtYWRtaW5A aWV0Zi5vcmcgWyBtYWlsdG86c2lwLWFkbWluQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGllZ28N Cj4gQg0KPiBTZW50OiBUdWVzZGF5LCBNYXkgMTgsIDIwMDQgNzo0MiBBTQ0KPiBUbzogc2lwQGll dGYub3JnOyBzaXBwaW5nDQo+IENjOiBDdWxsZW4gSmVubmluZ3MNCj4gU3ViamVjdDogW1NpcF0g U0lQIEZvcndhcmQsIFdobyBwYXlzIHRoZSBiaWxsID8NCj4NCj4gSGk7DQo+IE15IHF1ZXN0aW9u IGlzIHJlZ2FyZGluZyBiaWxsaW5nIGEgZm9yd2FyZGVkIHNpcCBjYWxsLg0KPg0KPiBMZXRzIHRh a2UgdGhlIGV4bXBsZSBmcm9tIGRyYWZ0LWlldGYtc2lwcGluZy1zZXJ2aWNlLWV4YW1wbGVzDQo+ IDIuNw0KPg0KPiBBbGljZSBjYWxscyBCb2IsIGFuZCBCb2IgaGFzIGFsbCBoaXMgaW5jb21taW5n IGNhbGxzIGZvcndhcmRlZCB0byB0aGUNCj4gUFNUTi4NCj4NCj4gTGV0IHNheSB0aGF0IGNhbGxz IGZyb20gQUxpY2UgdG8gQm9iIGluIHRoZSBzYW1lIGRvbWFpbiBhcmUgZnJlZSAoc2FtZQ0KPiBv ZmZpY2UsIG9yIHNhbWUgSVRTUCksIGJ1dCBjYWxscyB0byB0aGUgUFNUTiBhcmUgbm90IGZyZWUu DQo+DQo+IFdobyBwYXlzIGZvciBBbGljZSBjYWxsIHRvIEJvYiA/Pw0KPiBJbiBhIG5vcm1hbCBz aXR1YWNpb24sIEFsaWNlIGtub3dzIHRoYXQgdGhlIGNhbGwgaXMgZm9yIGZyZWUgYmVjdWFzZSBz aGUNCj4NCj4gaXMgY2FsbGluZyBCb2IncyBzaXAgbnVtYmVyLiBCdXQgdGhlIGdhdGV3ZWF5IG1h eSBjcmVhdGUgQ0RSIGZyb20gdGhlDQo+ICBGcm9tIGhlYWRlciBvZiB0aGUgU0lQIG1lc3NhZ2Ug YW5kIGF0IHRoZSBlbmQgb2YgdGhlIG1vbnRoIEFsaWNlIG1heQ0KPiBoYXZlIHRvIHBheSBmb3Ig dGhlIGNhbGwuDQo+DQo+IEkgc2VlIHRoaXMga2luZCBvZiBleGFtcGxlcyBpbiBzZXZlcmFsIG90 aGVyIGRyYWZ0cy9SRkMgcmVsYXRlZCB0byBTSVANCj4gc2VydmljZXMgYW5kIGNhbGwgZm9yd2Fy ZC4NCj4NCj4gSSBiZWxpdmUgZm9yd2FyZCBpcyBhIHZlcnkgaW1wb3J0YW50IGZlYXR1cmUsIGJ1 dCB0aGlzIGlzc3VlIG1heSBiZQ0KPiByZXNvbHZlZC4gVGhlIHF1ZXN0aW9uIGlzIGlmIGl0IGlz IGEgc3RhbmRhcmQgd2F5IHRvIG1ha2UgQm9iIHBheXMgZm9yDQo+IHRoZSBzZWNvbmQgbGVnIG9m IHRoZSBjYWxsIGxpa2UgaW4gUFNUTiBmb3J3YXJkLg0KPg0KPiBNYXliZSBjaGFuZ2luZyB0aGUg RnJvbSBoZWFkZXIgd2hlcmUgYXBwbGljYWJsZSBhbmQgYWRkaW5nIGEgbmV3IG9uZSB0bw0KPiAi cmVtZW1iZXIiIHRoYXQgdGhlIGNhbGwgaXMgZnJvbSwgaW4gbXkgZXhhbXBsZSwgQWxpY2UuDQo+ DQo+IFRoZSBkaXZlcnNpb24gaGVhZGVyIChEaXZlcnNpb24gSW5kaWNhdGlvbiBpbiBTSVANCj4g ZHJhZnQtbGV2eS1zaXAtZGl2ZXJzaW9uLTA3LnR4dCkiIG1heSBiZSBhIHNvbHV0aW9uIGlmIHRo ZSBQU1ROIGdhdGV3YXkNCj4gb3IgdGhlIFNJUCBCaWxsaW5nIHNlcnZlciBzdXBwb3J0IGl0IGFu ZCBrbm93cyB0aGF0IHRoZXkgaGF2ZSB0byBiaWxsDQo+IHRoZSBzaXAtdXJpIGluIHRoZSBkaXZl cnNpb24gaGVhZGVyICggdGhpcyBpcyByaWdodCA/Pz8gKS4NCj4NCj4gUmVnYXJkczsNCj4NCj4N Cj4NCj4NCj4NCg0KLS0NCkRpZWdvIEINCk1haWxWaXNpb24gTHRkLg0KVGVsLiAgOiDvnr00LTg1 MDA1MDUgZXh0IDEzDQplLW1haWw6IGRpZWdvYkBtYWlsdmlzaW9uLmNvbQ0Kd2ViICAgOiBodHRw Oi8vd3d3Lm1haWx2aXNpb24uY29tIDxodHRwczovL2dhdGV3YXktaW5kaWEud2lwcm8uY29tLyxE YW5hSW5mbz13d3cubWFpbHZpc2lvbi5jb20+IA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcCA8aHR0cHM6Ly9nYXRld2F5LWluZGlhLndp cHJvLmNvbS9tYWlsbWFuL2xpc3RpbmZvL3NpcCxEYW5hSW5mbz13d3cxLmlldGYub3JnLFNTTD4g DQpUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9j b2wNClVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9u IGN1cnJlbnQgc2lwDQpVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBv biB0aGUgYXBwbGljYXRpb24gb2Ygc2lwDQo= ------_=_NextPart_001_01C43E0C.B427AD59 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czpvID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3 ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxID0g DQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIj48SEVBRD4NCjxN RVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04Ij4NCjxUSVRMRT5SZTogW1NpcF0gU0lQIEZvcndhcmQsIFdobyBwYXlzIHRoZSBiaWxs ID88L1RJVExFPg0KDQo8TUVUQSBjb250ZW50PVdvcmQuRG9jdW1lbnQgbmFtZT1Qcm9nSWQ+DQo8 TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0MDAiIG5hbWU9R0VORVJBVE9SPg0KPE1F VEEgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTAiIG5hbWU9T3JpZ2luYXRvcj48TElOSyANCmhy ZWY9ImNpZDpmaWxlbGlzdC54bWxAMDFDNDNENjQuQjgyQzk1NTAiIHJlbD1GaWxlLUxpc3Q+PG86 U21hcnRUYWdUeXBlIA0KbmFtZT0iQ2l0eSIgDQpuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyI+PC9vOlNtYXJ0VGFnVHlwZT48bzpTbWFydFRh Z1R5cGUgDQpuYW1lPSJwbGFjZSIgDQpuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29m dC1jb206b2ZmaWNlOnNtYXJ0dGFncyI+PC9vOlNtYXJ0VGFnVHlwZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCiA8bzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KICA8bzpEb05vdFJlbHlPbkNT Uy8+DQogPC9vOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8dzpXb3JkRG9jdW1lbnQ+DQogIDx3OlNwZWxsaW5nU3Rh dGU+Q2xlYW48L3c6U3BlbGxpbmdTdGF0ZT4NCiAgPHc6R3JhbW1hclN0YXRlPkNsZWFuPC93Okdy YW1tYXJTdGF0ZT4NCiAgPHc6RG9jdW1lbnRLaW5kPkRvY3VtZW50RW1haWw8L3c6RG9jdW1lbnRL aW5kPg0KICA8dzpFbnZlbG9wZVZpcy8+DQogIDx3OkNvbXBhdGliaWxpdHk+DQogICA8dzpBcHBs eUJyZWFraW5nUnVsZXMvPg0KICA8L3c6Q29tcGF0aWJpbGl0eT4NCiAgPHc6QnJvd3NlckxldmVs Pk1pY3Jvc29mdEludGVybmV0RXhwbG9yZXI0PC93OkJyb3dzZXJMZXZlbD4NCiA8L3c6V29yZERv Y3VtZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiAhbXNvXT4NCjxTVFlMRT5zdDFcOiog ew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1bHQjaWVvb3VpKQ0KfQ0KPC9TVFlMRT4NCjwhW2VuZGlm XS0tPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBCYXRhbmc7DQp9DQpAZm9u dC1mYWNlIHsNCglmb250LWZhbWlseTogVGFob21hOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1m YW1pbHk6IEBCYXRhbmc7DQp9DQpAcGFnZSBTZWN0aW9uMSB7c2l6ZTogNjEyLjBwdCA3OTIuMHB0 OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDsgbXNvLWhlYWRlci1tYXJnaW46 IDM2LjBwdDsgbXNvLWZvb3Rlci1tYXJnaW46IDM2LjBwdDsgbXNvLXBhcGVyLXNvdXJjZTogMDsg fQ0KUC5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOOiAwbW0gMG1tIDBwdDsg Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBtc28tc3R5bGUtcGFyZW50OiAiIjsgbXNv LXBhZ2luYXRpb246IHdpZG93LW9ycGhhbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICJUaW1l cyBOZXcgUm9tYW4iDQp9DQpMSS5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lO OiAwbW0gMG1tIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBtc28tc3R5bGUt cGFyZW50OiAiIjsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbjsgbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iDQp9DQpESVYuTXNvTm9ybWFsIHsNCglGT05ULVNJ WkU6IDEycHQ7IE1BUkdJTjogMG1tIDBtbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJv bWFuIjsgbXNvLXN0eWxlLXBhcmVudDogIiI7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW47 IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3IFJvbWFuIg0KfQ0KQTpsaW5rIHsN CglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmU7IHRleHQtdW5kZXJsaW5l OiBzaW5nbGUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNP UkFUSU9OOiB1bmRlcmxpbmU7IHRleHQtdW5kZXJsaW5lOiBzaW5nbGUNCn0NCkE6dmlzaXRlZCB7 DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyB0ZXh0LXVuZGVybGlu ZTogc2luZ2xlDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogYmx1ZTsg VEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmU7IHRleHQtdW5kZXJsaW5lOiBzaW5nbGUNCn0NClAg ew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOLUxFRlQ6IDBtbTsgTUFSR0lOLVJJR0hUOiAwbW07 IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9y cGhhbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iOyBtc28tbWFy Z2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0bw0KfQ0KU1BBTi5F bWFpbFN0eWxlMTggew0KCUNPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWw7IG1zby1zdHls ZS10eXBlOiBwZXJzb25hbC1yZXBseTsgbXNvLXN0eWxlLW5vc2hvdzogeWVzOyBtc28tYW5zaS1m b250LXNpemU6IDEwLjBwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1hc2NpaS1m b250LWZhbWlseTogQXJpYWw7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRp LWZvbnQtZmFtaWx5OiBBcmlhbA0KfQ0KU1BBTi5TcGVsbEUgew0KCW1zby1zdHlsZS1uYW1lOiAi IjsgbXNvLXNwbC1lOiB5ZXMNCn0NClNQQU4uR3JhbUUgew0KCW1zby1zdHlsZS1uYW1lOiAiIjsg bXNvLWdyYW0tZTogeWVzDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24xDQp9DQo8 L1NUWUxFPg0KPCEtLVtpZiBndGUgbXNvIDEwXT4NCjxzdHlsZT4NCiAvKiBTdHlsZSBEZWZpbml0 aW9ucyAqLyANCiB0YWJsZS5Nc29Ob3JtYWxUYWJsZQ0KCXttc28tc3R5bGUtbmFtZToiVGFibGUg Tm9ybWFsIjsNCgltc28tdHN0eWxlLXJvd2JhbmQtc2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFu ZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsN Cgltc28tcGFkZGluZy1hbHQ6MG1tIDUuNHB0IDBtbSA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46 MG1tOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3 aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjt9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+PC9IRUFEPg0KPEJPRFkgbGFuZz1FTi1V UyBzdHlsZT0idGFiLWludGVydmFsOiAzNi4wcHQiIHZMaW5rPWJsdWUgbGluaz1ibHVlPg0KPERJ Vj48U1BBTiBjbGFzcz0zODc1NzQ1MDEtMjAwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIHNpemU9Mj5JIA0KYWdyZWUgd2l0aCBCYXJ1Y2ggdGhhdCBBQUEgZ3JvdXAgaXMgd29y a2luZyBmb3IgYXV0aGVudGljYXRpb24sIGF1dGhvcml6YXRpb24sIA0KYW5kIGFjY291bnRpbmcm bmJzcDtvZiBhcHBsaWNhdGlvbnMgaW5jbHVkaW5nIFNJUCwgYW5kIHRoZXJlIGlzIGVub3VnaCBy b29tIHRvIA0KYnVpbGQgQ0RScy9CaWxsaW5nIGJhc2VkIG9uIHRob3NlIHRoaW5ncy4gU28sIFNJ UCBXRyBkb2VzIG5vdCBuZWVkIHRvIGJlIHdvcnJpZWQgDQpmb3IgdGhpcy48L0ZPTlQ+PC9TUEFO PjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0zODc1NzQ1MDEtMjAwNTIwMDQ+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8 RElWPjxTUEFOIGNsYXNzPTM4NzU3NDUwMS0yMDA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PSMwMDAwZmYgDQpzaXplPTI+UmFkaGlrYSBSLiBSb3k8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz0zODc1NzQ1MDEtMjAwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIHNpemU9Mj48QSANCmhyZWY9Im1haWx0bzpycnJveUBhdHQuY29tIj5ycnJveUBhdHQu Y29tPC9BPjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxlPSJN QVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgZGly PWx0ciBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9VGFob21hIA0KICBzaXplPTI+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IHNpcC1hZG1pbkBpZXRmLm9yZyANCiAgW21h aWx0bzpzaXAtYWRtaW5AaWV0Zi5vcmddPEI+T24gQmVoYWxmIE9mIDwvQj5CYXJ1Y2ggU3Rlcm1h bjxCUj48Qj5TZW50OjwvQj4gDQogIFdlZG5lc2RheSwgTWF5IDE5LCAyMDA0IDU6NDcgQU08QlI+ PEI+VG86PC9CPiBzYXlhbi5jaG93ZGh1cnlAd2lwcm8uY29tOyANCiAgZGllZ29iQG1haWx2aXNp b24uY29tPEJSPjxCPkNjOjwvQj4gc2lwQGlldGYub3JnOyBzaXBwaW5nQGlldGYub3JnOyANCiAg Zmx1ZmZ5QGNpc2NvLmNvbTxCUj48Qj5TdWJqZWN0OjwvQj4gUkU6IFtTaXBdIFNJUCBGb3J3YXJk LCBXaG8gcGF5cyB0aGUgYmlsbCANCiAgPzxCUj48QlI+PC9GT05UPjwvRElWPg0KICA8RElWIGNs YXNzPVNlY3Rpb24xPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5h dnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+QW5vdGhlciBhdmVudWUgdGhhdCANCiAgY2FuIGJlIGV4 cGxvcmVkIGlzIGFuIGV4cGxpY2l0IGhlYWRlciB0byBkZWFsIHdpdGggdGhpcyBhbmQgb3RoZXIg YWNjb3VudGluZyANCiAgaXNzdWVzLiBJIHRoaW5rIHRoYXQgdGhlIEFBQSBncm91cCBoYXMgc3Vn Z2VzdGVkIGFuIEFDQ09VTlRJTkcgaGVhZGVyLiBXZSB3ZXJlIA0KICB0aGlua2luZyBvZiBhIEJJ TExJTkcgaGVhZGVyLiBJbiB0aGF0IGhlYWRlciB5b3Ugd291bGQgaGF2ZSBhIHVzZXJuYW1lIGFu ZCANCiAgdHlwZS4gU28gYXMgdGhlIGNhbGwgcHJvZ3Jlc3NlcyB5b3UgY291bGQgYWRkIHRvIHRo YXQgaGVhZGVyLiBUaGlzIHdvdWxkIGFsc28gDQogIGFsbG93IDxTUEFOIGNsYXNzPUdyYW1FPnRv IGNoYXJnZTwvU1BBTj4gZm9yIHZhcmlvdXMgc2VydmljZXMgYWxvbmcgdGhlIHdheS4gDQogIElt YWdpbmUgdGhlIGZvbGxvd2luZy4gPC9TUEFOPjwvRk9OVD48c3QxOkNpdHk+PHN0MTpwbGFjZT48 Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+QWxpY2U8L1NQ QU4+PC9GT05UPjwvc3QxOnBsYWNlPjwvc3QxOkNpdHk+PEZPTlQgDQogIGZhY2U9QXJpYWwgY29s b3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBu YXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPiBjYWxscyBCb2IsIEJvYiANCiAgZm9yd2FyZHMgdG8g Q2hhcmxpZSB3aG8gcmVxdWlyZXMgYW4gRU5VTSBsb29rdXAgdG8gZmluZCBoaXMgSVAg4oCTIGFu ZCB5b3UgYXJlIA0KICBkZWFsaW5nIHdpdGggYSBwc3ljaG90aWMgSVRTUCB0aGF0ICo8Qj48U1BB TiANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5DaGFyZ2VzPC9TUEFOPjwvQj4qIGZvciBF TlVNIA0KICBsaXN0aW5nLjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5J bmJvdW5kIA0KICA8L1NQQU4+PC9GT05UPjxzdDE6Q2l0eT48c3QxOnBsYWNlPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPkFsaWNlPC9TUEFOPjwvRk9OVD48L3N0 MTpwbGFjZT48L3N0MTpDaXR5PjxGT05UIA0KICBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0y PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1J TFk6IEFyaWFsIj4gLSZndDsgQm9iPFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQ QU4+QmlsbGluZzogPC9TUEFOPjwvRk9OVD48c3QxOkNpdHk+PHN0MTpwbGFjZT48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPW5hdnkgDQogIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+QWxpY2U8L1NQQU4+PC9GT05U Pjwvc3QxOnBsYWNlPjwvc3QxOkNpdHk+PEZPTlQgDQogIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBz aXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05U LUZBTUlMWTogQXJpYWwiPiwgDQogIGluYm91bmQ8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9 Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFN SUxZOiBBcmlhbCI+Rm9yd2FyZCBCb2IgLSZndDsgDQogIENoYXJsaWU8U1BBTiBzdHlsZT0ibXNv LXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFO PkJpbGxpbmc6IDwvU1BBTj48L0ZPTlQ+PHN0MTpDaXR5PjxzdDE6cGxhY2U+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj1uYXZ5IA0KICBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPkFsaWNlPC9TUEFOPjwvRk9OVD48 L3N0MTpwbGFjZT48L3N0MTpDaXR5PjxGT05UIA0KICBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6 ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1G QU1JTFk6IEFyaWFsIj4sIGluYm91bmQ7IEJvYiwgDQogIG91dGJvdW5kPG86cD48L286cD48L1NQ QU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29s b3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBu YXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPklUU1AgbG9va3MgdXAgDQogIENoYXJsaWU8U1BBTiAN CiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5CaWxsaW5nOiA8L1NQQU4+PC9GT05UPjxzdDE6Q2l0 eT48c3QxOnBsYWNlPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSANCiAgc2l6ZT0yPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFy aWFsIj5BbGljZTwvU1BBTj48L0ZPTlQ+PC9zdDE6cGxhY2U+PC9zdDE6Q2l0eT48Rk9OVCANCiAg ZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+LCBpbmJvdW5kOyBCb2IsIA0K ICBvdXRib3VuZDsgQ2hhcmxpZSwgPFNQQU4gDQogIGNsYXNzPVNwZWxsRT5zZXJ2aWNlWDwvU1BB Tj48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286 cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJp YWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPlNvIHdoZW4gdGhlIENEUiBnZXRzIA0KICB3 cml0dGVuLCB0aGUgcmF0aW5nIGVuZ2luZSBsb29rcyB0aHJvdWdoIHRoZSBCaWxsaW5nIGhlYWRl ciBhbmQgYXBwbGllcyBhbGwgDQogIHRoZSByZWxldmFudCBjaGFyZ2VzIHRvIHRoZSByZWxldmFu dCBhY2NvdW50cy4gU29tZSBtYXkgYmUgcGVyIG1pbnV0ZSwgc29tZSANCiAgbWF5IGJlIGZpeGVk IGNoYXJnZXMuPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5UaGUgcHJvYmxlbXMgYXJlIA0K ICBmaXJzdCBhbmQgZm9yZW1vc3QsIHNlY3VyaXR5LiBObyBvbmUgY2FuIGFkZCB0byB0aGUgYmls bGluZyBoZWFkZXIgdW5sZXNzIHRoZXkgDQogIGFyZSB0cnVzdGVkIGVudGl0aWVzIHdpdGhpbiB5 b3VyIHN5c3RlbSwgYmVjYXVzZSBtb25leSB3aWxsIGJlIGNoYXJnZWQgYmFzZWQgDQogIG9uIHRo ZSBpbmZvcm1hdGlvbiB0aGVyZS4gU2Vjb25kLCBjYXJlIGhhcyB0byBiZSB0YWtlbiB0byBzdHJp cCBvZmYgdGhlIGhlYWRlciANCiAgd2hlbiBpdCBsZWF2ZXMgdGhlIHRydXN0ZWQgZG9tYWluIOKA kyBvdXQgdG8gdGhlIDxTUEFOIGNsYXNzPVNwZWxsRT5VQeKAmXM8L1NQQU4+IA0KICBmb3IgZXhh bXBsZS4gWW91IGRvbuKAmXQgd2FudCBwZW9wbGUga25vd2luZyB3aGF0IGlzIGdvaW5nIG9uIGlu IHlvdXIgYmlsbGluZyANCiAgc3lzdGVtLiA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48 U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZ OiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPkJ1 dCB0aGUgaWRlYSBoZXJlIGlzIA0KICB2ZXJ5IGZsZXhpYmxlIGFuZCBjYW4gdGFrZSBpbnRvIGFj Y291bnQgbWFueSB0aGluZ3MgdGhhdCB3ZSBhcmVu4oCZdCB0aGlua2luZyANCiAgYWJvdXQgbm93 LiBGb3IgZXhhbXBsZSwgd2UgbWF5IGNoYXJnZSBkaWZmZXJlbnRseSBvbmUgZGF5IGNhbGxzIHRo YXQgcmVxdWlyZSANCiAgTkFUIHRyZWF0bWVudCBvbiB0aGUgUlRQIGxldmVsICh3aGVyZSB0aGUg YmFuZHdpZHRoIGNvc3QgdG8gdGhlIGhvc3RpbmcgSVRTUCANCiAgaXMgbm90IG5lZ2xpZ2libGUp LiBXaGVuIHlvdSBmaW5kIHRoYXQgdG8gYmUgdGhlIGNhc2UsIGp1c3QgYWRkIGl0IHRvIHRoZSAN CiAgQmlsbGluZyBoZWFkZXIuIFdoYXQgYWJvdXQgaWYgY2FsbHMgYXJlIGZvcndhcmRlZCBtdWx0 aXBsZSB0aW1lcz8gS2VlcCBhZGRpbmcgDQogIGVhY2ggbGVnIHRvIHRoZSBiaWxsaW5nIGhlYWRl ci48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286 cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJp YWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPldoYXQgZG9lcyBldmVyeW9uZSANCiAgdGhp bmsgYWJvdXQgdGhpcz88bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86 cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPkJhcnVjaDxvOnA+PC9v OnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48 L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0 Ij48Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiPi0tLS0tT3JpZ2luYWwgDQogIE1lc3NhZ2UtLS0tLTxC Uj48Qj48U1BBTiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPkZyb206PC9TUEFOPjwvQj4gDQog IHNpcC1hZG1pbkBpZXRmLm9yZyBbbWFpbHRvOnNpcC1hZG1pbkBpZXRmLm9yZ10gPEI+PFNQQU4g DQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+T24gQmVoYWxmIE9mIA0KICA8L1NQQU4+PC9C PnNheWFuLmNob3dkaHVyeUB3aXByby5jb208QlI+PEI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdF SUdIVDogYm9sZCI+U2VudDo8L1NQQU4+PC9CPiBXZWRuZXNkYXksIE1heSAxOSwgMjAwNCAxOjAw IA0KICBBTTxCUj48Qj48U1BBTiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlRvOjwvU1BBTj48 L0I+IGRpZWdvYkBtYWlsdmlzaW9uLmNvbTsgDQogIGJhcnVjaEBrYXlvdGUuY29tPEJSPjxCPjxT UEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+Q2M6PC9TUEFOPjwvQj4gDQogIHNpcEBpZXRm Lm9yZzsgc2lwcGluZ0BpZXRmLm9yZzsgZmx1ZmZ5QGNpc2NvLmNvbTxCUj48Qj48U1BBTiANCiAg c3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TdWJqZWN0OjwvU1BBTj48L0I+IFJFOiBbU2lwXSBT SVAgRm9yd2FyZCwgV2hvIHBheXMgDQogIHRoZSBiaWxsID88L1NQQU4+PC9GT05UPjwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PEZPTlQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIiANCiAgc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxESVY+DQogIDxQIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgDQogIHNpemU9Mz48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5BbHNvICwg QWxpY2UgbWlnaHQgYmUgc2VuZGluZyB0aGUgDQogIHJlLWludml0ZSB0byBvbiByZWNlaXB0IG9m IGEgMzAyIGZyb20gQm9iLiBTbyB0aGUgc2V0IG9mIHByb3hpZXMgaW52bG92ZWQgaW4gDQogIHRo ZSBmaXJzdCBsZWcgb2YgdGhlIGNhbGwgbWF5IG5vdCBiZSBpbnZvbHZlZCBpbiB0aGUgc2Vjb25k IA0KICA/PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PEZPTlQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIiANCiAgc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPlNv bHV0dWlvbiB0byB0aGlzIHdpbGwgYmUgb24gdGhlIFBTVE4gDQogIGdhdGV3YXkgc2lkZS48bzpw PjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iIA0KICBzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+VGhlIFBTVE4gZ2F0 ZXdheSBzaG91bGQgbG9vayBmb3IgYW5kIGJpbGwgDQogIGZyb20gRGl2ZXJzaW9uL1JlcXVlc3Qg SGlzdG9yeS9yZW1vdGUgUGFydCBIZWFkZXIgaW5mb3JtYXRpb24gaW4gcHJlZmVyZW5jZSB0byAN CiAgdGhlIGZyb20gaGVhZGVyIHdoaWNoIGlzIHVucmVsaWFibGUgYW55IA0Kd2F5LjxvOnA+PC9v OnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg DQogIHNpemU9Mz48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5Ib3dldmVyICwgSSBkbyBu b3Qga25vdyBvZiBhbnkgc3RhbmRhcmRzIA0KICB3aGljaCBleHBsaWNpdGx5IG1lbnRpb25zIHRo YXQgLi48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIA0KICBzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5i c3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIiANCiAgc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPlJlZ2Fy ZHMgDQogICw8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iIA0KICBzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ U2F5YW48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIA0KICBzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5i c3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPEJMT0NLUVVPVEUgc3R5 bGU9Ik1BUkdJTi1UT1A6IDVwdDsgTUFSR0lOLUJPVFRPTTogNXB0OyBNQVJHSU4tUklHSFQ6IDBt bSI+DQogICAgPERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogICAgc3R5bGU9Ik1BUkdJ Ti1CT1RUT006IDEycHQ7IE1BUkdJTi1MRUZUOiAzNnB0OyBNQVJHSU4tUklHSFQ6IDBtbTsgbXNv LW1hcmdpbi10b3AtYWx0OiAwbW0iPjxGT05UIA0KICAgIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg c2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPi0tLS0tT3JpZ2luYWwgDQogICAg TWVzc2FnZS0tLS0tIDxCUj48Qj48U1BBTiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPkZyb206 PC9TUEFOPjwvQj4gDQogICAgc2lwLWFkbWluQGlldGYub3JnJm5ic3A7b24gYmVoYWxmIG9mJm5i c3A7RGllZ28gQiA8QlI+PEI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5T ZW50OjwvU1BBTj48L0I+IFR1ZSA1LzE4LzIwMDQgNzo0NCBQTSANCiAgICA8QlI+PEI+PFNQQU4g c3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5Ubzo8L1NQQU4+PC9CPiBiYXJ1Y2hAa2F5b3RlLmNv bSANCiAgICA8QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5DYzo8L1NQQU4+ PC9CPiBzaXBAaWV0Zi5vcmc7IA0KICAgICdzaXBwaW5nJzsgJ0N1bGxlbiBKZW5uaW5ncycgPEJS PjxCPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+U3ViamVjdDo8L1NQQU4+ PC9CPiBSZTogW1NpcF0gU0lQIEZvcndhcmQsIFdobyANCiAgICBwYXlzIHRoZSBiaWxsID88L1NQ QU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgIDxQIHN0eWxlPSJNQVJHSU4tTEVG VDogMzZwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+PFNQQU4gDQogICAg c3R5bGU9IkZPTlQtU0laRTogMTBwdCI+SGkgQmFydWNoOzxCUj5UaGFua3MgZm9yIHlvdXIgYW5z d2VyLjxCUj5JIGJlbGl2ZSANCiAgICB0aGF0IHlvdSBhcmUgaW1wbGVtZW50aW5nIGEgcHJvcHJp ZXRhcnkgc29sdXRpb24gdG8gZGVhbCB3aXRoIGl0LjxCUj5JJ20gDQogICAgbG9va2luZyBtb3Jl IHRvIGEgc3RhbmRhcml6ZSB3YXkgdG8gZGVhbCB3aXRoIHRoZSBzZWNvbmQtbGVnIA0KICAgIGlz c3VlLjxCUj48QlI+SSdtIGFncmVlIHRoYXQgQWxpY2UgaGFzIHRvIHBheSBmb3IgdGhlIGZpcnN0 IGxlZyBhbmQgQm9iIGZvciANCiAgICB0aGU8QlI+c2Vjb25kLCBidXQgaWYgdGhlIFByb3h5IHRo YXQgaXMgZG9pbmcgdGhlIGZvcndhcmQgaXMgbm90IGEgDQogICAgYmlsaW5nPEJSPmVudGl0eSAo IGxvY2FsIGNhbGxzIGFyZSBmcmVlLCBvdXRib3VuZCBjYWxsIGFyZSBub3QgZnJlZSBhbmQgDQog ICAgYmlsbGVkIGJ5PEJSPmFuIGV4dGVybmFsIHJlYWwtdGltZSBiaWxsaW5nIHN5c3RlbSBjb25u ZWN0ZWQgdG8gdGhlIEdXIHVzaW5nIA0KICAgIFJBRElVUyBvcjxCUj5zaW1pbGFyKSwgdGhlIFBT VE4gZ2F0ZXdheSB3aWxsIGhhdmUgdG8ga25vdyB0aGF0IHRoaXMgY2FsbCBtYXkgDQogICAgYmU8 QlI+YmlsbGVkIHRvIEJvYiBhbmQgbm90IHRvIEFsaWNlICggc2hlIGFwZWFycyBpbiB0aGUgRnJv bSBoZWFkZXIgDQogICAgKS48QlI+PEJSPlRoYW5rczxCUj48QlI+QmFydWNoIFN0ZXJtYW4gd3Jv dGU6PEJSPjxCUj4mZ3Q7IEluIHRoZSBzeXN0ZW1zIA0KICAgIHRoYXQgd2UgaW1wbGVtZW50ZWQs IHR3byBjZHJzIGFyZSBjcmVhdGVkOiB0aGUgZmlyc3QgZm9yPEJSPiZndDsgdGhlIA0KICAgIGlu Y29taW5nIGxlZyAoQWxpY2UgdG8gQm9iJ3Mgbm9uLWZvcndhcmRlZCBsb2NhdGlvbikgYW5kIGEg c2Vjb25kPEJSPiZndDsgDQogICAgZm9yIHRoZSBmb3J3YXJkIHRvIEJvYidzIGZvcndhcmRlZCBs b2NhdGlvbi48QlI+Jmd0OzxCUj4mZ3Q7IEFsaWNlIHdvdWxkIHBheSANCiAgICBmb3IgdGhlIGZp cnN0IGxlZywgYW5kIEJvYiBwYXlzIGZvciB0aGUgc2Vjb25kLjxCUj4mZ3Q7PEJSPiZndDsgRnVy dGhlcm1vcmUsIA0KICAgIGl0IG1heSBiZSB0aGUgY2FzZSB0aGF0IEJvYiBwYXlzIGZvciB0aGUg Zmlyc3QgbGVnIGFzIHdlbGwuPEJSPiZndDsgSWYsIGZvciANCiAgICBleGFtcGxlLCBCb2IgaGFz IGEgdG9sbCBmcmVlIG51bWJlciB3aGVyZSBoZSBwYXlzIHBlciBtaW51dGU8QlI+Jmd0OyBjaGFy Z2VzIA0KICAgIGZvciB0aGUgaW5ib3VuZCBsZWcgKGluIHRoaXMgY2FzZSwgQWxpY2UgaXMgb24g dGhlIFBTVE4pLjxCUj4mZ3Q7PEJSPiZndDsgDQogICAgRWl0aGVyIHdheSwgbXVsdGlwbGUgQ0RS cyBpcyB0aGUgd2F5IHdlIGNhbWUgdXAgd2l0aCB0byBoYW5kbGUgdGhpcy48QlI+Jmd0OyANCiAg ICBDYXJlIGhhcyB0byBiZSB0YWtlbiB0aGF0IHRoZSBrZXkgdG8gYW55IENEUiBkYXRhYmFzZSBp cyBOT1QgdGhlPEJSPiZndDsgDQogICAgY2FsbC1JRCwgYmVjYXVzZSB0aGlzIGlzIHRoZSBzYW1l IGFjcm9zcyB0aGUgdHdvIENEUnMuPEJSPiZndDs8QlI+Jmd0OyANCiAgICBCYXJ1Y2g8QlI+Jmd0 OzxCUj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPiZndDsgRnJvbTogDQogICAg c2lwLWFkbWluQGlldGYub3JnIFs8QSANCiAgICBocmVmPSJtYWlsdG86c2lwLWFkbWluQGlldGYu b3JnIj5tYWlsdG86c2lwLWFkbWluQGlldGYub3JnPC9BPl0gT24gQmVoYWxmIE9mIA0KICAgIERp ZWdvPEJSPiZndDsgQjxCUj4mZ3Q7IFNlbnQ6IFR1ZXNkYXksIE1heSAxOCwgMjAwNCA3OjQyIEFN PEJSPiZndDsgVG86IA0KICAgIHNpcEBpZXRmLm9yZzsgc2lwcGluZzxCUj4mZ3Q7IENjOiBDdWxs ZW4gSmVubmluZ3M8QlI+Jmd0OyBTdWJqZWN0OiBbU2lwXSBTSVAgDQogICAgRm9yd2FyZCwgV2hv IHBheXMgdGhlIGJpbGwgPzxCUj4mZ3Q7PEJSPiZndDsgSGk7PEJSPiZndDsgTXkgcXVlc3Rpb24g aXMgDQogICAgcmVnYXJkaW5nIGJpbGxpbmcgYSBmb3J3YXJkZWQgc2lwIGNhbGwuPEJSPiZndDs8 QlI+Jmd0OyBMZXRzIHRha2UgdGhlIGV4bXBsZSANCiAgICBmcm9tIGRyYWZ0LWlldGYtc2lwcGlu Zy1zZXJ2aWNlLWV4YW1wbGVzPEJSPiZndDsgMi43PEJSPiZndDs8QlI+Jmd0OyBBbGljZSANCiAg ICBjYWxscyBCb2IsIGFuZCBCb2IgaGFzIGFsbCBoaXMgaW5jb21taW5nIGNhbGxzIGZvcndhcmRl ZCB0byB0aGU8QlI+Jmd0OyANCiAgICBQU1ROLjxCUj4mZ3Q7PEJSPiZndDsgTGV0IHNheSB0aGF0 IGNhbGxzIGZyb20gQUxpY2UgdG8gQm9iIGluIHRoZSBzYW1lIA0KICAgIGRvbWFpbiBhcmUgZnJl ZSAoc2FtZTxCUj4mZ3Q7IG9mZmljZSwgb3Igc2FtZSBJVFNQKSwgYnV0IGNhbGxzIHRvIHRoZSBQ U1ROIA0KICAgIGFyZSBub3QgZnJlZS48QlI+Jmd0OzxCUj4mZ3Q7IFdobyBwYXlzIGZvciBBbGlj ZSBjYWxsIHRvIEJvYiA/PzxCUj4mZ3Q7IEluIGEgDQogICAgbm9ybWFsIHNpdHVhY2lvbiwgQWxp Y2Uga25vd3MgdGhhdCB0aGUgY2FsbCBpcyBmb3IgZnJlZSBiZWN1YXNlIA0KICAgIHNoZTxCUj4m Z3Q7PEJSPiZndDsgaXMgY2FsbGluZyBCb2IncyBzaXAgbnVtYmVyLiBCdXQgdGhlIGdhdGV3ZWF5 IG1heSBjcmVhdGUgDQogICAgQ0RSIGZyb20gdGhlPEJSPiZndDsmbmJzcDsgRnJvbSBoZWFkZXIg b2YgdGhlIFNJUCBtZXNzYWdlIGFuZCBhdCB0aGUgZW5kIG9mIA0KICAgIHRoZSBtb250aCBBbGlj ZSBtYXk8QlI+Jmd0OyBoYXZlIHRvIHBheSBmb3IgdGhlIGNhbGwuPEJSPiZndDs8QlI+Jmd0OyBJ IHNlZSANCiAgICB0aGlzIGtpbmQgb2YgZXhhbXBsZXMgaW4gc2V2ZXJhbCBvdGhlciBkcmFmdHMv UkZDIHJlbGF0ZWQgdG8gU0lQPEJSPiZndDsgDQogICAgc2VydmljZXMgYW5kIGNhbGwgZm9yd2Fy ZC48QlI+Jmd0OzxCUj4mZ3Q7IEkgYmVsaXZlIGZvcndhcmQgaXMgYSB2ZXJ5IA0KICAgIGltcG9y dGFudCBmZWF0dXJlLCBidXQgdGhpcyBpc3N1ZSBtYXkgYmU8QlI+Jmd0OyByZXNvbHZlZC4gVGhl IHF1ZXN0aW9uIGlzIA0KICAgIGlmIGl0IGlzIGEgc3RhbmRhcmQgd2F5IHRvIG1ha2UgQm9iIHBh eXMgZm9yPEJSPiZndDsgdGhlIHNlY29uZCBsZWcgb2YgdGhlIA0KICAgIGNhbGwgbGlrZSBpbiBQ U1ROIGZvcndhcmQuPEJSPiZndDs8QlI+Jmd0OyBNYXliZSBjaGFuZ2luZyB0aGUgRnJvbSBoZWFk ZXIgDQogICAgd2hlcmUgYXBwbGljYWJsZSBhbmQgYWRkaW5nIGEgbmV3IG9uZSB0bzxCUj4mZ3Q7 ICJyZW1lbWJlciIgdGhhdCB0aGUgY2FsbCBpcyANCiAgICBmcm9tLCBpbiBteSBleGFtcGxlLCBB bGljZS48QlI+Jmd0OzxCUj4mZ3Q7IFRoZSBkaXZlcnNpb24gaGVhZGVyIChEaXZlcnNpb24gDQog ICAgSW5kaWNhdGlvbiBpbiBTSVA8QlI+Jmd0OyBkcmFmdC1sZXZ5LXNpcC1kaXZlcnNpb24tMDcu dHh0KSIgbWF5IGJlIGEgDQogICAgc29sdXRpb24gaWYgdGhlIFBTVE4gZ2F0ZXdheTxCUj4mZ3Q7 IG9yIHRoZSBTSVAgQmlsbGluZyBzZXJ2ZXIgc3VwcG9ydCBpdCANCiAgICBhbmQga25vd3MgdGhh dCB0aGV5IGhhdmUgdG8gYmlsbDxCUj4mZ3Q7IHRoZSBzaXAtdXJpIGluIHRoZSBkaXZlcnNpb24g aGVhZGVyIA0KICAgICggdGhpcyBpcyByaWdodCA/Pz8gKS48QlI+Jmd0OzxCUj4mZ3Q7IA0KICAg IFJlZ2FyZHM7PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj48QlI+ LS08QlI+RGllZ28gDQogICAgQjxCUj5NYWlsVmlzaW9uIEx0ZC48QlI+VGVsLiZuYnNwOyA6IO+e vTQtODUwMDUwNSBleHQgMTM8L1NQQU4+PC9GT05UPjxGT05UIA0KICAgIGZhY2U9QmF0YW5nIHNp emU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQmF0 YW5nOyBtc28tYmlkaS1mb250LWZhbWlseTogQmF0YW5nIj48QlI+PC9TUEFOPjwvRk9OVD48Rk9O VCANCiAgICBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+ZS1tYWlsOiANCiAg ICBkaWVnb2JAbWFpbHZpc2lvbi5jb208L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9QmF0YW5nIHNp emU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQmF0 YW5nOyBtc28tYmlkaS1mb250LWZhbWlseTogQmF0YW5nIj48QlI+PC9TUEFOPjwvRk9OVD48Rk9O VCANCiAgICBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+d2ViJm5ic3A7Jm5i c3A7IDogPEEgDQogICAgaHJlZj0iaHR0cHM6Ly9nYXRld2F5LWluZGlhLndpcHJvLmNvbS8sRGFu YUluZm89d3d3Lm1haWx2aXNpb24uY29tIj5odHRwOi8vd3d3Lm1haWx2aXNpb24uY29tPC9BPjxC Uj48QlI+PEJSPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxCUj5TaXAgDQogICAgbWFpbGluZyBsaXN0Jm5ic3A7IDxBIA0KICAgIGhyZWY9Imh0dHBz Oi8vZ2F0ZXdheS1pbmRpYS53aXByby5jb20vbWFpbG1hbi9saXN0aW5mby9zaXAsRGFuYUluZm89 d3d3MS5pZXRmLm9yZyxTU0wiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpcDwvQT48QlI+VGhpcyANCiAgICBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhl IGNvcmUgU0lQIFByb3RvY29sPEJSPlVzZSANCiAgICBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVt YmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwPEJSPlVzZSANCiAgICBzaXBwaW5n QGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiANCiAg ICBzaXA8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvQkxPQ0tRVU9URT48L0RJVj48L0JM T0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C43E0C.B427AD59-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 19 22:49:44 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07726 for ; Wed, 19 May 2004 22:49:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQdbO-0006nY-OO for sipping-archive@odin.ietf.org; Wed, 19 May 2004 22:48:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K2mAa3026125 for sipping-archive@odin.ietf.org; Wed, 19 May 2004 22:48:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQdYj-0005qA-6I for sipping-web-archive@optimus.ietf.org; Wed, 19 May 2004 22:45:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07414 for ; Wed, 19 May 2004 22:45:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQdYf-0005SC-RO for sipping-web-archive@ietf.org; Wed, 19 May 2004 22:45:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQdXv-0005JG-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 22:44:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQdWs-0005AX-00 for sipping-web-archive@ietf.org; Wed, 19 May 2004 22:43:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQdSZ-0004Oi-Ik; Wed, 19 May 2004 22:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQdNw-0002Ux-V2 for sipping@optimus.ietf.org; Wed, 19 May 2004 22:34:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07000 for ; Wed, 19 May 2004 22:34:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQdNt-0003pF-EK for sipping@ietf.org; Wed, 19 May 2004 22:34:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQdN0-0003hE-00 for sipping@ietf.org; Wed, 19 May 2004 22:33:18 -0400 Received: from bruiser.bcentralhost.com ([205.158.154.152]) by ietf-mx with esmtp (Exim 4.12) id 1BQdME-0003Z4-00; Wed, 19 May 2004 22:32:30 -0400 Received: from psnwxp014 (CPE000874076800-CM000039edf45e.cpe.net.cable.rogers.com [69.196.18.99]) by bruiser.bcentralhost.com id WAA11389; Wed, 19 May 2004 22:32:29 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200405200232.WAA11389@bruiser.bcentralhost.com> From: "Michael Herman \(Parallelspace/Office\)" To: , Date: Wed, 19 May 2004 22:31:20 -0400 Organization: Parallelspace Corporation MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C43DF1.0344F500" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <006d01c43d86$44d46a20$f7aaaad0@BaruchLaptop> Thread-Index: AcQ950192YBi7qmTR/uiyfnRAyedAgAKrInA Subject: [Sipping] ECMA 323 over 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.3 required=5.0 tests=AWL,HTML_70_80, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C43DF1.0344F500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Apologies for possibly sending this to the wrong email distribution lists ... Q: Does anyone know where I can find information about ECMA 232 and tunneling it over SIP? Thank you in advance (and my apologies if these are the wrong lists or if the list memberships are extraordinarily large), ---------- Michael Herman Parallelspace Corporation Developers of Advanced Business Collaboration Solutions for Microsoft SharePoint, Microsoft Live Communications Server and Groove Workspace Portal and Content Migration Solution Specialists: http://www.parallelspace.net/sharepoint SharePoint Migration Knowledge Center: http://groups.yahoo.com/group/sharepointmigration ------=_NextPart_000_0012_01C43DF1.0344F500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Sip] SIP = Forward, Who pays the bill ?
Apologies for possibly sending this to the = wrong email=20 distribution lists ...
 
Q: Does anyone know where I can find = information=20 about ECMA 232 and tunneling it over SIP?
 
 
 
Thank you in advance (and my apologies if = these are the=20 wrong lists or if the list memberships are extraordinarily=20 large),

----------
Michael Herman
Parallelspace = Corporation
Developers of=20 Advanced Business Collaboration Solutions for Microsoft SharePoint, = Microsoft=20 Live Communications Server and Groove Workspace

Portal and Content Migration = Solution=20 Specialists: http://www.parallelspace.net/sharepoint<= /U>
SharePoint Migration Knowledge Center: = http://groups.yahoo.com/group/sharepointmigration

------=_NextPart_000_0012_01C43DF1.0344F500-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 20 12:06:18 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27960 for ; Thu, 20 May 2004 12:06:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQply-0001as-Ef for sipping-archive@odin.ietf.org; Thu, 20 May 2004 11:47:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KFlsGY006126 for sipping-archive@odin.ietf.org; Thu, 20 May 2004 11:47:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpSJ-0001VK-47 for sipping-web-archive@optimus.ietf.org; Thu, 20 May 2004 11:27:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23567 for ; Thu, 20 May 2004 11:27:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpSG-0003re-H9 for sipping-web-archive@ietf.org; Thu, 20 May 2004 11:27:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpQo-0003eV-00 for sipping-web-archive@ietf.org; Thu, 20 May 2004 11:26:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQpPI-0003Sv-00 for sipping-web-archive@ietf.org; Thu, 20 May 2004 11:24:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQp6F-0004PX-E8; Thu, 20 May 2004 11:04:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQn2S-0002V4-G8 for sipping@optimus.ietf.org; Thu, 20 May 2004 08:52:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15027 for ; Thu, 20 May 2004 08:52:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQn2R-0001Nn-2j for sipping@ietf.org; Thu, 20 May 2004 08:52:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQn1U-0001Bs-00 for sipping@ietf.org; Thu, 20 May 2004 08:51:45 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1BQn19-000101-00 for sipping@ietf.org; Thu, 20 May 2004 08:51:23 -0400 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 i4KCpFdT027994; Thu, 20 May 2004 21:51:15 +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 i4KCpETM026421; Thu, 20 May 2004 21:51:14 +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 i4KCpEWB023490; Thu, 20 May 2004 21:51:14 +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 i4KCpEHm023487; Thu, 20 May 2004 21:51:14 +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 i4KCpDjo003677; Thu, 20 May 2004 21:51:13 +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 VAA11147; Thu, 20 May 2004 21:51:13 +0900 (JST) Received: from lab.ntt.co.jp by img.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with SMTP id VAA07081; Thu, 20 May 2004 21:51:12 +0900 (JST) From: Kumiko Ono To: Volker Hilt Cc: sipping@ietf.org Date: Thu, 20 May 2004 21:50:52 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 3.52 (WinNT,501) In-Reply-To: <40AA06BD.8090508@bell-labs.com> References: <40AA06BD.8090508@bell-labs.com> Message-Id: Content-Transfer-Encoding: 7bit Subject: [Sipping] Considerations for Session Policies Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 and Gonzalo, I read "draft-hilt-sipping-consider-policy-00" with great interest. Here are few comments. Section 1: Is there any order of the two operations? I think the diclosing operation of the UA usually needs to be done before receiving the instruction of session-specific policy. In addition, we need separate messages to diclose media information, such as SUBSCRIBE, in order to avoid "ghost ring" in the case as shown in Figure 2. Do you have any idea to avoid "ghost ring"? Do we need the other operation that the proxies see if the session follows the instruction of policies? Section 2-4: Your proposal is to use the redirect model for session-specific policies. In my understanding, the two models have the pros and cons as follows: Piggyback model vs. Redirect model *Piggyback pros. - Less messages to establish a session. - Easy to correlate a session and the policy. In this case, the policy is session-specific. cons. - UA needs to set media information to be protected for end-to-middle in request/response. - Proxy needs to add policy information to be protected for middle-to- end in request/response. - It is too late to enforce the policy to the SDP offer/anwer in 200/ACK messages. - Policy information is transmitted to a different network. - Hard to apply to policy changes during a session. The session timer mechanism could be used. *Redirect model pros. - Policy information can be protected for end-to-end, that is between a UA and a policy server. - Policy information is not transmitted outside of the network that has the policy. - Easy to apply to policy changes during a session. cons. - More messages to establish a session. A UAC can know the server with the error code for the request. However, How does a UAS know the server to have session policy? - Hard to correlate a session and the policy. The message of session-specific policy instruction are different from messages of session establishment. How does the proxy server determine what policy is instructed to the session? I don't know how the redirect model works on 3pcc control that needs the SDP offer/answer in 200/ACK messages. If the UA discloses the media information to the proxy using different messages before sending "200 OK", the redirect model can be benefical in this case. However, I don't know whether this is applicable to 3pcc control. Thanks a lot, Kumiko -- 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 Thu May 20 14:25: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 OAA09268 for ; Thu, 20 May 2004 14:25:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsAU-00074l-Fd for sipping-archive@odin.ietf.org; Thu, 20 May 2004 14:21:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KILMnG027200 for sipping-archive@odin.ietf.org; Thu, 20 May 2004 14:21:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrzR-0004Q9-Dc for sipping-web-archive@optimus.ietf.org; Thu, 20 May 2004 14:09:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07996 for ; Thu, 20 May 2004 14:09:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQrzP-00065G-30 for sipping-web-archive@ietf.org; Thu, 20 May 2004 14:09:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQryU-00060v-00 for sipping-web-archive@ietf.org; Thu, 20 May 2004 14:08:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQrxk-0005wl-00 for sipping-web-archive@ietf.org; Thu, 20 May 2004 14:08:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrj3-0008NK-I9; Thu, 20 May 2004 13:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQre7-0006zp-Qc for sipping@optimus.ietf.org; Thu, 20 May 2004 13:47:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06300 for ; Thu, 20 May 2004 13:47:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQre5-0003mm-I9 for sipping@ietf.org; Thu, 20 May 2004 13:47:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQrd7-0003hC-00 for sipping@ietf.org; Thu, 20 May 2004 13:46:54 -0400 Received: from glatton.cnchost.com ([207.155.248.47]) by ietf-mx with esmtp (Exim 4.12) id 1BQrcq-0003de-00 for sipping@ietf.org; Thu, 20 May 2004 13:46:36 -0400 Received: from MedhaviLT (61.79.219.209.transedge.com [209.219.79.61]) by glatton.cnchost.com id NAA13410; Thu, 20 May 2004 13:46:35 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] Message-ID: <200405201746.NAA13410@glatton.cnchost.com> Reply-To: From: "Medhavi Bhatia" To: Date: Thu, 20 May 2004 13:46:35 -0400 Organization: NexTone Communications MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04C5_01C43E70.DEC0C0D0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcQ+kmU9ULShdEU9RwCVA3D8cPA3xw== Subject: [Sipping] status of draft-ietf-sipping-realtimefax-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,HTML_70_80,HTML_MESSAGE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_04C5_01C43E70.DEC0C0D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Is this work incorporated as part of another draft ? Thanks - Medhavi ------=_NextPart_000_04C5_01C43E70.DEC0C0D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is this work incorporated as part of another draft = ?

 

Thanks

- Medhavi

------=_NextPart_000_04C5_01C43E70.DEC0C0D0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 20 16:07:31 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17638 for ; Thu, 20 May 2004 16:07:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtlF-0004Yw-48 for sipping-archive@odin.ietf.org; Thu, 20 May 2004 16:03:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KK3PCo017534 for sipping-archive@odin.ietf.org; Thu, 20 May 2004 16:03:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtcT-0002Wi-9M for sipping-web-archive@optimus.ietf.org; Thu, 20 May 2004 15:54:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16412 for ; Thu, 20 May 2004 15:54:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQtcR-0005yq-Q2 for sipping-web-archive@ietf.org; Thu, 20 May 2004 15:54:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQtbT-0005tv-00 for sipping-web-archive@ietf.org; Thu, 20 May 2004 15:53:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQtas-0005ob-00 for sipping-web-archive@ietf.org; Thu, 20 May 2004 15:52:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtSW-0007Oi-Ai; Thu, 20 May 2004 15:44:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtOP-0006Qd-Av for sipping@optimus.ietf.org; Thu, 20 May 2004 15:39:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15299 for ; Thu, 20 May 2004 15:39:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQtON-00052E-TZ for sipping@ietf.org; Thu, 20 May 2004 15:39:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQtNP-0004vS-00 for sipping@ietf.org; Thu, 20 May 2004 15:38:47 -0400 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 1BQtMR-0004qG-00 for sipping@ietf.org; Thu, 20 May 2004 15:37:47 -0400 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 i4KJbFDe008039; Thu, 20 May 2004 12:37:15 -0700 (PDT) Received: from [128.107.170.69] ([128.107.170.69]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id APC96266; Thu, 20 May 2004 12:37:14 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 20 May 2004 12:37:14 -0700 Subject: Re: [Sipping] Exploders drafts From: Cullen Jennings To: Miguel Garcia CC: , sipping Message-ID: In-Reply-To: <40AB31DE.1010903@nokia.com> 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: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 5/19/04 3:07 AM, "Miguel Garcia" wrote: >> >> The " The MESSAGE exploder MUST NOT copy any security body (such as an >> S/MIME signed body) addressed to the MESSAGE exploder to the >> outgoing MESSAGE request. This includes, e.g., security bodies >> signed with the public key of the exploder." >> This confuses me. If it was signed, it would be signed with the public key >> of the UA sending the request to the exploder? I'm just not sure what you >> are getting at with this. Is this the exploder must not relay any S/MIME >> body? > > This is obviously wrong. The text shold speak about an "encrypted body" > and "bodies encrypted with the public key of the explodr". > > The idea is very simple: if the exploder is able to decrypt an encrypted > body, it should not copy that encrypted body to the outgoing request, > since the receiver will not be able to decrypted. I get it now - thanks. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 20 16:16:35 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18197 for ; Thu, 20 May 2004 16:16:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtnB-0005G5-QE for sipping-archive@odin.ietf.org; Thu, 20 May 2004 16:05:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KK5P9m020207 for sipping-archive@odin.ietf.org; Thu, 20 May 2004 16:05:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtho-0003KE-Tn for sipping-web-archive@optimus.ietf.org; Thu, 20 May 2004 15:59:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16752 for ; Thu, 20 May 2004 15:59:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQthn-0006Gh-BV for sipping-web-archive@ietf.org; Thu, 20 May 2004 15:59:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQtgp-0006F1-00 for sipping-web-archive@ietf.org; Thu, 20 May 2004 15:58:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQtg0-0006Dj-00 for sipping-web-archive@ietf.org; Thu, 20 May 2004 15:58:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtaF-0000jR-8i; Thu, 20 May 2004 15:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtRZ-00073C-C5 for sipping@optimus.ietf.org; Thu, 20 May 2004 15:43:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15685 for ; Thu, 20 May 2004 15:43:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQtRX-0005IX-Ro for sipping@ietf.org; Thu, 20 May 2004 15:43:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQtQh-0005FN-00 for sipping@ietf.org; Thu, 20 May 2004 15:42:12 -0400 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 1BQtQG-0005BV-00 for sipping@ietf.org; Thu, 20 May 2004 15:41:44 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 May 2004 11:48:55 +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 i4KJfCf9018920; Thu, 20 May 2004 12:41:12 -0700 (PDT) Received: from [128.107.170.69] ([128.107.170.69]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id APC96601; Thu, 20 May 2004 12:41:11 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 20 May 2004 12:41:10 -0700 Subject: Re: [Sipping] Exploders drafts From: Cullen Jennings To: Miguel Garcia CC: , sipping Message-ID: In-Reply-To: <40AB31DE.1010903@nokia.com> 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: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 5/19/04 3:07 AM, "Miguel Garcia" wrote: >> On draft-garcia-sipping-message-exploder-00.txt >> >> The embedded headers in the URI are nice but raise lots of issues. For >> example, if I insert a P-Asserted-Identity header with a fake name, will it >> be used? Or perhaps a Route header that caused the message to go to someone >> that had not agreed to receive exploded messages. > > First, this issue is applicable not only to the MESSAGE exploder draft, > but to any other exploder document. It can happen with INVITE, SUBSCRIBE > or REFER as well. > > Second, the exploder implements a SIP UA functionality, meaning that if > implements RFC 3325, it is able to distinguish when the > P-Asserted-Identity is trusted or not, as required by the RFC. Based on > this trustness of the asserted identity, the exploder may implement > local policy to pass the header to the other side or not. Ok, Seems like some text is needed. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 20 17:44: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 RAA28198 for ; Thu, 20 May 2004 17:44:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvAD-0007uG-3H for sipping-archive@odin.ietf.org; Thu, 20 May 2004 17:33:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KLXHFv030392 for sipping-archive@odin.ietf.org; Thu, 20 May 2004 17:33:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQuwx-0001L1-4W for sipping-web-archive@optimus.ietf.org; Thu, 20 May 2004 17:19:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25723 for ; Thu, 20 May 2004 17:19:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQuwu-0007h9-Tz for sipping-web-archive@ietf.org; Thu, 20 May 2004 17:19:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQuuv-0007Os-00 for sipping-web-archive@ietf.org; Thu, 20 May 2004 17:17:32 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQusd-00073c-02 for sipping-web-archive@ietf.org; Thu, 20 May 2004 17:15:07 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQugj-0004ue-SU for sipping-web-archive@ietf.org; Thu, 20 May 2004 17:02:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtpA-0005gk-Tm; Thu, 20 May 2004 16:07:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtk8-0003VH-MA for sipping@optimus.ietf.org; Thu, 20 May 2004 16:02:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17152; Thu, 20 May 2004 16:02:13 -0400 (EDT) Message-Id: <200405202002.QAA17152@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 20 May 2004 16:02:13 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-kpml-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.5 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 Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML) Author(s) : E. Burger, M. Dolly Filename : draft-ietf-sipping-kpml-03.txt Pages : 42 Date : 2004-5-20 The Key Press Stimulus Event Package is a component of the Applications Interaction Framework for the Session Initiation Protocol (SIP). The event package defines a Key Press Markup Language (KPML) that describes filter specifications for reporting key presses entered at a presentation-free user interface SIP User Agent (UA). The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers). We recommend using VoiceXML or MSCML, as described in the Applications Interaction Framework, for building interactive voice response applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-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-kpml-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-5-20152746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-kpml-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-kpml-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-20152746.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 May 20 17: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 RAA29144 for ; Thu, 20 May 2004 17:58:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvOF-00061T-Tt for sipping-archive@odin.ietf.org; Thu, 20 May 2004 17:47:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KLlllC023147 for sipping-archive@odin.ietf.org; Thu, 20 May 2004 17:47:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvBj-0008QG-Vm for sipping-web-archive@optimus.ietf.org; Thu, 20 May 2004 17:34:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27572 for ; Thu, 20 May 2004 17:34:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQvBh-00021p-J1 for sipping-web-archive@ietf.org; Thu, 20 May 2004 17:34:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQvAe-0001uG-00 for sipping-web-archive@ietf.org; Thu, 20 May 2004 17:33:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQv9L-0001lP-00 for sipping-web-archive@ietf.org; Thu, 20 May 2004 17:32:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQuoh-0007sH-6d; Thu, 20 May 2004 17:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQuLn-0002fO-CB for sipping@optimus.ietf.org; Thu, 20 May 2004 16:41:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20586 for ; Thu, 20 May 2004 16:41:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQuLl-0001vi-6S for sipping@ietf.org; Thu, 20 May 2004 16:41:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQuKM-0001he-00 for sipping@ietf.org; Thu, 20 May 2004 16:39:44 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BQuJ4-0001Qe-00; Thu, 20 May 2004 16:38:22 -0400 Received: from dynamicsoft.com ([63.113.46.118]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4KKatbo005987; Thu, 20 May 2004 16:36:55 -0400 (EDT) Message-ID: <40AD16CA.7050407@dynamicsoft.com> Date: Thu, 20 May 2004 16:36:26 -0400 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: "Roy, Radhika R, ALABS" CC: baruch@kayote.com, sayan.chowdhury@wipro.com, diegob@mailvision.com, sip@ietf.org, sipping@ietf.org, fluffy@cisco.com Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? References: <34DA635B184A644DA4588E260EC0A25A07217374@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A07217374@ACCLUST02EVS1.ugd.att.com> 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 i4KKatbo005987 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 To be clear, Baruch is proposing a new SIP header, which the SIP WG=20 would need to worry about. I do not think such a thing is needed. As Keith pointed out, our=20 philosophy to date (and this is a broader IETF thing too), is to make=20 sure that you can *account* for what has happened. That is, that the=20 protocols contain sufficient information to record what transpired in a=20 call/transaction/dialog or whatever. Then, its someone elses problem=20 (for example, 3gpp) to specify how the appropriate information is=20 collected, what billing model is used, and how a CDR is generated. Not=20 to say that these things arent important, they're just not the SIP=20 working group's problem. -Jonathan R. Roy, Radhika R, ALABS wrote: > I agree with Baruch that AAA group is working for authentication,=20 > authorization, and accounting of applications including SIP, and there=20 > is enough room to build CDRs/Billing based on those things. So, SIP WG=20 > does not need to be worried for this. > =20 > Radhika R. Roy > rrroy@att.com >=20 > -----Original Message----- > *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org]*On Behalf Of > *Baruch Sterman > *Sent:* Wednesday, May 19, 2004 5:47 AM > *To:* sayan.chowdhury@wipro.com; diegob@mailvision.com > *Cc:* sip@ietf.org; sipping@ietf.org; fluffy@cisco.com > *Subject:* RE: [Sip] SIP Forward, Who pays the bill ? >=20 > Another avenue that can be explored is an explicit header to deal > with this and other accounting issues. I think that the AAA group > has suggested an ACCOUNTING header. We were thinking of a BILLING > header. In that header you would have a username and type. So as th= e > call progresses you could add to that header. This would also allow > to charge for various services along the way. Imagine the following. > Alice calls Bob, Bob forwards to Charlie who requires an ENUM looku= p > to find his IP =E2=80=93 and you are dealing with a psychotic ITSP = that > **Charges** for ENUM listing. >=20 > Inbound Alice -> Bob Billing: Alice, inbound >=20 > Forward Bob -> Charlie Billing: Alice, inbound; Bob, outbound >=20 > ITSP looks up Charlie Billing: Alice, inbound; Bob, outbound= ; > Charlie, serviceX >=20 > =20 >=20 > So when the CDR gets written, the rating engine looks through the > Billing header and applies all the relevant charges to the relevant > accounts. Some may be per minute, some may be fixed charges. >=20 > =20 >=20 > The problems are first and foremost, security. No one can add to th= e > billing header unless they are trusted entities within your system, > because money will be charged based on the information there. > Second, care has to be taken to strip off the header when it leaves > the trusted domain =E2=80=93 out to the UA=E2=80=99s for example. Y= ou don=E2=80=99t want > people knowing what is going on in your billing system. >=20 > =20 >=20 > But the idea here is very flexible and can take into account many > things that we aren=E2=80=99t thinking about now. For example, we m= ay charge > differently one day calls that require NAT treatment on the RTP > level (where the bandwidth cost to the hosting ITSP is not > negligible). When you find that to be the case, just add it to the > Billing header. What about if calls are forwarded multiple times? > Keep adding each leg to the billing header. >=20 > =20 >=20 > What does everyone think about this? >=20 > =20 >=20 > Baruch >=20 > =20 >=20 > -----Original Message----- > *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org] *On Behalf O= f > *sayan.chowdhury@wipro.com > *Sent:* Wednesday, May 19, 2004 1:00 AM > *To:* diegob@mailvision.com; baruch@kayote.com > *Cc:* sip@ietf.org; sipping@ietf.org; fluffy@cisco.com > *Subject:* RE: [Sip] SIP Forward, Who pays the bill ? >=20 > =20 >=20 > Also , Alice might be sending the re-invite to on receipt of a 302 > from Bob. So the set of proxies invloved in the first leg of the > call may not be involved in the second ? >=20 > Solutuion to this will be on the PSTN gateway side. >=20 > The PSTN gateway should look for and bill from Diversion/Request > History/remote Part Header information in preference to the from > header which is unreliable any way. >=20 > However , I do not know of any standards which explicitly mentions > that .. >=20 > =20 >=20 > Regards , >=20 > Sayan >=20 > =20 >=20 > -----Original Message----- > *From:* sip-admin@ietf.org on behalf of Diego B > *Sent:* Tue 5/18/2004 7:44 PM > *To:* baruch@kayote.com > *Cc:* sip@ietf.org; 'sipping'; 'Cullen Jennings' > *Subject:* Re: [Sip] SIP Forward, Who pays the bill ? >=20 > Hi Baruch; > Thanks for your answer. > I belive that you are implementing a proprietary solution to > deal with it. > I'm looking more to a standarize way to deal with the second-le= g > issue. >=20 > I'm agree that Alice has to pay for the first leg and Bob for t= he > second, but if the Proxy that is doing the forward is not a bil= ing > entity ( local calls are free, outbound call are not free and > billed by > an external real-time billing system connected to the GW using > RADIUS or > similar), the PSTN gateway will have to know that this call may= be > billed to Bob and not to Alice ( she apears in the From header = ). >=20 > Thanks >=20 > Baruch Sterman wrote: >=20 >> In the systems that we implemented, two cdrs are created: the > first for >> the incoming leg (Alice to Bob's non-forwarded location) and a > second >> for the forward to Bob's forwarded location. >> >> Alice would pay for the first leg, and Bob pays for the second. >> >> Furthermore, it may be the case that Bob pays for the first > leg as well. >> If, for example, Bob has a toll free number where he pays per > minute >> charges for the inbound leg (in this case, Alice is on the PSTN). >> >> Either way, multiple CDRs is the way we came up with to handle > this. >> Care has to be taken that the key to any CDR database is NOT the >> call-ID, because this is the same across the two CDRs. >> >> Baruch >> >> -----Original Message----- >> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf > Of Diego >> B >> Sent: Tuesday, May 18, 2004 7:42 AM >> To: sip@ietf.org; sipping >> Cc: Cullen Jennings >> Subject: [Sip] SIP Forward, Who pays the bill ? >> >> Hi; >> My question is regarding billing a forwarded sip call. >> >> Lets take the exmple from draft-ietf-sipping-service-examples >> 2.7 >> >> Alice calls Bob, and Bob has all his incomming calls forwarded > to the >> PSTN. >> >> Let say that calls from ALice to Bob in the same domain are > free (same >> office, or same ITSP), but calls to the PSTN are not free. >> >> Who pays for Alice call to Bob ?? >> In a normal situacion, Alice knows that the call is for free > becuase she >> >> is calling Bob's sip number. But the gateweay may create CDR > from the >> From header of the SIP message and at the end of the month > Alice may >> have to pay for the call. >> >> I see this kind of examples in several other drafts/RFC > related to SIP >> services and call forward. >> >> I belive forward is a very important feature, but this issue > may be >> resolved. The question is if it is a standard way to make Bob > pays for >> the second leg of the call like in PSTN forward. >> >> Maybe changing the From header where applicable and adding a > new one to >> "remember" that the call is from, in my example, Alice. >> >> The diversion header (Diversion Indication in SIP >> draft-levy-sip-diversion-07.txt)" may be a solution if the > PSTN gateway >> or the SIP Billing server support it and knows that they have > to bill >> the sip-uri in the diversion header ( this is right ??? ). >> >> Regards; >> >> >> >> >> >=20 > -- > Diego B > MailVision Ltd. > Tel. : =EF=9E=BD4-8500505 ext 13 > e-mail: diegob@mailvision.com > web : http://www.mailvision.com > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current s= ip > Use sipping@ietf.org for new developments on the application of= sip >=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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 20 23:58: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 XAA17848 for ; Thu, 20 May 2004 23:58:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR19C-0006CU-B6 for sipping-archive@odin.ietf.org; Thu, 20 May 2004 23:56:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L3ucDA023834 for sipping-archive@odin.ietf.org; Thu, 20 May 2004 23:56:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR15r-0005NT-NI for sipping-web-archive@optimus.ietf.org; Thu, 20 May 2004 23:53:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17706 for ; Thu, 20 May 2004 23:53:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR15p-0001ob-IT for sipping-web-archive@ietf.org; Thu, 20 May 2004 23:53:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR151-0001jK-00 for sipping-web-archive@ietf.org; Thu, 20 May 2004 23:52:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR145-0001eH-00 for sipping-web-archive@ietf.org; Thu, 20 May 2004 23:51:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR0tP-0002nB-7U; Thu, 20 May 2004 23:40:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR0pd-0001aR-Tt for sipping@optimus.ietf.org; Thu, 20 May 2004 23:36:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16785 for ; Thu, 20 May 2004 23:36:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR0pb-0007kE-NV for sipping@ietf.org; Thu, 20 May 2004 23:36:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR0oc-0007dm-00 for sipping@ietf.org; Thu, 20 May 2004 23:35:24 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BR0o5-0007VU-00; Thu, 20 May 2004 23:34:49 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 20 May 2004 20:32:52 -0700 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 i4L3YHf9008880; Thu, 20 May 2004 20:34:17 -0700 (PDT) Received: from [10.0.1.3] (sjc-vpn3-1222.cisco.com [10.21.68.198]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id APD35066; Thu, 20 May 2004 20:34:15 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 20 May 2004 20:33:12 -0700 Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? From: Cullen Jennings To: Jonathan Rosenberg , "Roy, Radhika R, ALABS" CC: , , , , Message-ID: In-Reply-To: <40AD16CA.7050407@dynamicsoft.com> Mime-version: 1.0 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Agree but wanted to add one little wrinkle that has been frustrating. In SIP, things like the call-id are often used to help figure out what has happened to the call. However, these are often selected by the UA with very little constraints on them. Most SIP systems allow call-id to be infinitely long, but most radius billing systems and databases used for correlation of billing records use fields with some fixed maximum length. Implementers should be aware of attacks based on this. Allowing the user (instead of the network) to pick the identifier used to correlate billing information is no= t the most desirable things from a security point of view. Cullen On 5/20/04 1:36 PM, "Jonathan Rosenberg" wrote: > To be clear, Baruch is proposing a new SIP header, which the SIP WG > would need to worry about. >=20 > I do not think such a thing is needed. As Keith pointed out, our > philosophy to date (and this is a broader IETF thing too), is to make > sure that you can *account* for what has happened. That is, that the > protocols contain sufficient information to record what transpired in a > call/transaction/dialog or whatever. Then, its someone elses problem > (for example, 3gpp) to specify how the appropriate information is > collected, what billing model is used, and how a CDR is generated. Not > to say that these things arent important, they're just not the SIP > working group's problem. >=20 > -Jonathan R. >=20 > Roy, Radhika R, ALABS wrote: >=20 >> I agree with Baruch that AAA group is working for authentication, >> authorization, and accounting of applications including SIP, and there >> is enough room to build CDRs/Billing based on those things. So, SIP WG >> does not need to be worried for this. >> =20 >> Radhika R. Roy >> rrroy@att.com >>=20 >> -----Original Message----- >> *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org]*On Behalf Of >> *Baruch Sterman >> *Sent:* Wednesday, May 19, 2004 5:47 AM >> *To:* sayan.chowdhury@wipro.com; diegob@mailvision.com >> *Cc:* sip@ietf.org; sipping@ietf.org; fluffy@cisco.com >> *Subject:* RE: [Sip] SIP Forward, Who pays the bill ? >>=20 >> Another avenue that can be explored is an explicit header to deal >> with this and other accounting issues. I think that the AAA group >> has suggested an ACCOUNTING header. We were thinking of a BILLING >> header. In that header you would have a username and type. So as the >> call progresses you could add to that header. This would also allow >> to charge for various services along the way. Imagine the following. >> Alice calls Bob, Bob forwards to Charlie who requires an ENUM lookup >> to find his IP =AD and you are dealing with a psychotic ITSP that >> **Charges** for ENUM listing. >>=20 >> Inbound Alice -> Bob Billing: Alice, inbound >>=20 >> Forward Bob -> Charlie Billing: Alice, inbound; Bob, outbound >>=20 >> ITSP looks up Charlie Billing: Alice, inbound; Bob, outbound; >> Charlie, serviceX >>=20 >> =20 >>=20 >> So when the CDR gets written, the rating engine looks through the >> Billing header and applies all the relevant charges to the relevant >> accounts. Some may be per minute, some may be fixed charges. >>=20 >> =20 >>=20 >> The problems are first and foremost, security. No one can add to the >> billing header unless they are trusted entities within your system, >> because money will be charged based on the information there. >> Second, care has to be taken to strip off the header when it leaves >> the trusted domain =AD out to the UA=B9s for example. You don=B9t want >> people knowing what is going on in your billing system. >>=20 >> =20 >>=20 >> But the idea here is very flexible and can take into account many >> things that we aren=B9t thinking about now. For example, we may charge >> differently one day calls that require NAT treatment on the RTP >> level (where the bandwidth cost to the hosting ITSP is not >> negligible). When you find that to be the case, just add it to the >> Billing header. What about if calls are forwarded multiple times? >> Keep adding each leg to the billing header. >>=20 >> =20 >>=20 >> What does everyone think about this? >>=20 >> =20 >>=20 >> Baruch >>=20 >> =20 >>=20 >> -----Original Message----- >> *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org] *On Behalf Of >> *sayan.chowdhury@wipro.com >> *Sent:* Wednesday, May 19, 2004 1:00 AM >> *To:* diegob@mailvision.com; baruch@kayote.com >> *Cc:* sip@ietf.org; sipping@ietf.org; fluffy@cisco.com >> *Subject:* RE: [Sip] SIP Forward, Who pays the bill ? >>=20 >> =20 >>=20 >> Also , Alice might be sending the re-invite to on receipt of a 302 >> from Bob. So the set of proxies invloved in the first leg of the >> call may not be involved in the second ? >>=20 >> Solutuion to this will be on the PSTN gateway side. >>=20 >> The PSTN gateway should look for and bill from Diversion/Request >> History/remote Part Header information in preference to the from >> header which is unreliable any way. >>=20 >> However , I do not know of any standards which explicitly mentions >> that .. >>=20 >> =20 >>=20 >> Regards , >>=20 >> Sayan >>=20 >> =20 >>=20 >> -----Original Message----- >> *From:* sip-admin@ietf.org on behalf of Diego B >> *Sent:* Tue 5/18/2004 7:44 PM >> *To:* baruch@kayote.com >> *Cc:* sip@ietf.org; 'sipping'; 'Cullen Jennings' >> *Subject:* Re: [Sip] SIP Forward, Who pays the bill ? >>=20 >> Hi Baruch; >> Thanks for your answer. >> I belive that you are implementing a proprietary solution to >> deal with it. >> I'm looking more to a standarize way to deal with the second-leg >> issue. >>=20 >> I'm agree that Alice has to pay for the first leg and Bob for th= e >> second, but if the Proxy that is doing the forward is not a bili= ng >> entity ( local calls are free, outbound call are not free and >> billed by >> an external real-time billing system connected to the GW using >> RADIUS or >> similar), the PSTN gateway will have to know that this call may = be >> billed to Bob and not to Alice ( she apears in the From header )= . >>=20 >> Thanks >>=20 >> Baruch Sterman wrote: >>=20 >>> In the systems that we implemented, two cdrs are created: the >> first for >>> the incoming leg (Alice to Bob's non-forwarded location) and a >> second >>> for the forward to Bob's forwarded location. >>>=20 >>> Alice would pay for the first leg, and Bob pays for the second. >>>=20 >>> Furthermore, it may be the case that Bob pays for the first >> leg as well. >>> If, for example, Bob has a toll free number where he pays per >> minute >>> charges for the inbound leg (in this case, Alice is on the PSTN). >>>=20 >>> Either way, multiple CDRs is the way we came up with to handle >> this. >>> Care has to be taken that the key to any CDR database is NOT the >>> call-ID, because this is the same across the two CDRs. >>>=20 >>> Baruch >>>=20 >>> -----Original Message----- >>> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf >> Of Diego >>> B >>> Sent: Tuesday, May 18, 2004 7:42 AM >>> To: sip@ietf.org; sipping >>> Cc: Cullen Jennings >>> Subject: [Sip] SIP Forward, Who pays the bill ? >>>=20 >>> Hi; >>> My question is regarding billing a forwarded sip call. >>>=20 >>> Lets take the exmple from draft-ietf-sipping-service-examples >>> 2.7 >>>=20 >>> Alice calls Bob, and Bob has all his incomming calls forwarded >> to the >>> PSTN. >>>=20 >>> Let say that calls from ALice to Bob in the same domain are >> free (same >>> office, or same ITSP), but calls to the PSTN are not free. >>>=20 >>> Who pays for Alice call to Bob ?? >>> In a normal situacion, Alice knows that the call is for free >> becuase she >>>=20 >>> is calling Bob's sip number. But the gateweay may create CDR >> from the >>> From header of the SIP message and at the end of the month >> Alice may >>> have to pay for the call. >>>=20 >>> I see this kind of examples in several other drafts/RFC >> related to SIP >>> services and call forward. >>>=20 >>> I belive forward is a very important feature, but this issue >> may be >>> resolved. The question is if it is a standard way to make Bob >> pays for >>> the second leg of the call like in PSTN forward. >>>=20 >>> Maybe changing the From header where applicable and adding a >> new one to >>> "remember" that the call is from, in my example, Alice. >>>=20 >>> The diversion header (Diversion Indication in SIP >>> draft-levy-sip-diversion-07.txt)" may be a solution if the >> PSTN gateway >>> or the SIP Billing server support it and knows that they have >> to bill >>> the sip-uri in the diversion header ( this is right ??? ). >>>=20 >>> Regards; >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> -- >> Diego B >> MailVision Ltd. >> Tel. : ?4-8500505 ext 13 >> e-mail: diegob@mailvision.com >> web : http://www.mailvision.com >> >>=20 >>=20 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> =20 >> > SSL> >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current si= p >> Use sipping@ietf.org for new developments on the application of = 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 May 21 05: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 FAA17414 for ; Fri, 21 May 2004 05:11:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5ra-0006yx-9H for sipping-archive@odin.ietf.org; Fri, 21 May 2004 04:58:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L8wkMF026824 for sipping-archive@odin.ietf.org; Fri, 21 May 2004 04:58:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5fK-0003Ov-KN for sipping-web-archive@optimus.ietf.org; Fri, 21 May 2004 04:46:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15777 for ; Fri, 21 May 2004 04:46:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR5fH-0000AI-LU for sipping-web-archive@ietf.org; Fri, 21 May 2004 04:46:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR5eF-0007lf-00 for sipping-web-archive@ietf.org; Fri, 21 May 2004 04:45:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR5dS-0007ZO-00 for sipping-web-archive@ietf.org; Fri, 21 May 2004 04:44:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5Rm-0007ye-NR; Fri, 21 May 2004 04:32:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5M9-0006Vr-9L for sipping@optimus.ietf.org; Fri, 21 May 2004 04:26:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14540 for ; Fri, 21 May 2004 04:26:14 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR5M6-0004tD-Cq for sipping@ietf.org; Fri, 21 May 2004 04:26:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR5L7-0004kO-00 for sipping@ietf.org; Fri, 21 May 2004 04:25:14 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BR5IC-0004EE-00 for sipping@ietf.org; Fri, 21 May 2004 04:23:17 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4L8M8v03031 for ; Fri, 21 May 2004 11:22:08 +0300 (EET DST) X-Scanned: Fri, 21 May 2004 11:22:02 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4L8M2kc011293 for ; Fri, 21 May 2004 11:22:02 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 005XTWMd; Fri, 21 May 2004 11:22:01 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4L8M0H07902 for ; Fri, 21 May 2004 11:22:00 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 21 May 2004 11:21:56 +0300 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] RE: Joint Interim Meeting Mon May 24 - Wed May 26 Date: Fri, 21 May 2004 11:21:55 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B5A@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABCCELaGGR5VRbmbyf4yHwvaEgFJOQ+AAAAXmqAADGlLwAdtbEjQ To: X-OriginalArrivalTime: 21 May 2004 08:21:56.0522 (UTC) FILETIME=[AE0950A0:01C43F0C] 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.7 required=5.0 tests=AWL,BIZ_TLD,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable You can now find the list of attendees from the following link: http://www.softarmor.com/simple/meets/interim2004/Attendance.html Thanks, Hisham > -----Original Message----- > From: sipping-admin@ietf.org=20 > [mailto:sipping-admin@ietf.org]On Behalf Of > ext hisham.khartabil@nokia.com > Sent: 13.April.2004 15:58 > To: sipping@ietf.org > Subject: RE: [Sipping] RE: Joint Interim Meeting Mon May 24 -=20 > Wed May 26 >=20 >=20 > It was pointed out to me that the Group Code for booking was=20 > incorrect. Here is the correct Group Code: NOKNOKA. >=20 > Apologies for the inconvenience. > Hisham >=20 > > -----Original Message----- > > From: sipping-admin@ietf.org=20 > > [mailto:sipping-admin@ietf.org]On Behalf Of > > ext hisham.khartabil@nokia.com > > Sent: 13.April.2004 10:03 > > To: rohan@cisco.com; sipping@ietf.org > > Cc: dean.willis@softarmor.com; mankin@psg.com; rjsparks@nostrum.com; > > jon.peterson@neustar.biz; hardie@qualcomm.com; > > Gonzalo.Camarillo@ericsson.com; alan.johnston@wcom.com; > > adam@dynamicsoft.com > > Subject: [Sipping] RE: Joint Interim Meeting Mon May 24 - Wed May 26 > >=20 > >=20 > > One small correction: > >=20 > > Rooms will be help until 3rd May. > >=20 > > Thanks, > > Hisham > >=20 > > > -----Original Message----- > > > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > > > Sent: 13.April.2004 10:00 > > > To: 'ext Rohan Mahy'; sipping (E-mail) > > > Cc: Dean Willis; Allison Mankin; Robert Sparks; John Peterson; Ted > > > Hardie; Gonzalo Camarillo; Alan Johnston; Adam Roach > > > Subject: RE: Joint Interim Meeting Mon May 24 - Wed May 26 > > >=20 > > >=20 > > > Here is the hotel information: > > >=20 > > > Renaissance Boston Hotel Bedford > > > 44 Middlesex Turnpike Bedford, MA 01730 USA > > > Phone: 1 781-275-5500 Fax: 1 781-275-3042 > > >=20 > > > http://marriott.com/property/propertyPage.mi?marshaCode=3DBOSSB > > >=20 > > > There are 50 rooms booked for this event at the rate of $99=20 > > > per night (from Sunday 23rd until Wednesday 26th). These=20 > > > rooms will be held until 3th May, so please reserve your room=20 > > > on or before that date. > > >=20 > > > You can reserve online or by telephone using the Group=20 > Code: NONOKA > > >=20 > > > Also, please use the links that Rohan provided to confirm=20 > > > your attendance. This will aid us in determining the catering=20 > > > requirements. Here is the link again: > > >=20 > > > mailto:rohan@cisco.com?Cc=3Dhisham.khartabil@nokia.com&Subject=3D[ > > > interim]yes > > >=20 > > > Thanks, > > > Hisham > > >=20 > > > > -----Original Message----- > > > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > > > Sent: 06.April.2004 20:54 > > > > To: sipping (E-mail) > > > > Cc: Dean Willis; Khartabil Hisham=20 > (Nokia-TP-MSW/Helsinki); Allison > > > > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo=20 > > Camarillo; > > > > Rohan Mahy; Alan Johnston; Adam Roach > > > > Subject: Joint Interim Meeting Mon May 24 - Wed May 26 > > > >=20 > > > >=20 > > > > Hello All, > > > >=20 > > > > Please mark your calendars. > > > >=20 > > > > I'd like to announce a joint interim of the SIP, SIPPING,=20 > > > > SIMPLE, and =20 > > > > XCON WGs. > > > > Nokia has generously agreed to host the event either at their=20 > > > > offices =20 > > > > near Boston or in a neighboring hotel during the week of May 24. > > > >=20 > > > > Please reserve the following dates for the WGs that you are=20 > > > > interested =20 > > > > in: > > > > Monday May 24 SIP and SIPPING tentatively 9 am start > > > > Tuesday May 25 SIMPLE All day > > > > Wednesday May 26 XCON tentatively finish at 4pm so folks=20 > > > can catch =20 > > > > flights. > > > > (the actual agenda is subject to change, including the dates=20 > > > > of various =20 > > > > WG meetings). > > > >=20 > > > > There will be no fee, however please let Hisham and myself=20 > > > > know if you =20 > > > > are planning to attend by clicking on the Yes or Maybe=20 > > links below: > > > >=20 > > > > mailto:rohan@cisco.com?=20 > > > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes > > > > mailto:rohan@cisco.com?=20 > > > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe > > > >=20 > > > > Wireless will be provided. As usual, I will be making=20 > > > > T-shirts. If you =20 > > > > are interested in buying one, please send your shirt size to me. > > > >=20 > > > > More details on the agenda and hotel accommodations will be=20 > > > > forthcoming =20 > > > > shortly. > > > >=20 > > > > thanks, > > > > -rohan > > > >=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 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 Fri May 21 05:14: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 FAA17619 for ; Fri, 21 May 2004 05:14:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5uU-0007mC-LE for sipping-archive@odin.ietf.org; Fri, 21 May 2004 05:01:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L91kkq029888 for sipping-archive@odin.ietf.org; Fri, 21 May 2004 05:01:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5qO-0006JY-5B for sipping-web-archive@optimus.ietf.org; Fri, 21 May 2004 04:57:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16406 for ; Fri, 21 May 2004 04:57:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR5qL-0001vg-2O for sipping-web-archive@ietf.org; Fri, 21 May 2004 04:57:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR5pV-0001nJ-00 for sipping-web-archive@ietf.org; Fri, 21 May 2004 04:56:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR5p3-0001eA-00 for sipping-web-archive@ietf.org; Fri, 21 May 2004 04:56:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5YW-0001Dl-Qu; Fri, 21 May 2004 04:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5QG-0007fx-1M for sipping@optimus.ietf.org; Fri, 21 May 2004 04:30:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14790 for ; Fri, 21 May 2004 04:30:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR5QD-0005Uo-2k for sipping@ietf.org; Fri, 21 May 2004 04:30:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR5PI-0005MW-00 for sipping@ietf.org; Fri, 21 May 2004 04:29:33 -0400 Received: from mxout3.netvision.net.il ([194.90.9.24]) by ietf-mx with esmtp (Exim 4.12) id 1BR5Ow-0005Dx-00; Fri, 21 May 2004 04:29:10 -0400 Received: from mailvision.com ([212.143.127.193]) by mxout3.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0HY200KC227PRH@mxout3.netvision.net.il>; Fri, 21 May 2004 11:28:40 +0300 (IDT) Date: Fri, 21 May 2004 10:28:37 +0200 From: Diego B Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? In-reply-to: <40AD16CA.7050407@dynamicsoft.com> To: Jonathan Rosenberg Cc: "Roy, Radhika R, ALABS" , baruch@kayote.com, sayan.chowdhury@wipro.com, sip@ietf.org, sipping@ietf.org, fluffy@cisco.com Message-id: <40ADBDB5.8030307@mailvision.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: QUOTED-PRINTABLE X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: <34DA635B184A644DA4588E260EC0A25A07217374@ACCLUST02EVS1.ugd.att.com> <40AD16CA.7050407@dynamicsoft.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=1.9 required=5.0 tests=AWL,ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Hi; Agreed, but my first question was exactly that, if there is a standar= d=20 way or standard Headers, to store information about a "forward" call. In a normal situation, no one will touch the From header and "normall= y" PSTN gateway copy the user-info from the From SIP-URI to the PSTN "B= =20 number", and this is normally used to create the CDR. I'm not trying to solve the CDR creation issue or how to bill a forwa= rd=20 call, but I'm looking to a standard way to store forward information = so=20 one day this information will be used correctly to create CDRs/billin= g. In a close environment, I can use whatever method to recognize a= =20 forward situation. But SIP is about inter operability and integration= =20 and AFAIK there are some drafts but nothing specific to inform of a c= all=20 forward situation, I don't know the status of Diversion header, but t= his=20 can be a solution if standardized. Thanks Jonathan Rosenberg wrote: > To be clear, Baruch is proposing a new SIP header, which the SIP WG= =20 > would need to worry about. >=20 > I do not think such a thing is needed. As Keith pointed out, our= =20 > philosophy to date (and this is a broader IETF thing too), is to ma= ke=20 > sure that you can *account* for what has happened. That is, that th= e=20 > protocols contain sufficient information to record what transpired = in a=20 > call/transaction/dialog or whatever. Then, its someone elses proble= m=20 > (for example, 3gpp) to specify how the appropriate information is= =20 > collected, what billing model is used, and how a CDR is generated. = Not=20 > to say that these things arent important, they're just not the SIP= =20 > working group's problem. >=20 > -Jonathan R. >=20 > Roy, Radhika R, ALABS wrote: >=20 >> I agree with Baruch that AAA group is working for authentication,= =20 >> authorization, and accounting of applications including SIP, and t= here=20 >> is enough room to build CDRs/Billing based on those things. So, SI= P WG=20 >> does not need to be worried for this. >> =20 >> Radhika R. Roy >> rrroy@att.com >> >> -----Original Message----- >> *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org]*On Beha= lf Of >> *Baruch Sterman >> *Sent:* Wednesday, May 19, 2004 5:47 AM >> *To:* sayan.chowdhury@wipro.com; diegob@mailvision.com >> *Cc:* sip@ietf.org; sipping@ietf.org; fluffy@cisco.com >> *Subject:* RE: [Sip] SIP Forward, Who pays the bill ? >> >> Another avenue that can be explored is an explicit header to d= eal >> with this and other accounting issues. I think that the AAA gr= oup >> has suggested an ACCOUNTING header. We were thinking of a BILL= ING >> header. In that header you would have a username and type. So = as the >> call progresses you could add to that header. This would also = allow >> to charge for various services along the way. Imagine the foll= owing. >> Alice calls Bob, Bob forwards to Charlie who requires an ENUM = lookup >> to find his IP =E2=80=93 and you are dealing with a psychotic = ITSP that >> **Charges** for ENUM listing. >> >> Inbound Alice -> Bob Billing: Alice, inbound >> >> Forward Bob -> Charlie Billing: Alice, inbound; Bob, outb= ound >> >> ITSP looks up Charlie Billing: Alice, inbound; Bob, out= bound; >> Charlie, serviceX >> >> =20 >> So when the CDR gets written, the rating engine looks through = the >> Billing header and applies all the relevant charges to the rel= evant >> accounts. Some may be per minute, some may be fixed charges. >> >> =20 >> The problems are first and foremost, security. No one can add = to the >> billing header unless they are trusted entities within your sy= stem, >> because money will be charged based on the information there. >> Second, care has to be taken to strip off the header when it l= eaves >> the trusted domain =E2=80=93 out to the UA=E2=80=99s for examp= le. You don=E2=80=99t want >> people knowing what is going on in your billing system. >> >> =20 >> But the idea here is very flexible and can take into account m= any >> things that we aren=E2=80=99t thinking about now. For example,= we may charge >> differently one day calls that require NAT treatment on the RT= P >> level (where the bandwidth cost to the hosting ITSP is not >> negligible). When you find that to be the case, just add it to= the >> Billing header. What about if calls are forwarded multiple tim= es? >> Keep adding each leg to the billing header. >> >> =20 >> What does everyone think about this? >> >> =20 >> Baruch >> >> =20 >> -----Original Message----- >> *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org] *On Beh= alf Of >> *sayan.chowdhury@wipro.com >> *Sent:* Wednesday, May 19, 2004 1:00 AM >> *To:* diegob@mailvision.com; baruch@kayote.com >> *Cc:* sip@ietf.org; sipping@ietf.org; fluffy@cisco.com >> *Subject:* RE: [Sip] SIP Forward, Who pays the bill ? >> >> =20 >> Also , Alice might be sending the re-invite to on receipt of a= 302 >> from Bob. So the set of proxies invloved in the first leg of t= he >> call may not be involved in the second ? >> >> Solutuion to this will be on the PSTN gateway side. >> >> The PSTN gateway should look for and bill from Diversion/Reque= st >> History/remote Part Header information in preference to the fr= om >> header which is unreliable any way. >> >> However , I do not know of any standards which explicitly ment= ions >> that .. >> >> =20 >> Regards , >> >> Sayan >> >> =20 >> -----Original Message----- >> *From:* sip-admin@ietf.org on behalf of Diego B >> *Sent:* Tue 5/18/2004 7:44 PM >> *To:* baruch@kayote.com >> *Cc:* sip@ietf.org; 'sipping'; 'Cullen Jennings' >> *Subject:* Re: [Sip] SIP Forward, Who pays the bill ? >> >> Hi Baruch; >> Thanks for your answer. >> I belive that you are implementing a proprietary solution = to >> deal with it. >> I'm looking more to a standarize way to deal with the seco= nd-leg >> issue. >> >> I'm agree that Alice has to pay for the first leg and Bob = for the >> second, but if the Proxy that is doing the forward is not = a=20 >> biling >> entity ( local calls are free, outbound call are not free = and >> billed by >> an external real-time billing system connected to the GW u= sing >> RADIUS or >> similar), the PSTN gateway will have to know that this cal= l=20 >> may be >> billed to Bob and not to Alice ( she apears in the From he= ader ). >> >> Thanks >> >> Baruch Sterman wrote: >> >>> In the systems that we implemented, two cdrs are created: the >> >> first for >> >>> the incoming leg (Alice to Bob's non-forwarded location) and a >> >> second >> >>> for the forward to Bob's forwarded location. >>> >>> Alice would pay for the first leg, and Bob pays for the second. >>> >>> Furthermore, it may be the case that Bob pays for the first >> >> leg as well. >> >>> If, for example, Bob has a toll free number where he pays per >> >> minute >> >>> charges for the inbound leg (in this case, Alice is on the PSTN)= . >>> >>> Either way, multiple CDRs is the way we came up with to handle >> >> this. >> >>> Care has to be taken that the key to any CDR database is NOT the >>> call-ID, because this is the same across the two CDRs. >>> >>> Baruch >>> >>> -----Original Message----- >>> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf >> >> Of Diego >> >>> B >>> Sent: Tuesday, May 18, 2004 7:42 AM >>> To: sip@ietf.org; sipping >>> Cc: Cullen Jennings >>> Subject: [Sip] SIP Forward, Who pays the bill ? >>> >>> Hi; >>> My question is regarding billing a forwarded sip call. >>> >>> Lets take the exmple from draft-ietf-sipping-service-examples >>> 2.7 >>> >>> Alice calls Bob, and Bob has all his incomming calls forwarded >> >> to the >> >>> PSTN. >>> >>> Let say that calls from ALice to Bob in the same domain are >> >> free (same >> >>> office, or same ITSP), but calls to the PSTN are not free. >>> >>> Who pays for Alice call to Bob ?? >>> In a normal situacion, Alice knows that the call is for free >> >> becuase she >> >>> >>> is calling Bob's sip number. But the gateweay may create CDR >> >> from the >> >>> From header of the SIP message and at the end of the month >> >> Alice may >> >>> have to pay for the call. >>> >>> I see this kind of examples in several other drafts/RFC >> >> related to SIP >> >>> services and call forward. >>> >>> I belive forward is a very important feature, but this issue >> >> may be >> >>> resolved. The question is if it is a standard way to make Bob >> >> pays for >> >>> the second leg of the call like in PSTN forward. >>> >>> Maybe changing the From header where applicable and adding a >> >> new one to >> >>> "remember" that the call is from, in my example, Alice. >>> >>> The diversion header (Diversion Indication in SIP >>> draft-levy-sip-diversion-07.txt)" may be a solution if the >> >> PSTN gateway >> >>> or the SIP Billing server support it and knows that they have >> >> to bill >> >>> the sip-uri in the diversion header ( this is right ??? ). >>> >>> Regards; >>> >>> >>> >>> >>> >> >> -- >> Diego B >> MailVision Ltd. >> Tel. : =EF=9E=BD4-8500505 ext 13 >> e-mail: diegob@mailvision.com >> web : http://www.mailvision.com >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/s= ip >> =20 >> =20 >> >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on curr= ent sip >> Use sipping@ietf.org for new developments on the applicati= on=20 >> of sip >> >=20 --=20 Diego B MailVision Ltd. Tel. : +972-4-8500505 ext 13 e-mail: diegob@mailvision.com web : http://www.mailvision.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 May 21 05:37: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 FAA18828 for ; Fri, 21 May 2004 05:37:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR6Rx-0008Uq-Bs for sipping-archive@odin.ietf.org; Fri, 21 May 2004 05:36:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L9aLde032658 for sipping-archive@odin.ietf.org; Fri, 21 May 2004 05:36:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR6JK-00069E-SS for sipping-web-archive@optimus.ietf.org; Fri, 21 May 2004 05:27:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18252 for ; Fri, 21 May 2004 05:27:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR6JH-0006ZE-HX for sipping-web-archive@ietf.org; Fri, 21 May 2004 05:27:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR6IS-0006Qp-00 for sipping-web-archive@ietf.org; Fri, 21 May 2004 05:26:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR6Hu-0006I6-00 for sipping-web-archive@ietf.org; Fri, 21 May 2004 05:25:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR66R-0002kF-09; Fri, 21 May 2004 05:14:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5t9-0007Ql-Eb for sipping@optimus.ietf.org; Fri, 21 May 2004 05:00:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16607 for ; Fri, 21 May 2004 05:00:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR5t6-0002R9-9W for sipping@ietf.org; Fri, 21 May 2004 05:00:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR5s7-0002FK-00 for sipping@ietf.org; Fri, 21 May 2004 04:59:19 -0400 Received: from vivo190.gprs.suomen2g.fi ([62.78.127.190] helo=localhost) by ietf-mx with esmtp (Exim 4.12) id 1BR5r9-0001x2-00; Fri, 21 May 2004 04:58:20 -0400 Received: from jh by localhost with local (Exim 3.35 #1 (Debian)) id 1BR5oI-0000OE-00; Fri, 21 May 2004 11:55:22 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16557.50170.649315.622928@tutpro.com> Date: Fri, 21 May 2004 11:55:22 +0300 To: Diego B Cc: Jonathan Rosenberg , "Roy, Radhika R, ALABS" , baruch@kayote.com, sayan.chowdhury@wipro.com, sip@ietf.org, sipping@ietf.org, fluffy@cisco.com Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? In-Reply-To: <40ADBDB5.8030307@mailvision.com> References: <34DA635B184A644DA4588E260EC0A25A07217374@ACCLUST02EVS1.ugd.att.com> <40AD16CA.7050407@dynamicsoft.com> <40ADBDB5.8030307@mailvision.com> X-Mailer: VM 7.17 under Emacs 21.2.1 From: Juha Heinanen 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 Diego B writes: > In a close environment, I can use whatever method to recognize a > forward situation. But SIP is about inter operability and integration > and AFAIK there are some drafts but nothing specific to inform of a call > forward situation, I don't know the status of Diversion header, but this > can be a solution if standardized. both rpid and diversion headers have become de-facto industry ways to achieve that you want. may be one day some ietf standardized way to do the same becomes widely implemented, at which point you can support this new thing too. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 21 08: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 IAA28091 for ; Fri, 21 May 2004 08:48:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR9P1-0004a8-JC for sipping-archive@odin.ietf.org; Fri, 21 May 2004 08:45:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LCjVfm017612 for sipping-archive@odin.ietf.org; Fri, 21 May 2004 08:45:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR9AZ-0000bf-BI for sipping-web-archive@optimus.ietf.org; Fri, 21 May 2004 08:30:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27087 for ; Fri, 21 May 2004 08:30:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR9AY-0007Xo-6p for sipping-web-archive@ietf.org; Fri, 21 May 2004 08:30:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR99b-0007Jh-00 for sipping-web-archive@ietf.org; Fri, 21 May 2004 08:29:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR98j-000782-00 for sipping-web-archive@ietf.org; Fri, 21 May 2004 08:28:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR93o-0007TX-Fl; Fri, 21 May 2004 08:23:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7u5-00008U-NW for sipping@optimus.ietf.org; Fri, 21 May 2004 07:09:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24103 for ; Fri, 21 May 2004 07:09:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR7u1-0000lK-AJ for sipping@ietf.org; Fri, 21 May 2004 07:09:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR7t2-0000ar-00 for sipping@ietf.org; Fri, 21 May 2004 07:08:24 -0400 Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BR7s6-0000HN-00; Fri, 21 May 2004 07:07:26 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i4LB5r47014070; Fri, 21 May 2004 07:06:58 -0400 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh5i.attrh.att.com (6.5.032) id 40A791690013C64A; Fri, 21 May 2004 07:06:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? Date: Fri, 21 May 2004 06:06:40 -0500 Message-ID: <28F05913385EAC43AF019413F674A01708145CA4@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? Thread-Index: AcQ/ELfgjhrsEC3hQJqIimMvFw1S/gAEn9iw From: "Dolly, Martin C, ALABS" To: "Diego B" , "Jonathan Rosenberg" Cc: "Roy, Radhika R, ALABS" , , , , , 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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QSBtZWNoYW5pc20gZm9yIHJlbGF5aW5nIGNhbGwgZm9yd2FyZGluZyBpbmZvcm1hdGlvbiBpcyBu ZWVkZWQsIGFuZCBJIGFncmVlIHRoYXQgdGhlIGRpdmVyc2lvbiBkcmFmdCBpcyBhIHZpYWJsZSBz b2x1dGlvbi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcC1hZG1pbkBp ZXRmLm9yZyBbbWFpbHRvOnNpcC1hZG1pbkBpZXRmLm9yZ11PbiBCZWhhbGYgT2YgRGllZ28gQg0K U2VudDogRnJpZGF5LCBNYXkgMjEsIDIwMDQgNDoyOSBBTQ0KVG86IEpvbmF0aGFuIFJvc2VuYmVy Zw0KQ2M6IFJveSwgUmFkaGlrYSBSLCBBTEFCUzsgYmFydWNoQGtheW90ZS5jb207IHNheWFuLmNo b3dkaHVyeUB3aXByby5jb207DQpzaXBAaWV0Zi5vcmc7IHNpcHBpbmdAaWV0Zi5vcmc7IGZsdWZm eUBjaXNjby5jb20NClN1YmplY3Q6IFJlOiBbU2lwcGluZ10gUkU6IFtTaXBdIFNJUCBGb3J3YXJk LCBXaG8gcGF5cyB0aGUgYmlsbCA/DQoNCg0KSGk7DQoNCkFncmVlZCwgYnV0IG15IGZpcnN0IHF1 ZXN0aW9uIHdhcyBleGFjdGx5IHRoYXQsIGlmIHRoZXJlIGlzIGEgc3RhbmRhcmQgDQp3YXkgb3Ig c3RhbmRhcmQgSGVhZGVycywgdG8gc3RvcmUgaW5mb3JtYXRpb24gYWJvdXQgYSAiZm9yd2FyZCIg Y2FsbC4NCg0KSW4gYSBub3JtYWwgc2l0dWF0aW9uLCBubyBvbmUgd2lsbCB0b3VjaCB0aGUgRnJv bSBoZWFkZXIgYW5kICJub3JtYWxseSINClBTVE4gZ2F0ZXdheSBjb3B5IHRoZSB1c2VyLWluZm8g ZnJvbSB0aGUgRnJvbSBTSVAtVVJJIHRvIHRoZSBQU1ROICJCIA0KbnVtYmVyIiwgYW5kIHRoaXMg aXMgbm9ybWFsbHkgdXNlZCB0byBjcmVhdGUgdGhlIENEUi4NCg0KSSdtIG5vdCB0cnlpbmcgdG8g c29sdmUgdGhlIENEUiBjcmVhdGlvbiBpc3N1ZSBvciBob3cgdG8gYmlsbCBhIGZvcndhcmQgDQpj YWxsLCBidXQgSSdtIGxvb2tpbmcgdG8gYSBzdGFuZGFyZCB3YXkgdG8gc3RvcmUgZm9yd2FyZCBp bmZvcm1hdGlvbiBzbyANCm9uZSBkYXkgdGhpcyBpbmZvcm1hdGlvbiB3aWxsIGJlIHVzZWQgY29y cmVjdGx5IHRvIGNyZWF0ZSBDRFJzL2JpbGxpbmcuDQoNCkluIGEgY2xvc2UgZW52aXJvbm1lbnQs IEkgY2FuIHVzZSB3aGF0ZXZlciBtZXRob2QgdG8gIHJlY29nbml6ZSBhIA0KZm9yd2FyZCBzaXR1 YXRpb24uIEJ1dCBTSVAgaXMgYWJvdXQgaW50ZXIgb3BlcmFiaWxpdHkgYW5kIGludGVncmF0aW9u IA0KYW5kIEFGQUlLIHRoZXJlIGFyZSBzb21lIGRyYWZ0cyBidXQgbm90aGluZyBzcGVjaWZpYyB0 byBpbmZvcm0gb2YgYSBjYWxsIA0KZm9yd2FyZCBzaXR1YXRpb24sIEkgZG9uJ3Qga25vdyB0aGUg c3RhdHVzIG9mIERpdmVyc2lvbiBoZWFkZXIsIGJ1dCB0aGlzIA0KY2FuIGJlIGEgc29sdXRpb24g aWYgc3RhbmRhcmRpemVkLg0KDQpUaGFua3MNCg0KSm9uYXRoYW4gUm9zZW5iZXJnIHdyb3RlOg0K PiBUbyBiZSBjbGVhciwgQmFydWNoIGlzIHByb3Bvc2luZyBhIG5ldyBTSVAgaGVhZGVyLCB3aGlj aCB0aGUgU0lQIFdHIA0KPiB3b3VsZCBuZWVkIHRvIHdvcnJ5IGFib3V0Lg0KPiANCj4gSSBkbyBu b3QgdGhpbmsgc3VjaCBhIHRoaW5nIGlzIG5lZWRlZC4gQXMgS2VpdGggcG9pbnRlZCBvdXQsIG91 ciANCj4gcGhpbG9zb3BoeSB0byBkYXRlIChhbmQgdGhpcyBpcyBhIGJyb2FkZXIgSUVURiB0aGlu ZyB0b28pLCBpcyB0byBtYWtlIA0KPiBzdXJlIHRoYXQgeW91IGNhbiAqYWNjb3VudCogZm9yIHdo YXQgaGFzIGhhcHBlbmVkLiBUaGF0IGlzLCB0aGF0IHRoZSANCj4gcHJvdG9jb2xzIGNvbnRhaW4g c3VmZmljaWVudCBpbmZvcm1hdGlvbiB0byByZWNvcmQgd2hhdCB0cmFuc3BpcmVkIGluIGEgDQo+ IGNhbGwvdHJhbnNhY3Rpb24vZGlhbG9nIG9yIHdoYXRldmVyLiBUaGVuLCBpdHMgc29tZW9uZSBl bHNlcyBwcm9ibGVtIA0KPiAoZm9yIGV4YW1wbGUsIDNncHApIHRvIHNwZWNpZnkgaG93IHRoZSBh cHByb3ByaWF0ZSBpbmZvcm1hdGlvbiBpcyANCj4gY29sbGVjdGVkLCB3aGF0IGJpbGxpbmcgbW9k ZWwgaXMgdXNlZCwgYW5kIGhvdyBhIENEUiBpcyBnZW5lcmF0ZWQuIE5vdCANCj4gdG8gc2F5IHRo YXQgdGhlc2UgdGhpbmdzIGFyZW50IGltcG9ydGFudCwgdGhleSdyZSBqdXN0IG5vdCB0aGUgU0lQ IA0KPiB3b3JraW5nIGdyb3VwJ3MgcHJvYmxlbS4NCj4gDQo+IC1Kb25hdGhhbiBSLg0KPiANCg== _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 21 09:15: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 JAA29712 for ; Fri, 21 May 2004 09:15:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR9m9-0002LF-Jl for sipping-archive@odin.ietf.org; Fri, 21 May 2004 09:09:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LD9PBf008996 for sipping-archive@odin.ietf.org; Fri, 21 May 2004 09:09:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR9iU-0000jn-5d for sipping-web-archive@optimus.ietf.org; Fri, 21 May 2004 09:05:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29101 for ; Fri, 21 May 2004 09:05:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR9iS-00071R-MO for sipping-web-archive@ietf.org; Fri, 21 May 2004 09:05:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR9hg-0006pH-00 for sipping-web-archive@ietf.org; Fri, 21 May 2004 09:04:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR9gj-0006d6-00 for sipping-web-archive@ietf.org; Fri, 21 May 2004 09:03:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR9QW-00057Y-Eh; Fri, 21 May 2004 08:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR9L9-0002v2-OD for sipping@optimus.ietf.org; Fri, 21 May 2004 08:41:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27517 for ; Fri, 21 May 2004 08:41:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR9L8-0001oA-E5 for sipping@ietf.org; Fri, 21 May 2004 08:41:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR9K8-0001bO-00 for sipping@ietf.org; Fri, 21 May 2004 08:40:29 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1BR9JD-0001EQ-00 for sipping@ietf.org; Fri, 21 May 2004 08:39:31 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4LCcRe09665; Fri, 21 May 2004 08:38:27 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 May 2004 08:38:27 -0400 Message-ID: From: "Mary Barnes" To: "'Juha Heinanen'" , Diego B Cc: sipping@ietf.org Subject: RE: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? Date: Fri, 21 May 2004 08:38:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43F30.809E951B" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_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_01C43F30.809E951B Content-Type: text/plain I've trimmed the receiver list and kept this on sipping only. I think folks should take a look at: http://www.ietf.org/internet-drafts/draft-elwell-sipping-redirection-reason- 00.txt and see if this doesn't help fill the gap. This could be used in conjunction with History-Info: http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-02.txt to achieve the functionality of knowing when a a call has been forwarded (obviously, not all addressing any billing requirements, but I think all the information you would need would be available). Regards, Mary. -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Friday, May 21, 2004 3:55 AM To: Diego B Cc: Jonathan Rosenberg; Roy, Radhika R, ALABS; baruch@kayote.com; Chowdhury, Sayan [Business:WBNG:7Q23]; sip@ietf.org; sipping@ietf.org; fluffy@cisco.com Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? Diego B writes: > In a close environment, I can use whatever method to recognize a > forward situation. But SIP is about inter operability and integration > and AFAIK there are some drafts but nothing specific to inform of a call > forward situation, I don't know the status of Diversion header, but this > can be a solution if standardized. both rpid and diversion headers have become de-facto industry ways to achieve that you want. may be one day some ietf standardized way to do the same becomes widely implemented, at which point you can support this new thing too. -- juha _______________________________________________ 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 ------_=_NextPart_001_01C43F30.809E951B Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ?

I've trimmed the receiver list and kept this on = sipping only.  I think folks should take a look at:
http://www.ietf.org/internet-drafts/draft-elwell-sippi= ng-redirection-reason-00.txt
and see if this doesn't help fill the gap.  =

This could be used in conjunction with = History-Info:
http://www.ietf.org/internet-drafts/draft-ietf-sip-his= tory-info-02.txt
to achieve the functionality of knowing when a a = call has been forwarded (obviously, not all addressing any billing = requirements, but I think all the information you would need would be = available).

Regards,
Mary.

-----Original Message-----
From: Juha Heinanen [mailto:jh@tutpro.com]
Sent: Friday, May 21, 2004 3:55 AM
To: Diego B
Cc: Jonathan Rosenberg; Roy, Radhika R, ALABS; = baruch@kayote.com; Chowdhury, Sayan [Business:WBNG:7Q23]; sip@ietf.org; = sipping@ietf.org; fluffy@cisco.com

Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who = pays the bill ?


Diego B writes:

 > In a close environment, I can use whatever = method to  recognize a
 > forward situation. But SIP is about inter = operability and integration
 > and AFAIK there are some drafts but = nothing specific to inform of a call
 > forward situation, I don't know the = status of Diversion header, but this
 > can be a solution if standardized.

both rpid and diversion headers have become de-facto = industry ways to achieve that you want.  may be one day some ietf = standardized way to do the same becomes widely implemented, at which = point you can support this new thing too.

-- juha

_______________________________________________
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

------_=_NextPart_001_01C43F30.809E951B-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 22 07: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 HAA00069 for ; Sat, 22 May 2004 07:28:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUXa-0006Zc-SN for sipping-archive@odin.ietf.org; Sat, 22 May 2004 07:19:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4MBJkhT025266 for sipping-archive@odin.ietf.org; Sat, 22 May 2004 07:19:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUMS-0004H5-A5 for sipping-web-archive@optimus.ietf.org; Sat, 22 May 2004 07:08:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29025 for ; Sat, 22 May 2004 07:08:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRUMN-0004v1-PG for sipping-web-archive@ietf.org; Sat, 22 May 2004 07:08:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRULP-0004lh-00 for sipping-web-archive@ietf.org; Sat, 22 May 2004 07:07:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRUKS-0004be-00 for sipping-web-archive@ietf.org; Sat, 22 May 2004 07:06:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUDW-0001ie-2n; Sat, 22 May 2004 06:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRU2C-00009j-CC for sipping@optimus.ietf.org; Sat, 22 May 2004 06:47:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27756 for ; Sat, 22 May 2004 06:47:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRU28-0001Fj-5O for sipping@ietf.org; Sat, 22 May 2004 06:47:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRU17-00015D-00 for sipping@ietf.org; Sat, 22 May 2004 06:46:14 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1BRU0A-0000u1-00 for sipping@ietf.org; Sat, 22 May 2004 06:45:14 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i4MAdqrw000895 for ; Sat, 22 May 2004 05:39:52 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i4MAdorw000855 for ; Sat, 22 May 2004 05:39:50 -0500 (EST) Date: Sat, 22 May 2004 13:45:00 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43FE9.D4E9C41A" Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Re: Here is the document Thread-Index: AcQ/6dTgRWZZiQTvRQGk4/5lBc02MAAAAAI9 From: "Romascanu, Dan (Dan)" To: Subject: [Sipping] Out of Office AutoReply: Re: Here is the 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.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C43FE9.D4E9C41A Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I am at the IEEE meeting and may not be able to read and reply to your = message until May 23rd. If you need to contact me directly, please call = +972-50-692-8065. Regards, Dan ------_=_NextPart_001_01C43FE9.D4E9C41A Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: <Possible SPAM> Re: Here is the = document

I am at the IEEE meeting and may not be able to read = and reply to your message until May 23rd. If you need to contact me = directly, please call +972-50-692-8065.

Regards,

Dan

------_=_NextPart_001_01C43FE9.D4E9C41A-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 22 16:35:09 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25597 for ; Sat, 22 May 2004 16:35:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRdBf-0004DN-32 for sipping-archive@odin.ietf.org; Sat, 22 May 2004 16:33:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4MKXhJl016202 for sipping-archive@odin.ietf.org; Sat, 22 May 2004 16:33:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRd5m-0002rb-ER for sipping-web-archive@optimus.ietf.org; Sat, 22 May 2004 16:27:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25253 for ; Sat, 22 May 2004 16:27:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRd5k-0006ZR-Jc for sipping-web-archive@ietf.org; Sat, 22 May 2004 16:27:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRd4o-0006Nf-00 for sipping-web-archive@ietf.org; Sat, 22 May 2004 16:26:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRd3w-0006C9-00 for sipping-web-archive@ietf.org; Sat, 22 May 2004 16:25:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRczO-0001F3-R6; Sat, 22 May 2004 16:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRcvJ-0000ak-4t for sipping@optimus.ietf.org; Sat, 22 May 2004 16:16:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24986 for ; Sat, 22 May 2004 16:16:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRcvH-0004TM-Hm for sipping@ietf.org; Sat, 22 May 2004 16:16:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRcuK-0004Go-00 for sipping@ietf.org; Sat, 22 May 2004 16:15:49 -0400 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 1BRctD-0003sq-00 for sipping@ietf.org; Sat, 22 May 2004 16:14:39 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 22 May 2004 12:20: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 i4MKE7De029630; Sat, 22 May 2004 13:14:07 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATK62490; Sat, 22 May 2004 13:13:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) To: sipping (E-mail) Message-Id: <0091DD85-AC2D-11D8-BA8A-0003938AF740@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-16--424353300 Cc: Rohan Mahy From: Rohan Mahy Date: Sat, 22 May 2004 13:17:09 -0700 X-Mailer: Apple Mail (2.613) Subject: [Sipping] Fwd: SIMPLE/SIP/SIPPING/XCON Working Groups Joint Interim Meeting Announcement Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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,BIZ_TLD,HTML_MESSAGE autolearn=no version=2.60 --Apple-Mail-16--424353300 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit FYI: A lot of folks didn't see this. thx, -r Begin forwarded message: > From: > Date: April 21, 2004 11:29:18 PM PDT > To: > Cc: , , > , , > , , , > , > Subject: SIMPLE/SIP/SIPPING/XCON Working Groups Joint Interim Meeting > Announcement > > An joint interim meeting for the SIMPLE, SIP, SIPPING and XCON working > groups will be help from Monday 24th May until Wednesday 26th May in > Boston, Massachusetts. > > Location: > Renaissance Boston Hotel Bedford > 44 Middlesex Turnpike Bedford, MA 01730 USA > Phone: 1 781-275-5500 Fax: 1 781-275-3042 > > http://marriott.com/property/propertyPage.mi?marshaCode=BOSSB > > Agenda: > > MONDAY - SIMPLE > > 9:00-12:00 - MSRP/MSRP Relays > 12:00-13:00 - Lunch > 13:00-16:00 - XCAP > 16:00-16:30 - Filtering > 16:30-17:00 - Partial Publish > 17:00-17:30 - Advanced Messaging > > TUESDAY - SIP/SIPPING > > 9:00-10:30 - KPML > 10:30-11:00 - GRUU > 11:00-12:00 - Session Policies > 12:00-13:00 - Lunch > 13:00-14:30 - Session Policies Cont. > 14:30-15:30 - Exploders > time permitting: > 15:30-16:15 - Connected Party > 16:15-17:00 - Application Interaction > 17:00-17:30 - Dialog Package > 17:30-18:00 - Connection Re-use > > WEDNESDAY - XCON > > 9:00-11:00 - Floor Control > 11:00-12:00 - CPCP > 12:00-13:00 - Lunch > 13:00-14:00 - CPCP Cont. > 14:00-16:00 - MPCP > > The chairs would like to thank Nokia for sponsoring the event. --Apple-Mail-16--424353300 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit FYI: A lot of folks didn't see this. thx, -r Begin forwarded message: Helvetica0000,0000,0000From: Helvetica< 0000,0000,0000Date: April 21, 2004 11:29:18 PM PDT 0000,0000,0000To: < 0000,0000,0000Cc: <, <, <, <, <, <, <, <, < 0000,0000,0000Subject: SIMPLE/SIP/SIPPING/XCON Working Groups Joint Interim Meeting Announcement An joint interim meeting for the SIMPLE, SIP, SIPPING and XCON working groups will be help from Monday 24th May until Wednesday 26th May in Boston, Massachusetts. Location: Renaissance Boston Hotel Bedford 44 Middlesex Turnpike Bedford, MA 01730 USA Phone: 1 781-275-5500 Fax: 1 781-275-3042 http://marriott.com/property/propertyPage.mi?marshaCode=BOSSB Agenda: MONDAY - SIMPLE 9:00-12:00 - MSRP/MSRP Relays 12:00-13:00 - Lunch 13:00-16:00 - XCAP 16:00-16:30 - Filtering 16:30-17:00 - Partial Publish 17:00-17:30 - Advanced Messaging TUESDAY - SIP/SIPPING 9:00-10:30 - KPML 10:30-11:00 - GRUU 11:00-12:00 - Session Policies 12:00-13:00 - Lunch 13:00-14:30 - Session Policies Cont. 14:30-15:30 - Exploders time permitting: 15:30-16:15 - Connected Party 16:15-17:00 - Application Interaction 17:00-17:30 - Dialog Package 17:30-18:00 - Connection Re-use WEDNESDAY - XCON 9:00-11:00 - Floor Control 11:00-12:00 - CPCP 12:00-13:00 - Lunch 13:00-14:00 - CPCP Cont. 14:00-16:00 - MPCP The chairs would like to thank Nokia for sponsoring the event. --Apple-Mail-16--424353300-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 23 01:52:15 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16768 for ; Sun, 23 May 2004 01:52:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRlsX-00065w-C0 for sipping-archive@odin.ietf.org; Sun, 23 May 2004 01:50:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4N5oXem023426 for sipping-archive@odin.ietf.org; Sun, 23 May 2004 01:50:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRlq9-0005iA-MR for sipping-web-archive@optimus.ietf.org; Sun, 23 May 2004 01:48:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16646 for ; Sun, 23 May 2004 01:48:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRlq6-00030C-8W for sipping-web-archive@ietf.org; Sun, 23 May 2004 01:48:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRlpB-0002mZ-00 for sipping-web-archive@ietf.org; Sun, 23 May 2004 01:47:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRloP-0002Z3-00 for sipping-web-archive@ietf.org; Sun, 23 May 2004 01:46:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRljM-0004Kp-HW; Sun, 23 May 2004 01:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRlda-0002xj-7U for sipping@optimus.ietf.org; Sun, 23 May 2004 01:35:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16342 for ; Sun, 23 May 2004 01:35:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRldW-00003d-Hj for sipping@ietf.org; Sun, 23 May 2004 01:35:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRlcg-0007dY-00 for sipping@ietf.org; Sun, 23 May 2004 01:34:11 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1BRlbh-0007BV-00; Sun, 23 May 2004 01:33:09 -0400 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 22 May 2004 22:32:40 -0700 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 22 May 2004 22:32:39 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 22 May 2004 22:32:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-65d71f76-0031-4100-b798-eac27d09341b" Date: Sat, 22 May 2004 22:32:48 -0700 Message-ID: Thread-Topic: draft-ietf-sipping-conference-package-04 thread-index: AcRAh2JX6/l8x28fQMGTEyx13ilzjw== From: "Orit Levin" To: , Cc: "Jonathan Rosenberg" , "Henning Schulzrinne" X-OriginalArrivalTime: 23 May 2004 05:32:38.0624 (UTC) FILETIME=[5C489600:01C44087] Subject: [Sipping] draft-ietf-sipping-conference-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.4 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE, MIME_BOUND_NEXTPART,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPartTM-000-65d71f76-0031-4100-b798-eac27d09341b Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44087.5422B609" ------_=_NextPart_001_01C44087.5422B609 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi guys, I have submitted a new version of the "Conference Package". Till it appears on the IETF site, you can find a copy at the link below (together with the rest of the sipping conferencing stuff). http://ee.wustl.edu/~alan/sip-conf/draft-ietf-sipping-conference-package -04.txt http://ee.wustl.edu/~alan/sip-conf/draft-ietf-sipping-conference-package -04.html =20 Thanks, Orit, ------_=_NextPart_001_01C44087.5422B609 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = guys,

I have submitted a = new version of the “Conference Package”.

Till it appears on = the IETF site, you can find a copy at the link below (together with the rest of = the sipping conferencing stuff).

http://ee.wustl.edu/~alan/sip-conf/draft-ietf-sipping-con= ference-package-04.txt

http://ee.wustl.edu/~alan/sip-conf/draft-ietf-sipping-co= nference-package-04.html

 

Thanks,

Orit,

------_=_NextPart_001_01C44087.5422B609-- ------=_NextPartTM-000-65d71f76-0031-4100-b798-eac27d09341b-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 24 06:37:22 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25360 for ; Mon, 24 May 2004 06:37:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCd5-0007hx-JG for sipping-archive@odin.ietf.org; Mon, 24 May 2004 06:24:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OAONDZ029629 for sipping-archive@odin.ietf.org; Mon, 24 May 2004 06:24:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCNa-0005Cu-IW for sipping-web-archive@optimus.ietf.org; Mon, 24 May 2004 06:08:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24157 for ; Mon, 24 May 2004 06:08:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSCNW-00053J-KP for sipping-web-archive@ietf.org; Mon, 24 May 2004 06:08:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSCMs-0004l8-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 06:07:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSCLs-0004RN-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 06:06:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCEY-0003mH-Iw; Mon, 24 May 2004 05:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSC69-0002gP-Uv for sipping@optimus.ietf.org; Mon, 24 May 2004 05:50:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23214 for ; Mon, 24 May 2004 05:50:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSC66-00078p-AC for sipping@ietf.org; Mon, 24 May 2004 05:50:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSC5B-0006qg-00 for sipping@ietf.org; Mon, 24 May 2004 05:49:22 -0400 Received: from usjk1004.kddi.com ([211.4.169.26]) by ietf-mx with esmtp (Exim 4.12) id 1BSC4m-0006Y2-00 for sipping@ietf.org; Mon, 24 May 2004 05:48:56 -0400 Received: from usjk1035.kddi.com ([10.96.2.25]) by usjk1004.kddi.com with ESMTP id i4O9mNU04219; Mon, 24 May 2004 18:48:23 +0900 (JST) Received: from usjk1010.kddi.com (localhost [127.0.0.1]) by usjk1035.kddi.com with ESMTP id i4O9mNi12200; Mon, 24 May 2004 18:48:23 +0900 (JST) Received: from KDDI-0403PC0002 ([10.100.94.32]) by usjk1010.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20040524094823.HYCC1051.usjk1010.kddi.com@KDDI-0403PC0002>; Mon, 24 May 2004 18:48:23 +0900 To: mary.barnes@nortelnetworks.com, jh@tutpro.com, diegob@mailvision.com Cc: sipping@ietf.org Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? From: Takuya Sawada References: In-Reply-To: Message-Id: <200405241848.DIG39159.BEVBB-TUX@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Mon, 24 May 2004 18:48:23 +0900 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.2 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Do you have a plan to include the proposal in Johon's draft into History-Info draft? Regards, Takuya > > I've trimmed the receiver list and kept this on sipping only. I think folks > should take a look at: > http://www.ietf.org/internet-drafts/draft-elwell-sipping-redirection-reason- > 00.txt > and see if this doesn't help fill the gap. > > This could be used in conjunction with History-Info: > http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-02.txt > to achieve the functionality of knowing when a a call has been forwarded > (obviously, not all addressing any billing requirements, but I think all the > information you would need would be available). > > Regards, > Mary. > > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Friday, May 21, 2004 3:55 AM > To: Diego B > Cc: Jonathan Rosenberg; Roy, Radhika R, ALABS; baruch@kayote.com; Chowdhury, > Sayan [Business:WBNG:7Q23]; sip@ietf.org; sipping@ietf.org; fluffy@cisco.com > Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? > > > Diego B writes: > > > In a close environment, I can use whatever method to recognize a > > forward situation. But SIP is about inter operability and integration > > and AFAIK there are some drafts but nothing specific to inform of a call > > forward situation, I don't know the status of Diversion header, but this > > can be a solution if standardized. > > both rpid and diversion headers have become de-facto industry ways to > achieve that you want. may be one day some ietf standardized way to do the > same becomes widely implemented, at which point you can support this new > thing too. > > -- juha > > _______________________________________________ > 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 > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 24 06:37:23 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25379 for ; Mon, 24 May 2004 06:37:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCd6-0007ib-Hi for sipping-archive@odin.ietf.org; Mon, 24 May 2004 06:24:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OAOOd8029661 for sipping-archive@odin.ietf.org; Mon, 24 May 2004 06:24:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCQe-0005sz-Bn for sipping-web-archive@optimus.ietf.org; Mon, 24 May 2004 06:11:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24240 for ; Mon, 24 May 2004 06:11:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSCQa-0005ze-FJ for sipping-web-archive@ietf.org; Mon, 24 May 2004 06:11:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSCPb-0005fx-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 06:10:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSCOf-0005MV-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 06:09:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCEZ-0003mU-RM; Mon, 24 May 2004 05:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSC8y-0002tU-U5 for sipping@optimus.ietf.org; Mon, 24 May 2004 05:53:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23260 for ; Mon, 24 May 2004 05:53:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSC8v-0000Ds-6S for sipping@ietf.org; Mon, 24 May 2004 05:53:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSC7y-0007jK-00 for sipping@ietf.org; Mon, 24 May 2004 05:52:15 -0400 Received: from usjk1002.kddi.com ([211.4.169.18]) by ietf-mx with esmtp (Exim 4.12) id 1BSC7B-00079t-00 for sipping@ietf.org; Mon, 24 May 2004 05:51:25 -0400 Received: from usjk1006.kddi.com (usjk1006 [10.96.2.3]) by usjk1002.kddi.com with ESMTP id i4O9osN06834; Mon, 24 May 2004 18:50:54 +0900 (JST) Received: from usjk1010.kddi.com (localhost [127.0.0.1]) by usjk1006.kddi.com with ESMTP id i4O9osV05534; Mon, 24 May 2004 18:50:54 +0900 (JST) Received: from KDDI-0403PC0002 ([10.100.94.32]) by usjk1010.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20040524095053.HYNF1051.usjk1010.kddi.com@KDDI-0403PC0002>; Mon, 24 May 2004 18:50:53 +0900 To: mary.barnes@nortelnetworks.com, jh@tutpro.com, diegob@mailvision.com Cc: sipping@ietf.org Subject: Solution 1 or Solution 2 (Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ?) From: Takuya Sawada References: In-Reply-To: Message-Id: <200405241850.DHB94354.-BVXUBETB@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Mon, 24 May 2004 18:50:54 +0900 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.2 required=5.0 tests=AWL autolearn=no version=2.60 Hi, In draft-elwell-sipping-redirection-reason-07, two solutions are proposed. Solution 1 proposes new Reason header protocol value and Solution 2 proposes new Contact URI parameter. As discussed in the draft, the main difference between two solutions is that redirect reason is associated with the original URI in the solution 1, whereas it is associated with the new URI in the solution 2. In ISUP, redirect reason is associated with the original called number. So, as far as ISUP interworking is concerned, solution 1 can be a suitable solution. But I think we need more pros and cons discussion on this topic. ---- As shown below, indexes of redirection-to and redirected-from are not necessarily adjacent to each other in the indexes tree. In the solution 1, History-Info of index=1.3 can not express where it is redirected from. In the solution 2, History-Info of index=1.1 can not express where it is redirected to. If we need complete information about from-to redirection, we need another field to be included. For example, redirect-to field for the soltuion 1 or redirected-from parameter for the solution 2. This is messy, though. 1.1 ---------------->o A: Redirect to C / index=1 / (Fork) 1.2 ----------->o------------------>o B \ \ 1.3 ---------------->o C ---- Regards, Takuya > > I've trimmed the receiver list and kept this on sipping only. I think folks > should take a look at: > http://www.ietf.org/internet-drafts/draft-elwell-sipping-redirection-reason- > 00.txt > and see if this doesn't help fill the gap. > > This could be used in conjunction with History-Info: > http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-02.txt > to achieve the functionality of knowing when a a call has been forwarded > (obviously, not all addressing any billing requirements, but I think all the > information you would need would be available). > > Regards, > Mary. > > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Friday, May 21, 2004 3:55 AM > To: Diego B > Cc: Jonathan Rosenberg; Roy, Radhika R, ALABS; baruch@kayote.com; Chowdhury, > Sayan [Business:WBNG:7Q23]; sip@ietf.org; sipping@ietf.org; fluffy@cisco.com > Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? > > > Diego B writes: > > > In a close environment, I can use whatever method to recognize a > > forward situation. But SIP is about inter operability and integration > > and AFAIK there are some drafts but nothing specific to inform of a call > > forward situation, I don't know the status of Diversion header, but this > > can be a solution if standardized. > > both rpid and diversion headers have become de-facto industry ways to > achieve that you want. may be one day some ietf standardized way to do the > same becomes widely implemented, at which point you can support this new > thing too. > > -- juha > > _______________________________________________ > 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 > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 24 06:39:46 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25511 for ; Mon, 24 May 2004 06:39:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCdk-0007wb-Gi for sipping-archive@odin.ietf.org; Mon, 24 May 2004 06:25:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OAP4KY030531 for sipping-archive@odin.ietf.org; Mon, 24 May 2004 06:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCa6-000797-RA for sipping-web-archive@optimus.ietf.org; Mon, 24 May 2004 06:21:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24514 for ; Mon, 24 May 2004 06:21:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSCa2-0001HL-Pl for sipping-web-archive@ietf.org; Mon, 24 May 2004 06:21:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSCZ4-0000wt-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 06:20:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSCY5-0000dx-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 06:19:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCEc-0003my-4P; Mon, 24 May 2004 05:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSC91-0002wE-1x for sipping@optimus.ietf.org; Mon, 24 May 2004 05:53:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23270 for ; Mon, 24 May 2004 05:53:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSC8x-0000E7-Dc for sipping@ietf.org; Mon, 24 May 2004 05:53:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSC81-0007ji-00 for sipping@ietf.org; Mon, 24 May 2004 05:52:18 -0400 Received: from usjk1002.kddi.com ([211.4.169.18]) by ietf-mx with esmtp (Exim 4.12) id 1BSC7L-0007Dr-00; Mon, 24 May 2004 05:51:36 -0400 Received: from usjk1006.kddi.com (usjk1006 [10.96.2.3]) by usjk1002.kddi.com with ESMTP id i4O9p4N06978; Mon, 24 May 2004 18:51:04 +0900 (JST) Received: from usjk1009.kddi.com (localhost [127.0.0.1]) by usjk1006.kddi.com with ESMTP id i4O9p4V05639; Mon, 24 May 2004 18:51:04 +0900 (JST) Received: from KDDI-0403PC0002 ([10.100.94.32]) by usjk1009.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20040524095104.GBIK1060.usjk1009.kddi.com@KDDI-0403PC0002>; Mon, 24 May 2004 18:51:04 +0900 To: fluffy@cisco.com, mdolly@att.com, diegob@mailvision.com, jdrosen@dynamicsoft.com Cc: rrroy@att.com, baruch@kayote.com, sayan.chowdhury@wipro.com, sip@ietf.org, sipping@ietf.org Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? From: Takuya Sawada References: <28F05913385EAC43AF019413F674A01708145CA4@OCCLUST04EVS1.ugd.att.com> In-Reply-To: Message-Id: <200405241851.JAC46755.EBUB-TVBX@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Mon, 24 May 2004 18:51:04 +0900 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.2 required=5.0 tests=AWL autolearn=no version=2.60 Hi, History-Info is the way to go in IETF. I agree with it. However, one of the missing pieces in History-Info, I think, is the mappings of redirection information from/to ISUP/ISDN network. In diversion draft, draft-levy-sip-diversion-07, section 10, elaborated on this topics with the examples. Does anyone have a clear idea about ISUP/ISDN and History-Info mapping? Does anyone have a plan to elaborate how interworking can be achieved? draft-elwell-sipping-redirection-reason may provide redirect reason mappings. But it may also need redirection counter or address presentation mappings when we require a certain level of transparency on call forwarding services. This interworking topic may be out of scope of IETF SIP WG and should be handled in other standard bodies like ITU-T or 3GPP. But I want to be sure that History-Info can offer the capabilities which can cover the mappings from/to ISUP/ISDN call forwarding services. * For example, can we all agree with that redirection counter corresponds with the depth of the dotted index in the last History-Info header? We may allow pruning of the tree because in ISUP only the first and the last redirection infomation can be conveyed. and so on... Regards, Takuya P.S. draft-levy-sip-diversion-07.txt has been deleted even before the expiration date. Does anyone know why? (07-version was published in January 2004, which means it will expire in July) > > The topic of what mechanism you use to know about this forwarding > information has been a long topic with much discussion. Right now, the WG > has selected the history mechanism (which grew out of the diversion work) > work as a WG item. The RPID work has become RFC 3325. Given the long history > of this, I highly recommend that if you think there is a reason that history > will not meet your needs, get that out very soon so that the history work > can be modified. > > I would be amazingly surprised to see diversion standardized. > > Cullen > > > > On 5/21/04 4:06 AM, "Dolly, Martin C, ALABS" wrote: > > > A mechanism for relaying call forwarding information is needed, and I agree > > that the diversion draft is a viable solution. > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Diego B > > Sent: Friday, May 21, 2004 4:29 AM > > To: Jonathan Rosenberg > > Cc: Roy, Radhika R, ALABS; baruch@kayote.com; sayan.chowdhury@wipro.com; > > sip@ietf.org; sipping@ietf.org; fluffy@cisco.com > > Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? > > > > > > Hi; > > > > Agreed, but my first question was exactly that, if there is a standard > > way or standard Headers, to store information about a "forward" call. > > > > In a normal situation, no one will touch the From header and "normally" > > PSTN gateway copy the user-info from the From SIP-URI to the PSTN "B > > number", and this is normally used to create the CDR. > > > > I'm not trying to solve the CDR creation issue or how to bill a forward > > call, but I'm looking to a standard way to store forward information so > > one day this information will be used correctly to create CDRs/billing. > > > > In a close environment, I can use whatever method to recognize a > > forward situation. But SIP is about inter operability and integration > > and AFAIK there are some drafts but nothing specific to inform of a call > > forward situation, I don't know the status of Diversion header, but this > > can be a solution if standardized. > > > > Thanks > > > > Jonathan Rosenberg wrote: > >> To be clear, Baruch is proposing a new SIP header, which the SIP WG > >> would need to worry about. > >> > >> I do not think such a thing is needed. As Keith pointed out, our > >> philosophy to date (and this is a broader IETF thing too), is to make > >> sure that you can *account* for what has happened. That is, that the > >> protocols contain sufficient information to record what transpired in a > >> call/transaction/dialog or whatever. Then, its someone elses problem > >> (for example, 3gpp) to specify how the appropriate information is > >> collected, what billing model is used, and how a CDR is generated. Not > >> to say that these things arent important, they're just not the SIP > >> working group's problem. > >> > >> -Jonathan R. > >> > > > _______________________________________________ > 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 -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 24 07:07:11 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26662 for ; Mon, 24 May 2004 07:07:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDFu-0004dq-Qc for sipping-archive@odin.ietf.org; Mon, 24 May 2004 07:04:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OB4Usq017836 for sipping-archive@odin.ietf.org; Mon, 24 May 2004 07:04:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSD97-0003dn-TR for sipping-web-archive@optimus.ietf.org; Mon, 24 May 2004 06:57:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26247 for ; Mon, 24 May 2004 06:57:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSD93-0004w1-Aw for sipping-web-archive@ietf.org; Mon, 24 May 2004 06:57:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSD82-0004d1-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 06:56:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSD7j-0004KB-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 06:56:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSD1x-0002i9-A2; Mon, 24 May 2004 06:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCuh-0001sr-6d for sipping@optimus.ietf.org; Mon, 24 May 2004 06:42:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25697 for ; Mon, 24 May 2004 06:42:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSCud-0000ER-0a for sipping@ietf.org; Mon, 24 May 2004 06:42:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSCtc-0007gx-00 for sipping@ietf.org; Mon, 24 May 2004 06:41:29 -0400 Received: from eukaryote30.gprs.suomen2g.fi ([62.78.106.30] helo=localhost) by ietf-mx with esmtp (Exim 4.12) id 1BSCsf-00071B-00 for sipping@ietf.org; Mon, 24 May 2004 06:40:31 -0400 Received: from jh by localhost with local (Exim 3.35 #1 (Debian)) id 1BSCpz-00016g-00; Mon, 24 May 2004 13:37:43 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16561.53367.50664.466483@tutpro.com> Date: Mon, 24 May 2004 13:37:43 +0300 To: Takuya Sawada Cc: mary.barnes@nortelnetworks.com, diegob@mailvision.com, sipping@ietf.org Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? In-Reply-To: <200405241848.DIG39159.BEVBB-TUX@kddi.com> References: <200405241848.DIG39159.BEVBB-TUX@kddi.com> X-Mailer: VM 7.17 under Emacs 21.2.1 From: Juha Heinanen 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 takuya, i'm not sure if people want the caller to know why redirection happened. to which category would redirection by enum query fit? -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 24 08:00:17 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29716 for ; Mon, 24 May 2004 08:00:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSE02-00022g-Kh for sipping-archive@odin.ietf.org; Mon, 24 May 2004 07:52:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OBqAa3007850 for sipping-archive@odin.ietf.org; Mon, 24 May 2004 07:52:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDip-0008PO-Uy for sipping-web-archive@optimus.ietf.org; Mon, 24 May 2004 07:34:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28411 for ; Mon, 24 May 2004 07:34:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSDip-0001d5-2q for sipping-web-archive@ietf.org; Mon, 24 May 2004 07:34:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSDhs-0001In-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 07:33:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSDh3-0000zu-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 07:32:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDYo-0006wg-69; Mon, 24 May 2004 07:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDIm-00058b-Nq for sipping@optimus.ietf.org; Mon, 24 May 2004 07:07:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26692 for ; Mon, 24 May 2004 07:07:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSDIi-0000NN-DY for sipping@ietf.org; Mon, 24 May 2004 07:07:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSDHt-00002Y-00 for sipping@ietf.org; Mon, 24 May 2004 07:06:33 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BSDH0-0007ES-00 for sipping@ietf.org; Mon, 24 May 2004 07:05:38 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i4OB4gLc029330; Mon, 24 May 2004 06:04:43 -0500 (CDT) Received: from ericsson.com (racom160247.am.ericsson.se [138.85.160.247]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LHB7YVZT; Mon, 24 May 2004 06:04:35 -0500 Message-ID: <40B1D6C9.9050502@ericsson.com> Date: Mon, 24 May 2004 14:04:41 +0300 X-Sybari-Trust: ef10a401 08d63d2e 74a7d05a 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: Volker Hilt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Session policies Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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, I am not sure whether Volker announced the submission of the draft below last week, but in case he didn't, here you have a link to it: http://www.ietf.org/internet-drafts/draft-hilt-sipping-consider-policy-00.txt The discussions on session policies in the SIPPING session (during the interim) will be partially based on this draft. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 24 09:33: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 JAA05286 for ; Mon, 24 May 2004 09:33:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFQU-0007nb-1d for sipping-archive@odin.ietf.org; Mon, 24 May 2004 09:23:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ODNYBB029980 for sipping-archive@odin.ietf.org; Mon, 24 May 2004 09:23:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFLs-0006tA-Th for sipping-web-archive@optimus.ietf.org; Mon, 24 May 2004 09:18:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04509 for ; Mon, 24 May 2004 09:18:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSFLr-0003cU-40 for sipping-web-archive@ietf.org; Mon, 24 May 2004 09:18:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFKt-0003J3-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 09:17:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSFJt-0002yo-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 09:16:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFBV-0005A6-QD; Mon, 24 May 2004 09:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSF1A-0003lP-Le for sipping@optimus.ietf.org; Mon, 24 May 2004 08:57:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03114 for ; Mon, 24 May 2004 08:57:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSF19-0004mF-Bb for sipping@ietf.org; Mon, 24 May 2004 08:57:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSF0A-0004Td-00 for sipping@ietf.org; Mon, 24 May 2004 08:56:23 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BSEzB-0003tf-00 for sipping@ietf.org; Mon, 24 May 2004 08:55:21 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i4OCskLc016932; Mon, 24 May 2004 07:54:47 -0500 (CDT) Received: from ericsson.com (rvi2-92-76.sw.ericsson.se [153.88.92.76]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LHB7Y619; Mon, 24 May 2004 07:54:39 -0500 Message-ID: <40B1F094.60606@ericsson.com> Date: Mon, 24 May 2004 15:54:44 +0300 X-Sybari-Trust: f57dfe38 08d63d2e 74a7d05a 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: Kumiko Ono CC: Volker Hilt , sipping@ietf.org Subject: Re: [Sipping] Considerations for Session Policies References: <40AA06BD.8090508@bell-labs.com> 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 Kumiko, inline: Kumiko Ono wrote: > Volker and Gonzalo, > > I read "draft-hilt-sipping-consider-policy-00" with great interest. > Here are few comments. > > Section 1: > Is there any order of the two operations? I think the diclosing > operation of the UA usually needs to be done before receiving the > instruction of session-specific policy. Yes, that is the usual order. > In addition, we need separate > messages to diclose media information, such as SUBSCRIBE, in order to > avoid "ghost ring" in the case as shown in Figure 2. Do you have any > idea to avoid "ghost ring"? Preconditions. > > Do we need the other operation that the proxies see if the session > follows the instruction of policies? Making sure that the UAs follow the policies is out of scope. > Section 2-4: > Your proposal is to use the redirect model for session-specific policies. > In my understanding, the two models have the pros and cons as follows: > > Piggyback model vs. Redirect model > > *Piggyback > > pros. > - Less messages to establish a session. This is not necessary true. Sometimes it involves more messages, actually... and a lot of times, piggybacking is just slower. Everytime a UA needs to disclose something to its proxy, it needs to trigger an end-to-end message exchange. If both terminals are on slow radio accesses, the exchange can be much slower than a direct out-of-band exchange with the proxy. > - Easy to correlate a session and the policy. > In this case, the policy is session-specific. > > cons. > - UA needs to set media information to be protected for end-to-middle in > request/response. > - Proxy needs to add policy information to be protected for middle-to- > end in request/response. > - It is too late to enforce the policy to the SDP offer/anwer in 200/ACK > messages. > - Policy information is transmitted to a different network. > - Hard to apply to policy changes during a session. > The session timer mechanism could be used. > > *Redirect model > > pros. > - Policy information can be protected for end-to-end, that is between a > UA and a policy server. > - Policy information is not transmitted outside of the network that has > the policy. > - Easy to apply to policy changes during a session. > > cons. > - More messages to establish a session. > A UAC can know the server with the error code for the request. > However, How does a UAS know the server to have session policy? See above. I do not think this is a disadvantage of this model. > - Hard to correlate a session and the policy. > The message of session-specific policy instruction are different from > messages of session establishment. How does the proxy server determine > what policy is instructed to the session? The proxy can hand the UA a URI whose user part correlates to the session. I do not think this is a hard problem. Thanks, Gonzalo > > I don't know how the redirect model works on 3pcc control that needs the > SDP offer/answer in 200/ACK messages. If the UA discloses the media > information to the proxy using different messages before sending "200 OK", > the redirect model can be benefical in this case. However, I don't > know whether this is applicable to 3pcc control. > > Thanks a lot, > > Kumiko > -- > 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 > -- 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 24 10:34:08 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10413 for ; Mon, 24 May 2004 10:34:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGNI-0008KB-3f for sipping-archive@odin.ietf.org; Mon, 24 May 2004 10:24:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OEOKwu031995 for sipping-archive@odin.ietf.org; Mon, 24 May 2004 10:24:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGGo-00079R-O8 for sipping-web-archive@optimus.ietf.org; Mon, 24 May 2004 10:17:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08920 for ; Mon, 24 May 2004 10:17:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSGGl-00006m-Oc for sipping-web-archive@ietf.org; Mon, 24 May 2004 10:17:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSGFk-00002O-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 10:16:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSGFM-0007li-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 10:16:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFx2-0003u2-Ux; Mon, 24 May 2004 09:57:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFqM-0002i7-IW for sipping@optimus.ietf.org; Mon, 24 May 2004 09:50:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06333 for ; Mon, 24 May 2004 09:50:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSFqK-0005tG-NL for sipping@ietf.org; Mon, 24 May 2004 09:50:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFpL-0005l7-00 for sipping@ietf.org; Mon, 24 May 2004 09:49:16 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BSFnr-0005YX-00 for sipping@ietf.org; Mon, 24 May 2004 09:47:43 -0400 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 i4ODkLC01091; Mon, 24 May 2004 09:46:21 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 May 2004 09:46:00 -0400 Message-ID: From: "Mary Barnes" To: "'Takuya Sawada'" , jh@tutpro.com, diegob@mailvision.com Cc: sipping@ietf.org Subject: RE: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? Date: Mon, 24 May 2004 09:45:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44195.709CCF40" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_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_01C44195.709CCF40 Content-Type: text/plain If option 2 is the preferred option (my view), then there would be no impact on History-Info. If option 1 is the preferred option, then this requires special handling to ensure that the specific reason is captured by History-Info. That seems to be much more awkward, but is certainly open for discussion. Mary. -----Original Message----- From: Takuya Sawada [mailto:tu-sawada@kddi.com] Sent: Monday, May 24, 2004 4:48 AM To: Barnes, Mary [NGC:B601:EXCH]; jh@tutpro.com; diegob@mailvision.com Cc: sipping@ietf.org Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? Hi, Do you have a plan to include the proposal in Johon's draft into History-Info draft? Regards, Takuya > > I've trimmed the receiver list and kept this on sipping only. I think > folks should take a look at: > http://www.ietf.org/internet-drafts/draft-elwell-sipping-redirection-r > eason- > 00.txt > and see if this doesn't help fill the gap. > > This could be used in conjunction with History-Info: > http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-02.txt > to achieve the functionality of knowing when a a call has been > forwarded (obviously, not all addressing any billing requirements, but > I think all the information you would need would be available). > > Regards, > Mary. > > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Friday, May 21, 2004 3:55 AM > To: Diego B > Cc: Jonathan Rosenberg; Roy, Radhika R, ALABS; baruch@kayote.com; Chowdhury, > Sayan [Business:WBNG:7Q23]; sip@ietf.org; sipping@ietf.org; fluffy@cisco.com > Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? > > > Diego B writes: > > > In a close environment, I can use whatever method to recognize a > > forward situation. But SIP is about inter operability and integration > > and AFAIK there are some drafts but nothing specific to inform of a call > > forward situation, I don't know the status of Diversion header, but this > > can be a solution if standardized. > > both rpid and diversion headers have become de-facto industry ways to > achieve that you want. may be one day some ietf standardized way to > do the same becomes widely implemented, at which point you can support > this new thing too. > > -- juha > > _______________________________________________ > 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 > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com ------_=_NextPart_001_01C44195.709CCF40 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ?

If option 2 is the preferred option (my view), then = there would be no impact on History-Info.  If option 1 is the = preferred option, then this requires special handling to ensure that = the specific reason is captured by History-Info.  That seems to be = much more awkward, but is certainly open for discussion.

Mary. 

-----Original Message-----
From: Takuya Sawada [mailto:tu-sawada@kddi.com] =
Sent: Monday, May 24, 2004 4:48 AM
To: Barnes, Mary [NGC:B601:EXCH]; jh@tutpro.com; = diegob@mailvision.com
Cc: sipping@ietf.org
Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who = pays the bill ?


Hi,

Do you have a plan to include the proposal in Johon's = draft into History-Info draft?

Regards,
Takuya

>
> I've trimmed the receiver list and kept this on = sipping only.  I think
> folks should take a look at:
> http://www.ietf.org/internet-drafts/draft-elwell-sippi= ng-redirection-r
> eason-
> 00.txt
> and see if this doesn't help fill the = gap. 
>
> This could be used in conjunction with = History-Info:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-his= tory-info-02.txt
> to achieve the functionality of knowing when a = a call has been
> forwarded (obviously, not all addressing any = billing requirements, but
> I think all the information you would need = would be available).
>
> Regards,
> Mary.
>
> -----Original Message-----
> From: Juha Heinanen [mailto:jh@tutpro.com]
> Sent: Friday, May 21, 2004 3:55 AM
> To: Diego B
> Cc: Jonathan Rosenberg; Roy, Radhika R, ALABS; = baruch@kayote.com; Chowdhury,
> Sayan [Business:WBNG:7Q23]; sip@ietf.org; = sipping@ietf.org; fluffy@cisco.com
> Subject: Re: [Sipping] RE: [Sip] SIP Forward, = Who pays the bill ?
>
>
> Diego B writes:
>
>  > In a close environment, I can use = whatever method to  recognize a
>  > forward situation. But SIP is about = inter operability and integration
>  > and AFAIK there are some drafts but = nothing specific to inform of a call
>  > forward situation, I don't know the = status of Diversion header, but this
>  > can be a solution if = standardized.
>
> both rpid and diversion headers have become = de-facto industry ways to
> achieve that you want.  may be one day = some ietf standardized way to
> do the same becomes widely implemented, at = which point you can support
> this new thing too.
>
> -- juha
>
> = _______________________________________________
> 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
>
>
> = _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the = application of SIP Use
> sip-implementors@cs.columbia.edu for questions = on current sip Use
> sip@ietf.org for new developments of core = SIP


--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi,
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
tu-sawada@kddi.com

------_=_NextPart_001_01C44195.709CCF40-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 24 11:09:49 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12777 for ; Mon, 24 May 2004 11:09:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGw5-00056E-2j for sipping-archive@odin.ietf.org; Mon, 24 May 2004 11:00:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OF0G4x019595 for sipping-archive@odin.ietf.org; Mon, 24 May 2004 11:00:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGd3-0002Ba-2U for sipping-web-archive@optimus.ietf.org; Mon, 24 May 2004 10:40:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10872 for ; Mon, 24 May 2004 10:40:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSGd0-0001xL-Jv for sipping-web-archive@ietf.org; Mon, 24 May 2004 10:40:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSGc1-0001tK-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 10:39:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSGbj-0001ot-00 for sipping-web-archive@ietf.org; Mon, 24 May 2004 10:39:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGO4-0008NU-41; Mon, 24 May 2004 10:25:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGDj-0006dV-Eu for sipping@optimus.ietf.org; Mon, 24 May 2004 10:14:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08543 for ; Mon, 24 May 2004 10:14:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSGDh-0007eI-7d for sipping@ietf.org; Mon, 24 May 2004 10:14:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSGCm-0007ad-00 for sipping@ietf.org; Mon, 24 May 2004 10:13:30 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BSGC0-0007Sq-00 for sipping@ietf.org; Mon, 24 May 2004 10:12:41 -0400 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 i4OEC5C22298; Mon, 24 May 2004 10:12:06 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 May 2004 10:10:59 -0400 Message-ID: From: "Mary Barnes" To: "'Takuya Sawada'" Cc: sipping@ietf.org Subject: RE: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? Date: Mon, 24 May 2004 10:10:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44198.E8BA38C0" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_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_01C44198.E8BA38C0 Content-Type: text/plain I've again pruned the receiver list. Others may be able to provide more detailed responses as to how you would make use of History-Info for your ISUP/ISDN mapping, but I did want to clarify a couple points, indicated by [MB] below. Regards, Mary. -----Original Message----- From: Takuya Sawada [mailto:tu-sawada@kddi.com] Sent: Monday, May 24, 2004 4:51 AM To: fluffy@cisco.com; mdolly@att.com; diegob@mailvision.com; jdrosen@dynamicsoft.com Cc: rrroy@att.com; baruch@kayote.com; Chowdhury, Sayan [Business:WBNG:7Q23]; sip@ietf.org; sipping@ietf.org Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? Hi, History-Info is the way to go in IETF. I agree with it. However, one of the missing pieces in History-Info, I think, is the mappings of redirection information from/to ISUP/ISDN network. In diversion draft, draft-levy-sip-diversion-07, section 10, elaborated on this topics with the examples. Does anyone have a clear idea about ISUP/ISDN and History-Info mapping? Does anyone have a plan to elaborate how interworking can be achieved? draft-elwell-sipping-redirection-reason may provide redirect reason mappings. But it may also need redirection counter or address presentation mappings when we require a certain level of transparency on call forwarding services. [MB] The intent of History-Info in combination with John's recent proposal for a "redirection reason" weren't intended to provide a one to one replacement for the diversion draft. The intent was that by using History-Info to capture all the URIs to which a request has been targeted and also capturing the reasons associated with those retargets, an application could make use of the information to provide end services. Gateways mapping to ISUP, QSIG, etc are one example of an application, but not the only example, thus the functionality provided by History-Info must be kept general. There are uses, per the appendix, that are pure SIP services. This interworking topic may be out of scope of IETF SIP WG and should be handled in other standard bodies like ITU-T or 3GPP. [MB] The impresssion I took from the recent discussion at IETF-59 was that the SIPPING WG is not particularly interested in dealing with how the specific SDOs (eg. ECMA and others) are making use of the SIP building blocks. If the building blocks are insufficient, then certainly input is requested which was the point of John Elwell's redirection reason draft. But I want to be sure that History-Info can offer the capabilities which can cover the mappings from/to ISUP/ISDN call forwarding services. * For example, can we all agree with that redirection counter corresponds with the depth of the dotted index in the last History-Info header? We may allow pruning of the tree because in ISUP only the first and the last redirection infomation can be conveyed. and so on... [MB] Discussion of pruning of the tree was brought up in the past (and specifically highlighted during the session at IETF-59) and the agreement was that there is no reason for the protocol to specify any pruning methodology. It's an application implementation decision. Although, certainly something the various SDOs wanting to use History-Info might want to specify. Regards, Takuya P.S. draft-levy-sip-diversion-07.txt has been deleted even before the expiration date. Does anyone know why? (07-version was published in January 2004, which means it will expire in July) > > The topic of what mechanism you use to know about this forwarding > information has been a long topic with much discussion. Right now, the > WG has selected the history mechanism (which grew out of the diversion > work) work as a WG item. The RPID work has become RFC 3325. Given the > long history of this, I highly recommend that if you think there is a > reason that history will not meet your needs, get that out very soon > so that the history work can be modified. > > I would be amazingly surprised to see diversion standardized. > > Cullen > > > > On 5/21/04 4:06 AM, "Dolly, Martin C, ALABS" wrote: > > > A mechanism for relaying call forwarding information is needed, and > > I agree that the diversion draft is a viable solution. > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > > Diego B > > Sent: Friday, May 21, 2004 4:29 AM > > To: Jonathan Rosenberg > > Cc: Roy, Radhika R, ALABS; baruch@kayote.com; sayan.chowdhury@wipro.com; > > sip@ietf.org; sipping@ietf.org; fluffy@cisco.com > > Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? > > > > > > Hi; > > > > Agreed, but my first question was exactly that, if there is a > > standard way or standard Headers, to store information about a > > "forward" call. > > > > In a normal situation, no one will touch the From header and > > "normally" PSTN gateway copy the user-info from the From SIP-URI to > > the PSTN "B number", and this is normally used to create the CDR. > > > > I'm not trying to solve the CDR creation issue or how to bill a > > forward call, but I'm looking to a standard way to store forward > > information so one day this information will be used correctly to > > create CDRs/billing. > > > > In a close environment, I can use whatever method to recognize a > > forward situation. But SIP is about inter operability and > > integration and AFAIK there are some drafts but nothing specific to > > inform of a call forward situation, I don't know the status of > > Diversion header, but this can be a solution if standardized. > > > > Thanks > > > > Jonathan Rosenberg wrote: > >> To be clear, Baruch is proposing a new SIP header, which the SIP WG > >> would need to worry about. > >> > >> I do not think such a thing is needed. As Keith pointed out, our > >> philosophy to date (and this is a broader IETF thing too), is to > >> make sure that you can *account* for what has happened. That is, > >> that the protocols contain sufficient information to record what > >> transpired in a call/transaction/dialog or whatever. Then, its > >> someone elses problem (for example, 3gpp) to specify how the > >> appropriate information is collected, what billing model is used, > >> and how a CDR is generated. Not to say that these things arent > >> important, they're just not the SIP working group's problem. > >> > >> -Jonathan R. > >> > > > _______________________________________________ > 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 -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ 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 ------_=_NextPart_001_01C44198.E8BA38C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ?

I've again pruned the receiver list.

Others may be able to provide more detailed responses = as to how you would make use of History-Info for your ISUP/ISDN = mapping, but I did want to clarify a couple points, indicated by [MB] = below.

Regards,
Mary.

-----Original Message-----
From: Takuya Sawada [mailto:tu-sawada@kddi.com] =
Sent: Monday, May 24, 2004 4:51 AM
To: fluffy@cisco.com; mdolly@att.com; = diegob@mailvision.com; jdrosen@dynamicsoft.com
Cc: rrroy@att.com; baruch@kayote.com; Chowdhury, = Sayan [Business:WBNG:7Q23]; sip@ietf.org; sipping@ietf.org
Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who = pays the bill ?


Hi,

History-Info is the way to go in IETF. I agree with = it. However, one of the missing pieces in History-Info, I think, is the =

mappings of redirection information from/to ISUP/ISDN = network. In diversion draft, draft-levy-sip-diversion-07, section 10, =

elaborated on this topics with the examples.

Does anyone have a clear idea about ISUP/ISDN and = History-Info mapping? Does anyone have a plan to elaborate how = interworking can be achieved? draft-elwell-sipping-redirection-reason = may provide redirect reason mappings. But it may also need redirection = counter or address presentation mappings when we require a certain = level of transparency on call forwarding services.

[MB] The intent of History-Info in combination with = John's recent proposal for a "redirection reason" weren't = intended to provide a one to one replacement for the diversion = draft.  The intent was that by using History-Info to capture all = the URIs to which a request has been targeted and also capturing the = reasons associated with those retargets, an application could make use = of the information to provide end services.  Gateways mapping to = ISUP, QSIG, etc are one example of an application, but not the only = example, thus the functionality provided by History-Info must be kept = general.  There are uses, per the appendix, that are pure SIP = services. 

This interworking topic may be out of scope of IETF = SIP WG and should be
handled in other standard bodies like ITU-T or = 3GPP.

[MB] The impresssion I took from the recent = discussion at IETF-59 was that the SIPPING WG is not particularly = interested in dealing with how the specific SDOs (eg. ECMA and others) = are making use of the SIP building blocks.  If the building blocks = are insufficient, then certainly input is requested which was the point = of John Elwell's redirection reason draft.

But I want to be sure that History-Info can offer the = capabilities which can cover the mappings from/to ISUP/ISDN call = forwarding services.

* For example, can we all agree with that redirection = counter corresponds
  with the depth of the dotted index in the = last History-Info header?
  We may allow pruning of the tree because in = ISUP only the first and the last
  redirection infomation can be = conveyed.
  and so on...

[MB] Discussion of pruning of the tree was brought up = in the past (and specifically highlighted during the session at = IETF-59) and the agreement was that there is no reason for the protocol = to specify any pruning methodology.  It's an application = implementation decision.  Although, certainly something the = various SDOs wanting to use History-Info might want to specify.  =

Regards,
Takuya

P.S.
draft-levy-sip-diversion-07.txt has been deleted = even before the expiration date. Does anyone know why? (07-version was = published in January 2004, which means it will expire in = July)


>
> The topic of what mechanism you use to know = about this forwarding
> information has been a long topic with much = discussion. Right now, the
> WG has selected the history mechanism (which = grew out of the diversion
> work) work as a WG item. The RPID work has = become RFC 3325. Given the
> long history of this, I highly recommend that = if you think there is a
> reason that history will not meet your needs, = get that out very soon
> so that the history work can be = modified.
>
> I would be amazingly surprised to see diversion = standardized.
>
> Cullen
>
>
>
> On 5/21/04 4:06 AM, "Dolly, Martin C, = ALABS" <mdolly@att.com> wrote:
>
> > A mechanism for relaying call forwarding = information is needed, and
> > I agree that the diversion draft is a = viable solution.
> >
> > -----Original Message-----
> > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On = Behalf Of
> > Diego B
> > Sent: Friday, May 21, 2004 4:29 AM
> > To: Jonathan Rosenberg
> > Cc: Roy, Radhika R, ALABS; = baruch@kayote.com; sayan.chowdhury@wipro.com;
> > sip@ietf.org; sipping@ietf.org; = fluffy@cisco.com
> > Subject: Re: [Sipping] RE: [Sip] SIP = Forward, Who pays the bill ?
> >
> >
> > Hi;
> >
> > Agreed, but my first question was exactly = that, if there is a
> > standard way or standard Headers, to store = information about a
> > "forward" call.
> >
> > In a normal situation, no one will touch = the From header and
> > "normally" PSTN gateway copy the = user-info from the From SIP-URI to
> > the PSTN "B number", and this is = normally used to create the CDR.
> >
> > I'm not trying to solve the CDR creation = issue or how to bill a
> > forward call, but I'm looking to a = standard way to store forward
> > information so one day this information = will be used correctly to
> > create CDRs/billing.
> >
> > In a close environment, I can use whatever = method to  recognize a
> > forward situation. But SIP is about inter = operability and
> > integration and AFAIK there are some = drafts but nothing specific to
> > inform of a call forward situation, I = don't know the status of
> > Diversion header, but this can be a = solution if standardized.
> >
> > Thanks
> >
> > Jonathan Rosenberg wrote:
> >> To be clear, Baruch is proposing a new = SIP header, which the SIP WG
> >> would need to worry about.
> >>
> >> I do not think such a thing is needed. = As Keith pointed out, our
> >> philosophy to date (and this is a = broader IETF thing too), is to
> >> make sure that you can *account* for = what has happened. That is,
> >> that the protocols contain sufficient = information to record what
> >> transpired in a = call/transaction/dialog or whatever. Then, its
> >> someone elses problem (for example, = 3gpp) to specify how the
> >> appropriate information is collected, = what billing model is used,
> >> and how a CDR is generated. Not to say = that these things arent
> >> important, they're just not the SIP = working group's problem.
> >>
> >> -Jonathan R.
> >>
>
>
> = _______________________________________________
> 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


--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi,
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
tu-sawada@kddi.com

_______________________________________________
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

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