From exim@www1.ietf.org Thu Apr 1 02:38:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23293 for ; Thu, 1 Apr 2004 02:38:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8wlv-0000kc-W2 for sipping-archive@odin.ietf.org; Thu, 01 Apr 2004 02:37:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i317btMX002886 for sipping-archive@odin.ietf.org; Thu, 1 Apr 2004 02:37:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8wlv-0000kL-M2 for sipping-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 02:37:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23245 for ; Thu, 1 Apr 2004 02:37:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8wls-0003iQ-00 for sipping-web-archive@ietf.org; Thu, 01 Apr 2004 02:37:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8wkv-0003dn-00 for sipping-web-archive@ietf.org; Thu, 01 Apr 2004 02:36:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8wk9-0003aa-00 for sipping-web-archive@ietf.org; Thu, 01 Apr 2004 02:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8wk7-0000Em-6I; Thu, 01 Apr 2004 02:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8wk4-0000E1-Ip for sipping@optimus.ietf.org; Thu, 01 Apr 2004 02:36:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23201 for ; Thu, 1 Apr 2004 02:35:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8wk0-0003Zh-00 for sipping@ietf.org; Thu, 01 Apr 2004 02:35:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8wj6-0003SP-00 for sipping@ietf.org; Thu, 01 Apr 2004 02:35:00 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B8wiQ-0003Od-00; Thu, 01 Apr 2004 02:34:18 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i317YA324793; Thu, 1 Apr 2004 10:34:10 +0300 (EET DST) X-Scanned: Thu, 1 Apr 2004 10:36:37 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i317abku031624; Thu, 1 Apr 2004 10:36:37 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 007el0Ry; Thu, 01 Apr 2004 10:36:37 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 i317Y2F08163; Thu, 1 Apr 2004 10:34:02 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Apr 2004 10:32:56 +0300 Message-ID: <406BC5A8.4080003@nokia.com> Date: Thu, 01 Apr 2004 10:32:56 +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: SIMPLE mailing list , SIPPING mailing list CC: Gonzalo Camarillo Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2004 07:32:56.0087 (UTC) FILETIME=[8CBF0A70:01C417BB] Content-Transfer-Encoding: 7bit Subject: [Sipping] MESSAGE Exploders 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 draft that discusses a exploder of MESSAGEs. While it appears in the repository, you can download them from: http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING (exploders), I am copying both mailing lists. 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 Fri Apr 2 00:14:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10170 for ; Fri, 2 Apr 2004 00:14:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E6A-0004rs-3n for sipping-archive@odin.ietf.org; Thu, 01 Apr 2004 21:07:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3227wNs018713 for sipping-archive@odin.ietf.org; Thu, 1 Apr 2004 21:07:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9BIY-0000qn-ET for sipping-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 18:08:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06998 for ; Thu, 1 Apr 2004 18:08:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9BIV-0007aA-00 for sipping-web-archive@ietf.org; Thu, 01 Apr 2004 18:08:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9BHZ-0007Uv-00 for sipping-web-archive@ietf.org; Thu, 01 Apr 2004 18:07:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9BH9-0007PH-00 for sipping-web-archive@ietf.org; Thu, 01 Apr 2004 18:07:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B996Z-0007Bv-LI; Thu, 01 Apr 2004 15:48:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95hF-0001Y8-FH for sipping@optimus.ietf.org; Thu, 01 Apr 2004 12:09:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16623 for ; Thu, 1 Apr 2004 10:26:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9452-0005uH-00 for sipping@ietf.org; Thu, 01 Apr 2004 10:26:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9447-0005o1-00 for sipping@ietf.org; Thu, 01 Apr 2004 10:25:12 -0500 Received: from [195.171.110.225] (helo=mailgate.siemenscomms.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1B943U-0005ft-00 for sipping@ietf.org; Thu, 01 Apr 2004 10:24:32 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HVI0050101TL8@siemenscomms.co.uk> for sipping@ietf.org; Thu, 01 Apr 2004 16:22:41 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HVI004BG01S5P@siemenscomms.co.uk> for sipping@ietf.org; Thu, 01 Apr 2004 16:22:40 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id <2CY7R2YD>; Thu, 01 Apr 2004 16:25:26 +0100 Content-return: allowed Date: Thu, 01 Apr 2004 16:24:00 +0100 From: "Elwell, John" To: sipping@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667D4ACD6@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="Boundary_(ID_ed4bpVGpKt60kEnc8/yhzw)" Subject: [Sipping] Redirection by a UAS Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_ed4bpVGpKt60kEnc8/yhzw) Content-type: text/plain Content-Transfer-Encoding: 7BIT SIP allows a UAS to reject an INVITE request with a 3xx response. A particular application of this is to achieve call forwarding no reply or deflection. With forwarding no reply the 3xx response is issued in accordance with a script in the UA after alerting the user for a certain time. With deflection the 3xx response is issued as a direct result of user action in response to alerting. A problem arises if the request cannot successfully be redirected in accordance with the contact URI in the 3xx response. Reasons could include, but are not limited to, the following: URI not found, not authorised, busy. The question is, how to notify the redirecting UAS that the request has failed. In the case of forwarding no reply, it might be desirable to continue alerting the user at that UAS until it can be determined that forwarding is successful (e.g., when another UAS begins alerting). In the case of deflection it might be useful to inform the user that deflection was unsuccessful and give the user another opportunity to answer the call. The only way of achieving this at present is for the proxy that retargets the request as a result of the 3xx response to repeat the request to the original contact on detecting failure of the retargeted request. This is not entirely satisfactory because it does not explicitly indicate the reason for repeating the request and it may have undesirable impact on call detail recording / missed call logging at the UAS. Does anyone else see this as a problem and is anyone aware of alternative solutions? John Elwell (john.elwell@siemens.com) --Boundary_(ID_ed4bpVGpKt60kEnc8/yhzw) Content-type: text/html Content-Transfer-Encoding: 7BIT Redirection by a UAS

SIP allows a UAS to reject an INVITE request with a 3xx response. A particular application of this is to achieve call forwarding no reply or deflection. With forwarding no reply the 3xx response is issued in accordance with a script in the UA after alerting the user for a certain time. With deflection the 3xx response is issued as a direct result of user action in response to alerting.

A problem arises if the request cannot successfully be redirected in accordance with the contact URI in the 3xx response. Reasons could include, but are not limited to, the following: URI not found, not authorised, busy. The question is, how to notify the redirecting UAS that the request has failed. In the case of forwarding no reply, it might be desirable to continue alerting the user at that UAS until it can be determined that forwarding is successful (e.g., when another UAS begins alerting). In the case of deflection it might be useful to inform the user that deflection was unsuccessful and give the user another opportunity to answer the call.

The only way of achieving this at present is for the proxy that retargets the request as a result of the 3xx response to repeat the request to the original contact on detecting failure of the retargeted request. This is not entirely satisfactory because it does not explicitly indicate the reason for repeating the request and it may have undesirable impact on call detail recording / missed call logging at the UAS.

Does anyone else see this as a problem and is anyone aware of alternative solutions?

John Elwell (john.elwell@siemens.com)

--Boundary_(ID_ed4bpVGpKt60kEnc8/yhzw)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 2 10:23: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 KAA13633 for ; Fri, 2 Apr 2004 10:23:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9N9F-0002kC-DY for sipping-archive@odin.ietf.org; Fri, 02 Apr 2004 06:47:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32BljkQ010549 for sipping-archive@odin.ietf.org; Fri, 2 Apr 2004 06:47:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9K6T-0002Y7-8u for sipping-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 03:32:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28807 for ; Fri, 2 Apr 2004 03:32:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9K6R-0002Kz-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 03:32:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9K5X-0002Eo-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 03:31:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9K4i-00027W-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 03:30:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ECD-0008Mj-Cf; Thu, 01 Apr 2004 21:14:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Cdh-0001Tc-Lb for sipping@optimus.ietf.org; Thu, 01 Apr 2004 19:34:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14038 for ; Thu, 1 Apr 2004 19:34:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Cdf-0002Yv-00 for sipping@ietf.org; Thu, 01 Apr 2004 19:34:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Ccl-0002TH-00 for sipping@ietf.org; Thu, 01 Apr 2004 19:33:32 -0500 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 1B9Cc1-0002Nz-00 for sipping@ietf.org; Thu, 01 Apr 2004 19:32:45 -0500 Received: from tate (host4.brodsoft.com [66.160.10.4]) by broadsoft.com (8.12.11/8.12.9) with SMTP id i320WeHh072853 for ; Thu, 1 Apr 2004 19:32:40 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sipping] Redirection by a UAS Date: Thu, 1 Apr 2004 19:36:52 -0500 Message-ID: <006401c4184a$98919220$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <50B1CBA96870A34799A506B2313F2667D4ACD6@ntht201e> 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 > SIP allows a UAS to reject an INVITE request > with a 3xx response. A particular application > of this is to achieve call forwarding no reply > or deflection. With forwarding no reply the > 3xx response is issued in accordance with a > script in the UA after alerting the user for > a certain time. With deflection the 3xx > response is issued as a direct result of user > action in response to alerting. > > A problem arises if the request cannot > successfully be redirected in accordance with > the contact URI in the 3xx response. Reasons > could include, but are not limited to, the > following: URI not found, not authorized, busy. > The question is, how to notify the redirecting > UAS that the request has failed. In the case of > forwarding no reply, it might be desirable to > continue alerting the user at that UAS until > it can be determined that forwarding is > successful (e.g., when another UAS begins > alerting). In the case of deflection it might > be useful to inform the user that deflection > was unsuccessful and give the user another > opportunity to answer the call. > > The only way of achieving this at present is > for the proxy that retargets the request as > a result of the 3xx response to repeat the > request to the original contact on detecting > failure of the retargeted request. This is not > entirely satisfactory because it does not > explicitly indicate the reason for repeating > the request and it may have undesirable impact > on call detail recording / missed call logging > at the UAS. > > Does anyone else see this as a problem and is > anyone aware of alternative solutions? solution 1: Instead of sending a 3xx, it could act as a transaction-stateful-proxy and proxy the INVITE to the forwarded-to party. solution 2: Go through the standards process to define a mechanism that allows service policies and relationships to be clearly communicated within a 3xx that contains multiple Contact entries. Using the Contact's q values helps with fault tolerance; however more information is needed to clearly communicate other common services like simultaneous-ringing, call-forward-busy, and call-forward-no-answer. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 2 16:41:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02893 for ; Fri, 2 Apr 2004 16:41:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WPb-0008Sz-0z for sipping-archive@odin.ietf.org; Fri, 02 Apr 2004 16:41:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LfEZ5032546 for sipping-archive@odin.ietf.org; Fri, 2 Apr 2004 16:41:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WPa-0008Sr-SB for sipping-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:41:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02817 for ; Fri, 2 Apr 2004 16:41:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WPY-00078w-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 16:41:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WO4-0006lV-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 16:39:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9WMO-0006J9-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 16:37:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WLn-00062R-KH; Fri, 02 Apr 2004 16:37:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9UKw-00079m-BY for sipping@optimus.ietf.org; Fri, 02 Apr 2004 14:28:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23393 for ; Fri, 2 Apr 2004 14:28:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9UKt-0001OB-00 for sipping@ietf.org; Fri, 02 Apr 2004 14:28:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9UJv-0001GZ-00 for sipping@ietf.org; Fri, 02 Apr 2004 14:27:16 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B9UJb-00018u-00 for sipping@ietf.org; Fri, 02 Apr 2004 14:26:55 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 02 Apr 2004 11:35:41 -0800 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i32JQNCC014633; Fri, 2 Apr 2004 14:26:24 -0500 (EST) Received: from mhammer-w2k03.cisco.com ([64.100.229.254]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AYE52608; Fri, 2 Apr 2004 11:26:22 -0800 (PST) Message-Id: <4.3.2.7.2.20040402142517.0319a530@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Apr 2004 14:26:21 -0500 To: From: Michael Hammer Subject: RE: [Sipping] Redirection by a UAS Cc: In-Reply-To: <006401c4184a$98919220$2b01a8c0@broadsoft.com> References: <50B1CBA96870A34799A506B2313F2667D4ACD6@ntht201e> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 07:36 PM 4/1/2004 -0500, Brett Tate wrote: > > SIP allows a UAS to reject an INVITE request > > with a 3xx response. A particular application > > of this is to achieve call forwarding no reply > > or deflection. With forwarding no reply the > > 3xx response is issued in accordance with a > > script in the UA after alerting the user for > > a certain time. With deflection the 3xx > > response is issued as a direct result of user > > action in response to alerting. > > > > A problem arises if the request cannot > > successfully be redirected in accordance with > > the contact URI in the 3xx response. Reasons > > could include, but are not limited to, the > > following: URI not found, not authorized, busy. > > The question is, how to notify the redirecting > > UAS that the request has failed. In the case of > > forwarding no reply, it might be desirable to > > continue alerting the user at that UAS until > > it can be determined that forwarding is > > successful (e.g., when another UAS begins > > alerting). In the case of deflection it might > > be useful to inform the user that deflection > > was unsuccessful and give the user another > > opportunity to answer the call. > > > > The only way of achieving this at present is > > for the proxy that retargets the request as > > a result of the 3xx response to repeat the > > request to the original contact on detecting > > failure of the retargeted request. This is not > > entirely satisfactory because it does not > > explicitly indicate the reason for repeating > > the request and it may have undesirable impact > > on call detail recording / missed call logging > > at the UAS. > > > > Does anyone else see this as a problem and is > > anyone aware of alternative solutions? > >solution 1: > Instead of sending a 3xx, it could act as a > transaction-stateful-proxy and proxy the > INVITE to the forwarded-to party. > >solution 2: > Go through the standards process to define > a mechanism that allows service policies and > relationships to be clearly communicated > within a 3xx that contains multiple Contact > entries. Using the Contact's q values helps > with fault tolerance; however more information > is needed to clearly communicate other common > services like simultaneous-ringing, > call-forward-busy, and call-forward-no-answer. Would it be possible to include a last resort Contact that refers back to itself, but in such a way that the local part has a convention that indicates that the forwarding failed? Mike >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Apr 2 16:58:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04694 for ; Fri, 2 Apr 2004 16:58:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wff-0001R5-Jn for sipping-archive@odin.ietf.org; Fri, 02 Apr 2004 16:57:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LvpDp005519 for sipping-archive@odin.ietf.org; Fri, 2 Apr 2004 16:57:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wff-0001Qt-Ba for sipping-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:57:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04584 for ; Fri, 2 Apr 2004 16:57:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Wfd-0002bk-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 16:57:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wbq-0001lO-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 16:53:54 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WaD-0001Ld-02 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 16:52:13 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WXD-000849-Tw for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 16:49:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WX9-0005IP-Cr; Fri, 02 Apr 2004 16:49:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9VLg-0006Ag-RU for sipping@optimus.ietf.org; Fri, 02 Apr 2004 15:33:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27437 for ; Fri, 2 Apr 2004 15:33:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9VLf-0002QL-00 for sipping@ietf.org; Fri, 02 Apr 2004 15:33:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9VKp-0002J9-00 for sipping@ietf.org; Fri, 02 Apr 2004 15:32:16 -0500 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 1B9VKD-0002CG-00 for sipping@ietf.org; Fri, 02 Apr 2004 15:31:37 -0500 Received: from tate (host4.brodsoft.com [66.160.10.4]) by broadsoft.com (8.12.11/8.12.9) with SMTP id i32KVVCH095365; Fri, 2 Apr 2004 15:31:31 -0500 (EST) Reply-To: From: "Brett Tate" To: "'Michael Hammer'" Cc: Subject: RE: [Sipping] Redirection by a UAS Date: Fri, 2 Apr 2004 15:35:44 -0500 Message-ID: <008601c418f2$133ddc70$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4.3.2.7.2.20040402145352.00b9af00@cia.cisco.com> 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 > > > >solution 2: > > > > Go through the standards process to define > > > > a mechanism that allows service policies and > > > > relationships to be clearly communicated > > > > within a 3xx that contains multiple Contact > > > > entries. Using the Contact's q values helps > > > > with fault tolerance; however more information > > > > is needed to clearly communicate other common > > > > services like simultaneous-ringing, > > > > call-forward-busy, and call-forward-no-answer. > > > > > > Would it be possible to include a last resort > > > Contact that refers back to itself, but in such > > > a way that the local part has a convention that > > > indicates that the forwarding failed? > > > >Yes, if both parties agree upon a solution. > > Why both? The contact is provided by the > called party. The calling party simply uses > the contact. Only the called party needs to know > what the convention means. Did I miss something? Trying the contact entry with the highest q value is relatively obvious; however if I recall correctly, rfc3261 does not even make choosing the highest q value a MUST. The relationship between this contact entry and other contact entries are currently not obvious or well standardized. Some vendors simultaneous-ring if the q values are the same; other vendors do not. Some vendors advance contact entries upon any 4xx-6xx response; others do not. Some vendors only advance if no response is received. There is currently no defined parameter within a contact entry which can communicate a no-answer timer indicating the desire to advance to the next contact. However I assume that some vendors have toyed with trying to use the expires parameter for this purpose. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 2 16:59: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 QAA04981 for ; Fri, 2 Apr 2004 16:59:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WgU-0001bn-G4 for sipping-archive@odin.ietf.org; Fri, 02 Apr 2004 16:58:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32Lwgvs006179 for sipping-archive@odin.ietf.org; Fri, 2 Apr 2004 16:58:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WgU-0001ba-C9 for sipping-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:58:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04813 for ; Fri, 2 Apr 2004 16:58:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WgS-0002qK-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 16:58:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wcj-000204-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 16:54:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WaN-0001Ld-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 16:52:23 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WTm-0007nk-Pp for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 16:45:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WTK-0002e7-1v; Fri, 02 Apr 2004 16:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Uj1-0001DX-5D for sipping@optimus.ietf.org; Fri, 02 Apr 2004 14:53:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24987 for ; Fri, 2 Apr 2004 14:53:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Uiy-0005Ct-00 for sipping@ietf.org; Fri, 02 Apr 2004 14:53:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Ui5-000545-00 for sipping@ietf.org; Fri, 02 Apr 2004 14:52:14 -0500 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 1B9Uh3-0004sy-00 for sipping@ietf.org; Fri, 02 Apr 2004 14:51:09 -0500 Received: from tate (host4.brodsoft.com [66.160.10.4]) by broadsoft.com (8.12.11/8.12.9) with SMTP id i32Jp62l088441; Fri, 2 Apr 2004 14:51:06 -0500 (EST) Reply-To: From: "Brett Tate" To: "'Michael Hammer'" Cc: Subject: RE: [Sipping] Redirection by a UAS Date: Fri, 2 Apr 2004 14:55:19 -0500 Message-ID: <007501c418ec$6df7c780$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4.3.2.7.2.20040402142517.0319a530@cia.cisco.com> 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 > > > Does anyone else see this as a problem and is > > > anyone aware of alternative solutions? > > > >solution 1: > > Instead of sending a 3xx, it could act as a > > transaction-stateful-proxy and proxy the > > INVITE to the forwarded-to party. > > > >solution 2: > > Go through the standards process to define > > a mechanism that allows service policies and > > relationships to be clearly communicated > > within a 3xx that contains multiple Contact > > entries. Using the Contact's q values helps > > with fault tolerance; however more information > > is needed to clearly communicate other common > > services like simultaneous-ringing, > > call-forward-busy, and call-forward-no-answer. > > Would it be possible to include a last resort > Contact that refers back to itself, but in such > a way that the local part has a convention that > indicates that the forwarding failed? Yes, if both parties agree upon a solution. Many vendors have either chosen to implement a b2bua or proxy to resolve the issue. Others have implemented 3xx proprietary solutions. I am not aware on anyone having tried to standardize a 3xx solution. The main reason is because it typically isn't the best solution for complex services. However it definitely would be beneficial for basic services. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 2 16:59:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05127 for ; Fri, 2 Apr 2004 16:59:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wgg-0001g5-CW for sipping-archive@odin.ietf.org; Fri, 02 Apr 2004 16:58:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32Lwsop006447 for sipping-archive@odin.ietf.org; Fri, 2 Apr 2004 16:58:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wgg-0001fu-8q for sipping-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:58:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04875 for ; Fri, 2 Apr 2004 16:58:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Wge-0002so-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 16:58:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wcv-00022L-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 16:55:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WaO-0001S5-02 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 16:52:24 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WTX-0007nj-8t for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 16:45:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WTM-0002el-RA; Fri, 02 Apr 2004 16:45:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Umz-0001S6-Mi for sipping@optimus.ietf.org; Fri, 02 Apr 2004 14:57:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25174 for ; Fri, 2 Apr 2004 14:57:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Umw-0005kg-00 for sipping@ietf.org; Fri, 02 Apr 2004 14:57:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Um0-0005df-00 for sipping@ietf.org; Fri, 02 Apr 2004 14:56:17 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B9UlQ-0005TG-00 for sipping@ietf.org; Fri, 02 Apr 2004 14:55:40 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 02 Apr 2004 11:54:59 -0800 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i32Jt4cp001160; Fri, 2 Apr 2004 14:55:05 -0500 (EST) Received: from mhammer-w2k03.cisco.com ([64.100.229.254]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AYE55536; Fri, 2 Apr 2004 11:55:03 -0800 (PST) Message-Id: <4.3.2.7.2.20040402145352.00b9af00@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Apr 2004 14:55:03 -0500 To: From: Michael Hammer Subject: RE: [Sipping] Redirection by a UAS Cc: In-Reply-To: <007501c418ec$6df7c780$2b01a8c0@broadsoft.com> References: <4.3.2.7.2.20040402142517.0319a530@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 02:55 PM 4/2/2004 -0500, Brett Tate wrote: > > >solution 2: > > > Go through the standards process to define > > > a mechanism that allows service policies and > > > relationships to be clearly communicated > > > within a 3xx that contains multiple Contact > > > entries. Using the Contact's q values helps > > > with fault tolerance; however more information > > > is needed to clearly communicate other common > > > services like simultaneous-ringing, > > > call-forward-busy, and call-forward-no-answer. > > > > Would it be possible to include a last resort > > Contact that refers back to itself, but in such > > a way that the local part has a convention that > > indicates that the forwarding failed? > >Yes, if both parties agree upon a solution. Why both? The contact is provided by the called party. The calling party simply uses the contact. Only the called party needs to know what the convention means. Did I miss something? Mike _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Apr 2 17:24: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 RAA08476 for ; Fri, 2 Apr 2004 17:24:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X4X-0001QB-G7 for sipping-archive@odin.ietf.org; Fri, 02 Apr 2004 17:23:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32MNXeM005463 for sipping-archive@odin.ietf.org; Fri, 2 Apr 2004 17:23:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X4X-0001Q2-8Y for sipping-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:23:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08282 for ; Fri, 2 Apr 2004 17:23:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9X4U-0000I7-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 17:23:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wys-00070h-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 17:17:42 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WxH-0006bI-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 17:16:03 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9Wsa-0000ae-DG for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 17:11:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WsP-0006h3-MF; Fri, 02 Apr 2004 17:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Ws6-0006Xp-OH for sipping@optimus.ietf.org; Fri, 02 Apr 2004 17:10:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06938 for ; Fri, 2 Apr 2004 17:10:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ws4-0005T7-00 for sipping@ietf.org; Fri, 02 Apr 2004 17:10:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WqA-000502-00 for sipping@ietf.org; Fri, 02 Apr 2004 17:08:43 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WpC-0004dV-00; Fri, 02 Apr 2004 17:07:42 -0500 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i32M75h07991; Fri, 2 Apr 2004 16:07:05 -0600 Message-ID: <406DE407.7000701@dynamicsoft.com> Date: Fri, 02 Apr 2004 16:07:03 -0600 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Miguel Garcia , SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo References: <406BC5A8.4080003@nokia.com> <406DE1C8.3040309@dynamicsoft.com> In-Reply-To: <406DE1C8.3040309@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Simple] MESSAGE Exploders 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (Comments to self inline) Ben Campbell wrote: [...] > Saying the exploder MUST NOT include the URI list in the outbound > messages seems a little severe. I can imagine applications where I want > the recipients to know the list. This could be useful for "reply to all" > sort of functions. But if we do allow this, we would need to give the > sender a way to choose, possibly on a per-URI basis. (Sort of a "cc" vs. > "bcc" thing.) This sort of functionality seems to be required by REQ-GROUP-2 and REQ-GROUP-4 from the advanced IM reqs draft. [...] _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Apr 2 17:25: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 RAA09336 for ; Fri, 2 Apr 2004 17:25:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X6O-00028l-VQ for sipping-archive@odin.ietf.org; Fri, 02 Apr 2004 17:25:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32MPSm9008221 for sipping-archive@odin.ietf.org; Fri, 2 Apr 2004 17:25:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X6O-00028J-QQ for sipping-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:25:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09176 for ; Fri, 2 Apr 2004 17:25:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9X6M-0000kL-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 17:25:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9X27-0007fG-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 17:21:04 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WyF-0006bI-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 17:17:03 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9Wnp-0000Ik-9B for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 17:06:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wnb-0003rs-UL; Fri, 02 Apr 2004 17:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wn5-0003W1-0T for sipping@optimus.ietf.org; Fri, 02 Apr 2004 17:05:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06005 for ; Fri, 2 Apr 2004 17:05:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Wn2-0004Af-00 for sipping@ietf.org; Fri, 02 Apr 2004 17:05:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WjS-0003Ur-00 for sipping@ietf.org; Fri, 02 Apr 2004 17:01:47 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Wfz-0002Zt-00; Fri, 02 Apr 2004 16:58:11 -0500 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i32LvVh07784; Fri, 2 Apr 2004 15:57:31 -0600 Message-ID: <406DE1C8.3040309@dynamicsoft.com> Date: Fri, 02 Apr 2004 15:57:28 -0600 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo References: <406BC5A8.4080003@nokia.com> In-Reply-To: <406BC5A8.4080003@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Simple] MESSAGE Exploders 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I like this approach overall. A couple of comments and questions. Apologies if these have already been discussed. Is it legal for the list parameter to point to something other than a body part? That is, can I have external lists? Saying the exploder MUST NOT include the URI list in the outbound messages seems a little severe. I can imagine applications where I want the recipients to know the list. This could be useful for "reply to all" sort of functions. But if we do allow this, we would need to give the sender a way to choose, possibly on a per-URI basis. (Sort of a "cc" vs. "bcc" thing.) Instead of saying that message exploders must always send message requests, we might consider saying the outbound request method must match the outbound method. This would allow for exploders that know how to explode more than one method. When condidering DoS issues, it might be worth suggesting behavior if the exploder finds duplicate URIs on the list. For example, I could put the same URI in a bunch of times, and have a nice DoS amplifier. Miguel Garcia wrote: > Hi: > > I have just submitted a draft that discusses a exploder of MESSAGEs. > > While it appears in the repository, you can download them from: > > http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt > > http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html > > > Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING > (exploders), I am copying both mailing lists. > > Regards, > > Miguel _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Apr 2 18:19: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 SAA12655 for ; Fri, 2 Apr 2004 18:19:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Xvi-0002hp-Sr for sipping-archive@odin.ietf.org; Fri, 02 Apr 2004 18:19:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32NIK3I009942 for sipping-archive@odin.ietf.org; Fri, 2 Apr 2004 18:18:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9XvY-0002Xx-J6 for sipping-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 18:18:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12597 for ; Fri, 2 Apr 2004 18:18:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9XvQ-0000FJ-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 18:18:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9XuT-00007X-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 18:17:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Xts-0007nC-00 for sipping-web-archive@ietf.org; Fri, 02 Apr 2004 18:16:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9XnC-0007wd-Tn; Fri, 02 Apr 2004 18:09:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Xlq-0007Sc-HC for sipping@optimus.ietf.org; Fri, 02 Apr 2004 18:08:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11605 for ; Fri, 2 Apr 2004 18:08:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Xln-0006iB-00 for sipping@ietf.org; Fri, 02 Apr 2004 18:08:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Xkt-0006ba-00 for sipping@ietf.org; Fri, 02 Apr 2004 18:07:20 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B9XkV-0006UP-00; Fri, 02 Apr 2004 18:06:55 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2004 15:14:28 +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 i32N6MKj006377; Fri, 2 Apr 2004 15:06:22 -0800 (PST) Received: from cisco.com ([161.44.79.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHI30980; Fri, 2 Apr 2004 18:06:21 -0500 (EST) Message-ID: <406DF1EC.4050400@cisco.com> Date: Fri, 02 Apr 2004 18:06:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo Subject: Re: [Sipping] MESSAGE Exploders draft References: <406BC5A8.4080003@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Miguel, In general the approach in the draft seems reasonable to me. I see one area of ambiguity, having to do with how multipart bodies are handled. The draft says to remove the list and include everything else. But even your example doesn't do that - it also removes the multipart/mixed wrapper. Of course in this particular example that makes perfect sense, but it goes beyond what the draft says to do. There are more complex cases: - for security there could be signed body parts. - The signature could be on the multipart containing the message and list. It would have to be removed. - The signature could be on just the message. Presumably it should remain. - There could be other body parts referenced by cid: urls in other headers in the message. I think there needs to be a more prescriptive way of defining what gets passed on in the exploded messages. This is really just a manifestation of a more general problem of how to decide how different body parts should be processed. It potentially exists in a normal, unexploded, MESSAGE. I think at least part of the answer lies with Content-Disposition. I think there should be clarity about the content-disposition should be for the body part(s) that MESSAGE interprets as message content. Probably "render" (which is default for sip) would be an appropriate content-disposition for message content. Also, I think there should be some clarity about what the content-disposition should be for various kinds of multipart containers when used in the various ways they may be used in sip. I'm not quite sure what the answer is here. The list itself is of course referenced from a cid: url. It is the url and its placement that determines how the corresponding body part should be processed. For these, the content-disposition should be some value that doesn't imply some other sort of processing. I think it can't be any of "session", "render", "alert", or "icon". Maybe it could be "attachment". Paul Miguel Garcia wrote: > Hi: > > I have just submitted a draft that discusses a exploder of MESSAGEs. > > While it appears in the repository, you can download them from: > > http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt > > http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html > > > Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING > (exploders), I am copying both mailing lists. > > Regards, > > Miguel _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Apr 5 13:27: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 NAA16474 for ; Mon, 5 Apr 2004 13:27: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 1BAXsh-0005fp-FK for sipping-archive@odin.ietf.org; Mon, 05 Apr 2004 13:27:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35HRVKE021810 for sipping-archive@odin.ietf.org; Mon, 5 Apr 2004 13:27:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXsh-0005fc-3n for sipping-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 13:27: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 NAA16336 for ; Mon, 5 Apr 2004 13:27:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAXse-00009F-00 for sipping-web-archive@ietf.org; Mon, 05 Apr 2004 13:27:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAXYS-0005Uf-00 for sipping-web-archive@ietf.org; Mon, 05 Apr 2004 13:06:38 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAXRu-0004Xk-00 for sipping-web-archive@ietf.org; Mon, 05 Apr 2004 12:59:50 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAXGE-0000Ew-Mi for sipping-web-archive@ietf.org; Mon, 05 Apr 2004 12:47:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXC1-0000Ae-DL; Mon, 05 Apr 2004 12:43:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWze-0006W5-J9 for sipping@optimus.ietf.org; Mon, 05 Apr 2004 12:30: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 MAA13579 for ; Mon, 5 Apr 2004 12:30:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWzd-0000RI-00 for sipping@ietf.org; Mon, 05 Apr 2004 12:30:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWyl-0000K3-00 for sipping@ietf.org; Mon, 05 Apr 2004 12:29:44 -0400 Received: from [195.171.110.225] (helo=mailgate.siemenscomms.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BAWy7-00008f-00 for sipping@ietf.org; Mon, 05 Apr 2004 12:29:03 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HVP00L01HP614@siemenscomms.co.uk> for sipping@ietf.org; Mon, 05 Apr 2004 17:27:07 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HVP00K3PHP6PH@siemenscomms.co.uk>; Mon, 05 Apr 2004 17:27:06 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id <212F8WA6>; Mon, 05 Apr 2004 17:29:51 +0100 Content-return: allowed Date: Mon, 05 Apr 2004 17:28:26 +0100 From: "Elwell, John" Subject: RE: [Sipping] Redirection by a UAS To: "'Michael Hammer'" , brett@broadsoft.com Cc: sipping@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667D4ACE1@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain 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 Michael, You wrote: > Would it be possible to include a last resort Contact that > refers back to > itself, but in such a way that the local part has a convention that > indicates that the forwarding failed? > This sounds interesting. Would the fact that the Call-ID has not changed be a sufficient indication that it is a repeat attempt, presumably because forwarding failed? John (john.elwell@siemens.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 Apr 5 14:11:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20138 for ; Mon, 5 Apr 2004 14:11: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 1BAYYy-0000M0-Np for sipping-archive@odin.ietf.org; Mon, 05 Apr 2004 14:11:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35IBC6n001360 for sipping-archive@odin.ietf.org; Mon, 5 Apr 2004 14: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 1BAYYy-0000Lm-Fe for sipping-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 14:11: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 OAA19971 for ; Mon, 5 Apr 2004 14:11:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAYYv-0005ci-00 for sipping-web-archive@ietf.org; Mon, 05 Apr 2004 14:11:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAY8E-00034N-00 for sipping-web-archive@ietf.org; Mon, 05 Apr 2004 13:43:35 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAY5w-0002ef-00 for sipping-web-archive@ietf.org; Mon, 05 Apr 2004 13:41:13 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAY50-0005XA-AI for sipping-web-archive@ietf.org; Mon, 05 Apr 2004 13:40:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAY4o-000302-8Y; Mon, 05 Apr 2004 13:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAY43-0002n8-Kl for sipping@optimus.ietf.org; Mon, 05 Apr 2004 13:39: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 NAA18937 for ; Mon, 5 Apr 2004 13:39:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAY41-0002CD-00 for sipping@ietf.org; Mon, 05 Apr 2004 13:39:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAXz9-0001Ko-00 for sipping@ietf.org; Mon, 05 Apr 2004 13:34:12 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BAXm0-0006tx-00 for sipping@ietf.org; Mon, 05 Apr 2004 13:20:36 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 05 Apr 2004 10:18:29 -0700 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i35HK4CC016434; Mon, 5 Apr 2004 13:20:04 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-64-100-224-139.cisco.com [64.100.224.139]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AYF46889; Mon, 5 Apr 2004 10:20:02 -0700 (PDT) Message-Id: <4.3.2.7.2.20040405131707.02b656d0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Apr 2004 13:20:02 -0400 To: "Elwell, John" From: Michael Hammer Subject: RE: [Sipping] Redirection by a UAS Cc: brett@broadsoft.com, sipping@ietf.org In-Reply-To: <50B1CBA96870A34799A506B2313F2667D4ACE1@ntht201e> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 05:28 PM 4/5/2004 +0100, Elwell, John wrote: >Michael, > >You wrote: > > Would it be possible to include a last resort Contact that > > refers back to > > itself, but in such a way that the local part has a convention that > > indicates that the forwarding failed? > > >This sounds interesting. Would the fact that the Call-ID has not changed be >a sufficient indication that it is a repeat attempt, presumably because >forwarding failed? > >John (john.elwell@siemens.com) Because of cases where re-transmissions are used (which could be temporarily mis-routed), I would not want to rely on an implicit indication. An explicit index into a stored call state (which I assume exists) would seem better to me. Mike _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Apr 6 08:08:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09476 for ; Tue, 6 Apr 2004 08:08: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 1BApMr-0004AW-Mj for sipping-archive@odin.ietf.org; Tue, 06 Apr 2004 08:07:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36C7nEZ016024 for sipping-archive@odin.ietf.org; Tue, 6 Apr 2004 08:07:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BApMr-0004AK-CD for sipping-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 08:07: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 IAA09338 for ; Tue, 6 Apr 2004 08:07:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BApMq-0000YU-00 for sipping-web-archive@ietf.org; Tue, 06 Apr 2004 08:07:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAp7X-0005EF-00 for sipping-web-archive@ietf.org; Tue, 06 Apr 2004 07:51:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAoYn-0002Mz-00 for sipping-web-archive@ietf.org; Tue, 06 Apr 2004 07:16:05 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAoYn-0006mm-G3 for sipping-web-archive@ietf.org; Tue, 06 Apr 2004 07:16:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoYk-0000Ie-5e; Tue, 06 Apr 2004 07:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoXo-0008Ug-3G for sipping@optimus.ietf.org; Tue, 06 Apr 2004 07:15: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 HAA05600 for ; Tue, 6 Apr 2004 07:15:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAoXn-00028A-00 for sipping@ietf.org; Tue, 06 Apr 2004 07:15:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAoRD-0000tZ-00 for sipping@ietf.org; Tue, 06 Apr 2004 07:08:16 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx with esmtp (Exim 4.12) id 1BAoCX-00061Y-00 for sipping@ietf.org; Tue, 06 Apr 2004 06:53:05 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HVQ00F01WST7V@siemenscomms.co.uk> for sipping@ietf.org; Tue, 06 Apr 2004 11:50:54 +0100 (BST) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HVQ00DB0WRVU3@siemenscomms.co.uk>; Tue, 06 Apr 2004 11:50:19 +0100 (BST) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2653.19) id <2L4MDWRR>; Tue, 06 Apr 2004 11:51:41 +0100 Content-return: allowed Date: Tue, 06 Apr 2004 11:51:40 +0100 From: "Elwell, John" Subject: RE: [Sipping] Redirection by a UAS To: "'Michael Hammer'" Cc: brett@broadsoft.com, sipping@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667D4ACE8@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain 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 > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: 05 April 2004 18:20 > To: Elwell, John > Cc: brett@broadsoft.com; sipping@ietf.org > Subject: RE: [Sipping] Redirection by a UAS > > > At 05:28 PM 4/5/2004 +0100, Elwell, John wrote: > >Michael, > > > >You wrote: > > > Would it be possible to include a last resort Contact that > > > refers back to > > > itself, but in such a way that the local part has a > convention that > > > indicates that the forwarding failed? > > > > >This sounds interesting. Would the fact that the Call-ID has > not changed be > >a sufficient indication that it is a repeat attempt, > presumably because > >forwarding failed? > > > >John (john.elwell@siemens.com) > > Because of cases where re-transmissions are used (which could be > temporarily mis-routed), I would not want to rely on an implicit > indication. An explicit index into a stored call state > (which I assume > exists) would seem better to me. > > Mike > In that case, perhaps History-Info would suffice. The UAS could see from History-Info that the request has been redirected from itself elsewhere and then back again. John _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 7 07:34:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11165 for ; Wed, 7 Apr 2004 07:34: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 1BBBJV-00087Q-BH for sipping-archive@odin.ietf.org; Wed, 07 Apr 2004 07:33:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37BXnLc031189 for sipping-archive@odin.ietf.org; Wed, 7 Apr 2004 07:33:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBJR-00086s-Ok for sipping-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 07:33: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 HAA11008 for ; Wed, 7 Apr 2004 07:33:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBBJQ-0007M2-00 for sipping-web-archive@ietf.org; Wed, 07 Apr 2004 07:33:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBA9B-00071L-00 for sipping-web-archive@ietf.org; Wed, 07 Apr 2004 06:19:06 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BB949-0006wT-00 for sipping-web-archive@ietf.org; Wed, 07 Apr 2004 05:09:50 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BB8xw-00069a-DY for sipping-web-archive@ietf.org; Wed, 07 Apr 2004 05:03:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB8tr-0003R7-Sd; Wed, 07 Apr 2004 04:59:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuzT-0008L9-RJ for sipping@optimus.ietf.org; Tue, 06 Apr 2004 14:08: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 OAA12775 for ; Tue, 6 Apr 2004 14:08:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAuzR-0002Nk-00 for sipping@ietf.org; Tue, 06 Apr 2004 14:08:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAutR-0001MB-00 for sipping@ietf.org; Tue, 06 Apr 2004 14:01:50 -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 1BAukH-0000EP-00 for sipping@ietf.org; Tue, 06 Apr 2004 13:52:21 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 Apr 2004 09:59:28 +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 i36HplGF010984; Tue, 6 Apr 2004 10:51:48 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARU49906; Tue, 6 Apr 2004 10:51:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <50D70048-87F3-11D8-BF5F-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: Dean Willis , Hisham Khartabil , Allison Mankin , Robert Sparks , John Peterson , Ted Hardie , Gonzalo Camarillo , Rohan Mahy , Alan Johnston , Adam Roach From: Rohan Mahy Date: Tue, 6 Apr 2004 10:53:31 -0700 To: sipping (E-mail) X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Subject: [Sipping] Joint Interim Meeting Mon May 24 - Wed May 26 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello All, Please mark your calendars. I'd like to announce a joint interim of the SIP, SIPPING, SIMPLE, and XCON WGs. Nokia has generously agreed to host the event either at their offices near Boston or in a neighboring hotel during the week of May 24. Please reserve the following dates for the WGs that you are interested 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 can catch flights. (the actual agenda is subject to change, including the dates of various WG meetings). There will be no fee, however please let Hisham and myself know if you are planning to attend by clicking on the Yes or Maybe links below: mailto:rohan@cisco.com? Cc=hisham.khartabil@nokia.com&Subject=[interim]yes mailto:rohan@cisco.com? Cc=hisham.khartabil@nokia.com&Subject=[interim]maybe Wireless will be provided. As usual, I will be making T-shirts. If you are interested in buying one, please send your shirt size to me. More details on the agenda and hotel accommodations will be forthcoming shortly. thanks, -rohan _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Apr 7 07:34:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11284 for ; Wed, 7 Apr 2004 07:34:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBJw-0008MY-Aq for sipping-archive@odin.ietf.org; Wed, 07 Apr 2004 07:34:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37BYGPJ032112 for sipping-archive@odin.ietf.org; Wed, 7 Apr 2004 07:34:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBJv-0008Lh-TM for sipping-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 07:34: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 HAA11137 for ; Wed, 7 Apr 2004 07:34:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBBJv-0007Se-00 for sipping-web-archive@ietf.org; Wed, 07 Apr 2004 07:34:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBAAg-000781-00 for sipping-web-archive@ietf.org; Wed, 07 Apr 2004 06:20:39 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BB94E-000734-00 for sipping-web-archive@ietf.org; Wed, 07 Apr 2004 05:09:55 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BB8xw-00069j-FZ for sipping-web-archive@ietf.org; Wed, 07 Apr 2004 05:03:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB8tp-0003N9-5y; Wed, 07 Apr 2004 04:59:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAZ6f-0001ut-70 for sipping@optimus.ietf.org; Mon, 05 Apr 2004 14:46:01 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23576 for ; Mon, 5 Apr 2004 14:45:57 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BAZ6A-0001de-RN; Mon, 05 Apr 2004 14:45:30 -0400 X-test-idtracker: no To: IETF-Announce :; From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Mon, 05 Apr 2004 14:45:30 -0400 Subject: [Sipping] Last Call: 'The Early Session Disposition Type for the Session Initiation Protocol (SIP)' to Proposed Standard Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,TO_HAS_SPACES autolearn=no version=2.60 The IESG has received a request from the Session Initiation Proposal Investigation WG to consider the following documents: - 'The Early Session Disposition Type for the Session Initiation Protocol (SIP) ' as a Proposed Standard - 'Early Media and Ringing Tone Generation in the Session Initiation Protocol ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-19. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sipping-early-disposition- 01.txt http://www.ietf.org/internet-drafts/draft-ietf-sipping-early-media-01.txt _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Apr 7 13:20:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14105 for ; Wed, 7 Apr 2004 13:20: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 1BBGiz-0002Fk-96 for sipping-archive@odin.ietf.org; Wed, 07 Apr 2004 13:20:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37HKTMl008653 for sipping-archive@odin.ietf.org; Wed, 7 Apr 2004 13:20:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGiz-0002FK-2q for sipping-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 13:20: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 NAA14011 for ; Wed, 7 Apr 2004 13:20:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGix-0000FH-00 for sipping-web-archive@ietf.org; Wed, 07 Apr 2004 13:20:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBFU9-0005Eq-00 for sipping-web-archive@ietf.org; Wed, 07 Apr 2004 12:01:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBE2c-0004Ij-00 for sipping-web-archive@ietf.org; Wed, 07 Apr 2004 10:28:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBE28-0000XV-KA; Wed, 07 Apr 2004 10:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBE1C-0008TA-UA for sipping@optimus.ietf.org; Wed, 07 Apr 2004 10:27: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 KAA28948 for ; Wed, 7 Apr 2004 10:27:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBE19-00047u-00 for sipping@ietf.org; Wed, 07 Apr 2004 10:27:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBDNi-00068z-00 for sipping@ietf.org; Wed, 07 Apr 2004 09:46:18 -0400 Received: from krr.debis.hu ([195.228.20.2] helo=ns.t-systems.co.hu) by ietf-mx with esmtp (Exim 4.12) id 1BBCEe-0006Ev-00 for sipping@ietf.org; Wed, 07 Apr 2004 08:32:53 -0400 Received: from MAILSRV.uns.t-systems.tss ([172.16.1.64]) by ns.t-systems.co.hu (8.9.3p2/8.9.3/Debian 8.9.3-21) with ESMTP id QAA26692 for ; Wed, 7 Apr 2004 16:50:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Apr 2004 13:54:20 +0200 Message-ID: <29026DD9543DBF4BB2B4F9325683E47A426B3C@MAILSRV.uns.t-systems.tss> Thread-Topic: Initiating TLS from behind a firewall&nat Thread-Index: AcQclw9wAjzYEbNLTqe5OdDB3/n8MQ== From: =?iso-8859-2?Q?Petr=F3czi_Attila?= To: Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Initiating TLS from behind a firewall&nat Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All, does anybody know about some standard for initiating a TLS connection = from behind a firewall with NAT? In details: Our client is sitting behind a firewall with NAT and wants = to connect to a SIP UA somewhere on the Internet. We have an http/https = proxy installed on the firewall&nat device.=20 Our client first has to build up a TCP connection through the proxy to = the other SIP device before starting the TLS handshake to secure the = channel. For example in case of https the browser sends a plain connect = message to the 443 port of the distant https server before starting the = TLS handshake on a new socket layered over the TCP socket. What about = SIP? I think we may send an INFO message to build up the TCP connection, and = after the TLS handshake can we send our first INVITE message through the = secured TLS channel. Am I right?=20 I have found = http://www.jdrosen.net/papers/draft-rosenberg-sip-entfw-01.txt and=20 http://ncl.cgu.edu/publications/paulsamy_chatterjee.PDF, but they do not = deal with such details.=20 Best regards, Attila =20 Attila Petr=F3czi T-Systems RIC Kft. H-1097 Budapest, K=F6nyves K=E1lm=E1n krt. 12-14. Telefon: +36 1 456 5361 Fax: +36 1 456 5499 mailto:HYPERLINK = "mailto:attila.petroczi@t-systems.co.hu"attila.petroczi@t-systems.co.hu = =20 www.t-systems.co.hu = =20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Apr 8 04:41: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 EAA20307 for ; Thu, 8 Apr 2004 04:41: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 1BBV5k-0003hd-0o for sipping-archive@odin.ietf.org; Thu, 08 Apr 2004 04:40:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i388etvt014233 for sipping-archive@odin.ietf.org; Thu, 8 Apr 2004 04:40:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBV5j-0003hU-Od for sipping-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 04:40: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 EAA20125 for ; Thu, 8 Apr 2004 04:40:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBV5g-0005Bw-00 for sipping-web-archive@ietf.org; Thu, 08 Apr 2004 04:40:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBSda-0005uj-00 for sipping-web-archive@ietf.org; Thu, 08 Apr 2004 02:03:44 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBRK4-0007gj-00 for sipping-web-archive@ietf.org; Thu, 08 Apr 2004 00:39:28 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBRHo-0006kt-0v for sipping-web-archive@ietf.org; Thu, 08 Apr 2004 00:37:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBRHh-0007KV-OR; Thu, 08 Apr 2004 00:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBRGp-00078t-TO for sipping@optimus.ietf.org; Thu, 08 Apr 2004 00:36:08 -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 AAA14421 for ; Thu, 8 Apr 2004 00:36:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBRGn-0007Kd-00 for sipping@ietf.org; Thu, 08 Apr 2004 00:36:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBOin-0000C8-00 for sipping@ietf.org; Wed, 07 Apr 2004 21:52:50 -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 1BBNRe-0002qM-00 for sipping@ietf.org; Wed, 07 Apr 2004 20:31:02 -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 i380UQKj024040; Wed, 7 Apr 2004 17:30:26 -0700 (PDT) Received: from [128.107.170.113] ([128.107.170.113]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANW82896; Wed, 7 Apr 2004 17:30:25 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 07 Apr 2004 17:30:27 -0700 From: Cullen Jennings To: "'sipping@ietf.org'" CC: Orit Levin , Henning Schulzrinne , Jonathan Rosenberg Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] User with multiple sessions in Conference 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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In a conference, here are many cases where a single user may have set up multiple SIP dialogs with the focus. For example, using one UA instance for audio and another UA instance for IM. Or connected on both cell phone and on desk phone in office. Right now the conference package seems a little underspecified in how to deal with this and we need to clear this up. I'm tossing out two proposal below. Comments? Ideas? Can we choose one? Could be close something like this on this list? -------------------------------------------------------------- Proposal 1: The User Element gets a new attribute called contact. This attribute contains the contact that the focus used for this dialog. Each dialog results in a separate User Element instance and the uri is used to correlate the fact that they are the same user. For anonymous calls the system needs to generate separate anonymous user uri's so they can be separated from one another. For Example, 1234 5678 --------------------------------------------------------------- Proposal 2: The data in the User Element gets split between a User Element and a new Session Element that is placed inside the User Element. The media stream elements are put inside the Session. 1234 5678 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 8 18:44:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04073 for ; Thu, 8 Apr 2004 18:44: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 1BBiFP-0008LX-8n for sipping-archive@odin.ietf.org; Thu, 08 Apr 2004 18:43:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38MhljA032083 for sipping-archive@odin.ietf.org; Thu, 8 Apr 2004 18:43:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiFL-0008LD-Bs for sipping-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 18:43: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 SAA04027 for ; Thu, 8 Apr 2004 18:43:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiFH-00077T-00 for sipping-web-archive@ietf.org; Thu, 08 Apr 2004 18:43:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBgJW-0000j9-00 for sipping-web-archive@ietf.org; Thu, 08 Apr 2004 16:39:56 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBdXW-00051D-00 for sipping-web-archive@ietf.org; Thu, 08 Apr 2004 13:42:11 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBdJG-000180-1V for sipping-web-archive@ietf.org; Thu, 08 Apr 2004 13:27:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBdIu-0001yJ-HR; Thu, 08 Apr 2004 13:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBdI8-0001ri-Vi for sipping@optimus.ietf.org; Thu, 08 Apr 2004 13:26: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 NAA05499 for ; Thu, 8 Apr 2004 13:26:14 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBdI6-0003BO-00 for sipping@ietf.org; Thu, 08 Apr 2004 13:26:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBadc-00010d-00 for sipping@ietf.org; Thu, 08 Apr 2004 10:36:18 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BBYOc-0000QI-00 for sipping@ietf.org; Thu, 08 Apr 2004 08:12:39 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38CBeE20206; Thu, 8 Apr 2004 15:11:40 +0300 (EET DST) X-Scanned: Thu, 8 Apr 2004 15:11:28 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i38CBS1r032581; Thu, 8 Apr 2004 15:11:28 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00XuVosK; Thu, 08 Apr 2004 15:11:26 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 i38CBQF00936; Thu, 8 Apr 2004 15:11:26 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Apr 2004 15:11:22 +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] User with multiple sessions in Conference Package Date: Thu, 8 Apr 2004 15:11:22 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978CD@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] User with multiple sessions in Conference Package Thread-Index: AcQdI1W4JaOglVucSkSn6HHWJFgMCQAPuj+w To: , Cc: , , X-OriginalArrivalTime: 08 Apr 2004 12:11:22.0810 (UTC) FILETIME=[9B9EE9A0:01C41D62] 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 Why do you need the focus to know that it is the same user (human)? I = don't understand the use case. Can you elaborate? Thanks, Hisham > -----Original Message----- > From: sipping-admin@ietf.org=20 > [mailto:sipping-admin@ietf.org]On Behalf Of > ext Cullen Jennings > Sent: 08.April.2004 03:30 > To: 'sipping@ietf.org' > Cc: Orit Levin; Henning Schulzrinne; Jonathan Rosenberg > Subject: [Sipping] User with multiple sessions in Conference Package >=20 >=20 >=20 > In a conference, here are many cases where a single user may=20 > have set up > multiple SIP dialogs with the focus. For example, using one=20 > UA instance for > audio and another UA instance for IM. Or connected on both=20 > cell phone and on > desk phone in office. Right now the conference package seems a little > underspecified in how to deal with this and we need to clear this up. >=20 > I'm tossing out two proposal below. Comments? Ideas? Can we=20 > choose one? > Could be close something like this on this list? >=20 > -------------------------------------------------------------- >=20 > Proposal 1:=20 >=20 > The User Element gets a new attribute called contact. This attribute > contains the contact that the focus used for this dialog. Each dialog > results in a separate User Element instance and the uri is=20 > used to correlate > the fact that they are the same user. For anonymous calls the=20 > system needs > to generate separate anonymous user uri's so they can be=20 > separated from one > another.=20 >=20 > For Example, >=20 > > > 1234 > =20 > > 5678 > > >=20 > --------------------------------------------------------------- >=20 > Proposal 2:=20 >=20 > The data in the User Element gets split between a User=20 > Element and a new > Session Element that is placed inside the User Element. The=20 > media stream > elements are put inside the Session. >=20 > > > > 1234 > =20 > > 5678 > > > >=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 Apr 9 18:09: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 SAA26620 for ; Fri, 9 Apr 2004 18:09: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 1BC4Au-00065j-JG for sipping-archive@odin.ietf.org; Fri, 09 Apr 2004 18:08:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39M8avT023411 for sipping-archive@odin.ietf.org; Fri, 9 Apr 2004 18:08:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4Au-00065W-EW for sipping-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 18:08: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 SAA26522 for ; Fri, 9 Apr 2004 18:08:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC4Ap-0007jT-00 for sipping-web-archive@ietf.org; Fri, 09 Apr 2004 18:08:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC3vb-0006oN-00 for sipping-web-archive@ietf.org; Fri, 09 Apr 2004 17:52:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BC3hS-0005cR-00 for sipping-web-archive@ietf.org; Fri, 09 Apr 2004 17:38:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC3hK-0007WK-5T; Fri, 09 Apr 2004 17:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC3h7-0007RQ-Jz for sipping@optimus.ietf.org; Fri, 09 Apr 2004 17:37: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 RAA24328 for ; Fri, 9 Apr 2004 17:37:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC3h4-0005a5-00 for sipping@ietf.org; Fri, 09 Apr 2004 17:37:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC3Mj-0004A8-00 for sipping@ietf.org; Fri, 09 Apr 2004 17:16:46 -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 1BC370-0002RQ-00 for sipping@ietf.org; Fri, 09 Apr 2004 17:00:30 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Apr 2004 13:09:23 +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 i39KxuKj025878 for ; Fri, 9 Apr 2004 13:59:57 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM68691; Fri, 9 Apr 2004 16:59:55 -0400 (EDT) Message-ID: <40770ECB.7010900@cisco.com> Date: Fri, 09 Apr 2004 16:59:55 -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: sipping@ietf.org Subject: Re: [Sipping] Last Call: 'The Early Session Disposition Type for the Session Initiation Protocol (SIP)' to Proposed Standard References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I just read thru this again. I found one loose end. In section 4: Sending early media using a different offer/answer exchange than the one used for sending regular media helps avoid media clipping in case of forking. The UAC can reject or mute new offers for early media without muting the sessions that will carry media when the original INVITE is accepted. The UAC can give priority to media received over the latter sessions. This way, the application server model transitions from early to regular media at the right moment. There is one case where the UAC still may have difficulty knowing which media to render - the case when multiple 200 responses make it back to the UAC, because multiple UAS's answered at almost the same time. This is similar to the case of receiving multiple early media streams in the gateway model - you can't necessarily decide which media stream matches which sip message, so if the intent is to hang up on one call and retain the other, it may take time to figure out which was the right media stream to play. I don't know that this changes the arguments in a material way. An implementation that wants to cover all the bases will in this case want to take some of the same remediation steps as in the gateway case, which is a lot of pain. Most likely the typical approach will be to ignore the problem on the assumption that it will rarely happen, and that clipping is acceptable in that case. I don't have strong feelings if this should be mentioned in the draft or not. 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 Apr 9 18:32:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28497 for ; Fri, 9 Apr 2004 18:32:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4Xo-0003HL-89 for sipping-archive@odin.ietf.org; Fri, 09 Apr 2004 18:32:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39MWGbg012604 for sipping-archive@odin.ietf.org; Fri, 9 Apr 2004 18:32:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4Xo-0003HD-3m for sipping-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 18:32: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 SAA28452 for ; Fri, 9 Apr 2004 18:32:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC4Xk-000201-00 for sipping-web-archive@ietf.org; Fri, 09 Apr 2004 18:32:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC4UK-0001dQ-00 for sipping-web-archive@ietf.org; Fri, 09 Apr 2004 18:28:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BC4P0-0001Am-00 for sipping-web-archive@ietf.org; Fri, 09 Apr 2004 18:23:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4Or-0001us-Ks; Fri, 09 Apr 2004 18:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4OH-0001rR-Kt for sipping@optimus.ietf.org; Fri, 09 Apr 2004 18:22: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 SAA27989 for ; Fri, 9 Apr 2004 18:22:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC4OD-00013b-00 for sipping@ietf.org; Fri, 09 Apr 2004 18:22:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC4Gx-0000VU-00 for sipping@ietf.org; Fri, 09 Apr 2004 18:14:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BC48Y-0007Y0-00 for sipping@ietf.org; Fri, 09 Apr 2004 18:06:10 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2004 15:16:07 -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 i39M5ZCC024525 for ; Fri, 9 Apr 2004 18:05:35 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM72617; Fri, 9 Apr 2004 18:05:34 -0400 (EDT) Message-ID: <40771E2E.1080008@cisco.com> Date: Fri, 09 Apr 2004 18:05:34 -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: sipping@ietf.org References: <200403302147.QAA14364@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re:draft-camarillo-sipping-uri-list-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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Section 4 says: As for any other SIP request, the size of requests carrying URI lists MUST NOT exceed 1300 bytes, unless the user agent client has positive knowledge that the message will not traverse a congestion-unsafe link at any hop, or that the message size is at least 200 bytes less than the lowest MTU value found en route to the server. I was curious about the implications of this, so I did some counting. I took the example in section 9 and stripped out all the leading blanks to get a plausible size estimate. The number I got was 1242, with four urls in the list. Each additional URL (of the size in the example) adds 37 bytes. So a list with more than 5 urls exceeds the 1300 byte limit. That says to me that this technique is pretty much useless except in carefully controlled networks, or when compression is used. Seems pretty limiting. So it seems likely that in practice content indirection will have to be used. 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 Apr 12 12:06:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26574 for ; Mon, 12 Apr 2004 12:06: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 1BD3x8-0005tg-Ub for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 12:06:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CG6UiN022668 for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 12:06:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3x8-0005tX-FO for sipping-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 12:06: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 MAA26545 for ; Mon, 12 Apr 2004 12:06:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD3x6-00047N-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 12:06:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD3w5-0003zM-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 12:05:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD3uo-0003lJ-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 12:04:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3uk-0005fj-JQ; Mon, 12 Apr 2004 12:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3uC-0005eW-G7 for sipping@optimus.ietf.org; Mon, 12 Apr 2004 12:03: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 MAA26440 for ; Mon, 12 Apr 2004 12:03:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD3u9-0003hZ-00 for sipping@ietf.org; Mon, 12 Apr 2004 12:03:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD3s1-0003RW-00 for sipping@ietf.org; Mon, 12 Apr 2004 12:01:14 -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 1BD3qt-00039u-00 for sipping@ietf.org; Mon, 12 Apr 2004 12:00:03 -0400 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 i3CFxH2Q017406; Mon, 12 Apr 2004 08:59:19 -0700 (PDT) Received: from [128.107.170.99] ([128.107.170.99]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOA67936; Mon, 12 Apr 2004 08:59:16 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 12 Apr 2004 08:59:14 -0700 From: Cullen Jennings To: Eric Burger , "'sipping@ietf.org'" , , Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Conf stuff in natann 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 Their is a bit of weird inconsistency in the having the parameters that are passed to the __sip-conf service invocation embedded in the user portion. In the annc and dialog service, there are no parameters in the user portion of the URI. Yet in the conf service, the conf id is embedded in the user portion. I think this is wrong. It should be __sip-conf@mediaserver.example.net;conf=uniqueIdentifier This makes it feasible to specify routing rules for proxies that correctly get all the traffic for the service to the media server. Particularly if the media server is behind a NAT. Could you change the draft to make the conf service invocation consistent with the annc and dialog? 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 Mon Apr 12 13:34: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 NAA00317 for ; Mon, 12 Apr 2004 13:34: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 1BD5Ju-0007KI-OE for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 13:34:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CHY6LP028158 for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 13:34:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5Ju-0007K5-Jx for sipping-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 13:34: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 NAA00311 for ; Mon, 12 Apr 2004 13:34:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5Js-0007hH-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 13:34:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD5Im-0007We-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 13:32:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD5I0-0007Ox-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 13:32:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5Ht-0006uV-TS; Mon, 12 Apr 2004 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5HZ-0006t1-7M for sipping@optimus.ietf.org; Mon, 12 Apr 2004 13:31: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 NAA00262 for ; Mon, 12 Apr 2004 13:31:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5HV-0007OI-00 for sipping@ietf.org; Mon, 12 Apr 2004 13:31:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD5Gk-0007Hc-00 for sipping@ietf.org; Mon, 12 Apr 2004 13:30:51 -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 1BD5Ft-00079f-00 for sipping@ietf.org; Mon, 12 Apr 2004 13:29:57 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2004 09:38:12 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3CHTMGF020815; Mon, 12 Apr 2004 10:29:23 -0700 (PDT) Received: from [128.107.170.99] ([128.107.170.99]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOA75698; Mon, 12 Apr 2004 10:29:21 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 12 Apr 2004 10:29:19 -0700 From: Cullen Jennings To: Andy Spitzer , Eric Burger , "'sipping@ietf.org'" , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Conf stuff in natann 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 Thanks for the fast response. I'm lost on how you imagine this working - I think you will need to walk me through it. Let's say the domain is cisco.com and I have two media servers ms1.cisco.com and ms2.cisco.com. And my conference ID's are 6 digit numbers. Are you suggesting that ms1.cisco.com and ms2.cisco.com know that __sip-conf=1 belongs to ms1 and __sip-conf=2 belongs to ms2 and they both send a REGISTER message to the proxy and ms2 registers __sip-conf=2@cisco.com with a contact pointing to ms2.cisco.com? I don't see how they could register all the possible conference Ids in any useful way. Mostly because the message needs to routed to the ms before the ms will create the conference and conference needs to be created before it's id can be registered and the registration needs to happen before the routing and thus we have a circular loop of dependencies in time. I'm proposing that the proxy route to the correct media server by having the host portion of the URI be ms1.cisco.com or ms2.cisco.com On 4/12/04 9:28 AM, "Andy Spitzer" wrote: > Cullen, > > The reason for having the conf id as part of the user part, was because > unlike the other services (annc, ivr, and dialog), conferencing is not > stand alone. With annc, ivr, and dialog, each session is unique in > independent. With conferencing, however, multiple sessions make up a > particular conference. > > As such, a particular conference must live on a particular media server. > All participants into that conference must reach the same media server. > By placing the conf id in the user part, it makes the conference look like > a user on a particular media server, and as such any proxy can use the > correct routing rules for users in order to reach the correct media server > assigned to that conference. Just the same way they would route users to > a particular endpoint. > > If the conf id was done as you describe, it would mean proxies would have > to look into the parameters to determine which conference was being > requested in order to determine which media server to INVITE. We didn't > want to force proxies to do that, so it was decided the user part was more > proxy friendly. > > Your approach is certainly feasible, and was indeed originally > considered. I believe it may be possible to support both simultainously. > > --Andy Spitzer > woof@snowshore.com > > On Mon, 12 Apr 2004 08:59:14 -0700, Cullen Jennings > wrote: > >> >> Their is a bit of weird inconsistency in the having the parameters that >> are >> passed to the __sip-conf service invocation embedded in the user portion. >> >> In the annc and dialog service, there are no parameters in the user >> portion >> of the URI. Yet in the conf service, the conf id is embedded in the user >> portion. >> >> I think this is wrong. It should be >> >> __sip-conf@mediaserver.example.net;conf=uniqueIdentifier >> >> This makes it feasible to specify routing rules for proxies that >> correctly >> get all the traffic for the service to the media server. Particularly if >> the >> media server is behind a NAT. >> >> Could you change the draft to make the conf service invocation consistent >> with the annc and dialog? >> >> 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 Mon Apr 12 13:53:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01461 for ; Mon, 12 Apr 2004 13:53: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 1BD5c5-000159-RY for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 13:52:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CHqrQK004159 for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 13:52:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5c5-000150-L6 for sipping-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 13: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 NAA01441 for ; Mon, 12 Apr 2004 13:52:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5c2-0002Le-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 13:52:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD5aU-0002BK-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 13:51:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD5ZU-0001wI-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 13:50:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5ZM-0000TS-1U; Mon, 12 Apr 2004 13:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5YW-0000Ma-4E for sipping@optimus.ietf.org; Mon, 12 Apr 2004 13:49: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 NAA01203 for ; Mon, 12 Apr 2004 13:49:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5YS-0001m4-00 for sipping@ietf.org; Mon, 12 Apr 2004 13:49:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD5Wt-0001YS-00 for sipping@ietf.org; Mon, 12 Apr 2004 13:47:32 -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 1BD5Tt-00016O-00 for sipping@ietf.org; Mon, 12 Apr 2004 13:44:25 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2004 09:53:53 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3CHhqKj029238; Mon, 12 Apr 2004 10:43:52 -0700 (PDT) Received: from [128.107.170.99] ([128.107.170.99]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOA77236; Mon, 12 Apr 2004 10:43:49 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 12 Apr 2004 10:43:47 -0700 Subject: Re: [Sipping] User with multiple sessions in Conference Package From: Cullen Jennings To: , CC: Orit Levin , Henning Schulzrinne , Jonathan Rosenberg Message-ID: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017978CD@esebe019.ntc.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 I'll take a stab at explaining :-) If someone has a roster displayed on some device - they want to see that one person, Cullen is in the conference they don't want to sees that their are 4 participants, Cullen-Cell-Phone, Cullen-Speaker-Phone, Cullen-JABBER_GATEWAY, Cullen-VIDEO-ICHAT_GW. More importantly, they want to be able to use a user interface to boot Cullen out of the conference not have to go and somehow magically figure out which devices to boot out since they are being used by Cullen. If their are 10 participants that are all Anonymous, you still want to be able to know their are 10 participants not 1 participant called Anonymous that seems to have dialed in from 10 devices. Given that SIP AOR correspond to a user and is not a single device. There are basically three levels off aggregation happening here. There are users. Each user can have multiple SIP dialogs that got them into the conference. Each one of these SIP dialogs can be started and terminated independently. For example one may be dialed out while another dialed in and one may be active while others may be ongoing. Inside of each SIP dialog, there can be multiple media stream (audio, video, etc). The three levels are Users, SIP Sessions or Dialogs, Media Sessions. Unfortunately, the draft as written supports two things and the User level information and the SIP session level information is mixed together. I think this needs to get fixed. One more use case, many audio conference systems announce when a user joins of leaves. This is really annoying when someone transfers from the cell phone to desk phone. Let me give you a scenario that I think XCON should support. Cullen dials in to conf from cell phone and is announced. Cullen then dials in from desk phone and is *not* announced because the user Cullen is already in the conference. Cullen hangs up cell phone and this is *not* announced because Cullen is still in the conference. Cullen hangs up his desk phone and the conference announces that "Fluffy has left the building" because he is no longer in the conference. On 4/8/04 5:11 AM, "hisham.khartabil@nokia.com" wrote: > Why do you need the focus to know that it is the same user (human)? I don't > understand the use case. Can you elaborate? > > Thanks, > Hisham > >> -----Original Message----- >> From: sipping-admin@ietf.org >> [mailto:sipping-admin@ietf.org]On Behalf Of >> ext Cullen Jennings >> Sent: 08.April.2004 03:30 >> To: 'sipping@ietf.org' >> Cc: Orit Levin; Henning Schulzrinne; Jonathan Rosenberg >> Subject: [Sipping] User with multiple sessions in Conference Package >> >> >> >> In a conference, here are many cases where a single user may >> have set up >> multiple SIP dialogs with the focus. For example, using one >> UA instance for >> audio and another UA instance for IM. Or connected on both >> cell phone and on >> desk phone in office. Right now the conference package seems a little >> underspecified in how to deal with this and we need to clear this up. >> >> I'm tossing out two proposal below. Comments? Ideas? Can we >> choose one? >> Could be close something like this on this list? >> >> -------------------------------------------------------------- >> >> Proposal 1: >> >> The User Element gets a new attribute called contact. This attribute >> contains the contact that the focus used for this dialog. Each dialog >> results in a separate User Element instance and the uri is >> used to correlate >> the fact that they are the same user. For anonymous calls the >> system needs >> to generate separate anonymous user uri's so they can be >> separated from one >> another. >> >> For Example, >> >> >> >> 1234 >> >> >> 5678 >> >> >> >> --------------------------------------------------------------- >> >> Proposal 2: >> >> The data in the User Element gets split between a User >> Element and a new >> Session Element that is placed inside the User Element. The >> media stream >> elements are put inside the Session. >> >> >> >> >> 1234 >> >> >> 5678 >> >> >> >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the 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 Apr 12 17:35:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16260 for ; Mon, 12 Apr 2004 17:35: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 1BD95F-00069X-Cw for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 17:35:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CLZDu2023651 for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 17:35:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD956-000695-8M for sipping-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 17:35: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 RAA16236 for ; Mon, 12 Apr 2004 17:35:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD953-0004Z1-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 17:35:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD8gk-0002dU-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 17:09:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD8F4-0000rS-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 16:41:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD8Eo-0008I8-C3; Mon, 12 Apr 2004 16:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD8E3-0008Do-NW for sipping@optimus.ietf.org; Mon, 12 Apr 2004 16: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 QAA13355 for ; Mon, 12 Apr 2004 16:40:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD8Dz-0000lT-00 for sipping@ietf.org; Mon, 12 Apr 2004 16:40:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD7uF-0006nT-00 for sipping@ietf.org; Mon, 12 Apr 2004 16:19:48 -0400 Received: from omzesmtp03.mci.com ([199.249.17.11]) by ietf-mx with esmtp (Exim 4.12) id 1BD7dj-0005C0-00 for sipping@ietf.org; Mon, 12 Apr 2004 16:02:44 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HW200HBIQ4LHC@firewall.mci.com> for sipping@ietf.org; Mon, 12 Apr 2004 19:57:57 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HW200201Q4KNX@pmismtp02.mcilink.com>; Mon, 12 Apr 2004 19:57:57 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.143.39]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HW20027HQ4I6Y@pmismtp02.mcilink.com>; Mon, 12 Apr 2004 19:57:56 +0000 (GMT) Date: Mon, 12 Apr 2004 14:57:55 -0500 From: Alan Johnston Subject: Re: [Sipping] Conf stuff in natann draft In-reply-to: X-Sender: Alan.Johnston@pop.mcilink.com To: Cullen Jennings , Eric Burger , "'sipping@ietf.org'" , woof@snowshore.com, jvandyke@snowshore.com Message-id: <5.2.1.1.0.20040412145421.02c025e0@pop.mcilink.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cullen, You are right - there is an inconsistency. However, if we make netann consistent as you propose (and previous versions of netann use exactly this format), then netann becomes inconsistent with the conferencing framework and the rest of the conferencing work. The conferencing framework assumes that the conference ID is embedded in the user portion of the URI, not in URI parameters. Can you explain your NAT issue with this approach? Thanks, Alan Johnston MCI sip:alan@sipstation.com At 08:59 AM 4/12/2004 -0700, Cullen Jennings wrote: >Their is a bit of weird inconsistency in the having the parameters that are >passed to the __sip-conf service invocation embedded in the user portion. > >In the annc and dialog service, there are no parameters in the user portion >of the URI. Yet in the conf service, the conf id is embedded in the user >portion. > >I think this is wrong. It should be > >__sip-conf@mediaserver.example.net;conf=uniqueIdentifier > >This makes it feasible to specify routing rules for proxies that correctly >get all the traffic for the service to the media server. Particularly if the >media server is behind a NAT. > >Could you change the draft to make the conf service invocation consistent >with the annc and dialog? > >Cullen > > > > > > > > > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Apr 12 18:03:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17932 for ; Mon, 12 Apr 2004 18:03:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD9WD-0003DV-Sx for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 18:03:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CM35GE012361 for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 18:03:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD9W1-0003A4-7B for sipping-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 18:03: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 SAA17812 for ; Mon, 12 Apr 2004 18:02:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD9Vw-0006BP-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 18:02:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD8z6-00044y-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 17:28:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD8bH-00029R-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 17:04:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD8b4-0002zI-EB; Mon, 12 Apr 2004 17:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD8aa-0002vU-Gi for sipping@optimus.ietf.org; Mon, 12 Apr 2004 17:03: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 RAA14689 for ; Mon, 12 Apr 2004 17:03:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD8aU-000259-00 for sipping@ietf.org; Mon, 12 Apr 2004 17:03:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD87s-0000K0-00 for sipping@ietf.org; Mon, 12 Apr 2004 16:33:54 -0400 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx with esmtp (Exim 4.12) id 1BD7qL-0006Fw-00 for sipping@ietf.org; Mon, 12 Apr 2004 16:15:46 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HW200006QCGY7@firewall.mci.com> for sipping@ietf.org; Mon, 12 Apr 2004 20:02:40 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HW200301QCF0Y@pmismtp02.mcilink.com>; Mon, 12 Apr 2004 20:02:40 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.143.39]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HW20023BQCCWG@pmismtp02.mcilink.com>; Mon, 12 Apr 2004 20:02:39 +0000 (GMT) Date: Mon, 12 Apr 2004 15:02:38 -0500 From: Alan Johnston Subject: Re: [Sipping] User with multiple sessions in Conference Package In-reply-to: X-Sender: Alan.Johnston@pop.mcilink.com To: Cullen Jennings , hisham.khartabil@nokia.com, sipping@ietf.org Cc: Orit Levin , Henning Schulzrinne , Jonathan Rosenberg Message-id: <5.2.1.1.0.20040412145825.02c036e0@pop.mcilink.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <2038BCC78B1AD641891A0D1AE133DBB7017978CD@esebe019.ntc.nokia.com> Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cullen, I agree with your explanation - this is definitely a goal. However, I don't understand your initial proposals. The conference package should, as you argue, just indicate that Cullen is in the conference, and perhaps note the media types used. Whether these media types are supported by a single device, or multiple devices doesn't matter as far as the conference package is concerned. What exactly is the problem you are trying to solve with your two proposals? I don't think that Contact URIs belong in the conference package - if a participant wants detailed information about the way in which a participant is connected to the conference, the dialog package can be used. Thanks, Alan Johnston MCI sip:alan@sipstation.com At 10:43 AM 4/12/2004 -0700, Cullen Jennings wrote: >I'll take a stab at explaining :-) > >If someone has a roster displayed on some device - they want to see that one >person, Cullen is in the conference they don't want to sees that their are 4 >participants, Cullen-Cell-Phone, Cullen-Speaker-Phone, >Cullen-JABBER_GATEWAY, Cullen-VIDEO-ICHAT_GW. More importantly, they want to >be able to use a user interface to boot Cullen out of the conference not >have to go and somehow magically figure out which devices to boot out since >they are being used by Cullen. > >If their are 10 participants that are all Anonymous, you still want to be >able to know their are 10 participants not 1 participant called Anonymous >that seems to have dialed in from 10 devices. > >Given that SIP AOR correspond to a user and is not a single device. There >are basically three levels off aggregation happening here. > >There are users. Each user can have multiple SIP dialogs that got them into >the conference. Each one of these SIP dialogs can be started and terminated >independently. For example one may be dialed out while another dialed in and >one may be active while others may be ongoing. Inside of each SIP dialog, >there can be multiple media stream (audio, video, etc). The three levels are >Users, SIP Sessions or Dialogs, Media Sessions. Unfortunately, the draft as >written supports two things and the User level information and the SIP >session level information is mixed together. I think this needs to get >fixed. > >One more use case, many audio conference systems announce when a user joins >of leaves. This is really annoying when someone transfers from the cell >phone to desk phone. Let me give you a scenario that I think XCON should >support. > >Cullen dials in to conf from cell phone and is announced. Cullen then dials >in from desk phone and is *not* announced because the user Cullen is already >in the conference. Cullen hangs up cell phone and this is *not* announced >because Cullen is still in the conference. Cullen hangs up his desk phone >and the conference announces that "Fluffy has left the building" because he >is no longer in the conference. > > >On 4/8/04 5:11 AM, "hisham.khartabil@nokia.com" >wrote: > > > Why do you need the focus to know that it is the same user (human)? I don't > > understand the use case. Can you elaborate? > > > > Thanks, > > Hisham > > > >> -----Original Message----- > >> From: sipping-admin@ietf.org > >> [mailto:sipping-admin@ietf.org]On Behalf Of > >> ext Cullen Jennings > >> Sent: 08.April.2004 03:30 > >> To: 'sipping@ietf.org' > >> Cc: Orit Levin; Henning Schulzrinne; Jonathan Rosenberg > >> Subject: [Sipping] User with multiple sessions in Conference Package > >> > >> > >> > >> In a conference, here are many cases where a single user may > >> have set up > >> multiple SIP dialogs with the focus. For example, using one > >> UA instance for > >> audio and another UA instance for IM. Or connected on both > >> cell phone and on > >> desk phone in office. Right now the conference package seems a little > >> underspecified in how to deal with this and we need to clear this up. > >> > >> I'm tossing out two proposal below. Comments? Ideas? Can we > >> choose one? > >> Could be close something like this on this list? > >> > >> -------------------------------------------------------------- > >> > >> Proposal 1: > >> > >> The User Element gets a new attribute called contact. This attribute > >> contains the contact that the focus used for this dialog. Each dialog > >> results in a separate User Element instance and the uri is > >> used to correlate > >> the fact that they are the same user. For anonymous calls the > >> system needs > >> to generate separate anonymous user uri's so they can be > >> separated from one > >> another. > >> > >> For Example, > >> > >> > >> > >> 1234 > >> > >> > >> 5678 > >> > >> > >> > >> --------------------------------------------------------------- > >> > >> Proposal 2: > >> > >> The data in the User Element gets split between a User > >> Element and a new > >> Session Element that is placed inside the User Element. The > >> media stream > >> elements are put inside the Session. > >> > >> > >> > >> > >> 1234 > >> > >> > >> 5678 > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >> This list is for NEW development of the application of SIP > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sip@ietf.org for new developments of core SIP > >> > > > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Apr 12 22:57:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02945 for ; Mon, 12 Apr 2004 22:57: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 1BDE78-0003Oh-B5 for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 22:57:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D2vUL3013055 for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 22:57:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDE75-0003OQ-Sb for sipping-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 22:57: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 WAA02906 for ; Mon, 12 Apr 2004 22:57:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDE72-0005Rm-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 22:57:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDE4j-0005F7-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 22:55:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDDz0-0004hc-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 22:49:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDDyv-0002cg-7M; Mon, 12 Apr 2004 22:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDDxu-0002aq-84 for sipping@optimus.ietf.org; Mon, 12 Apr 2004 22:48: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 WAA02473 for ; Mon, 12 Apr 2004 22:47:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDDxq-0004X7-00 for sipping@ietf.org; Mon, 12 Apr 2004 22:47:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDDuN-00042Z-00 for sipping@ietf.org; Mon, 12 Apr 2004 22:44:21 -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 1BDDsO-0003lt-00 for sipping@ietf.org; Mon, 12 Apr 2004 22:42:16 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2004 18:50:29 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3D2fZGF004715; Mon, 12 Apr 2004 19:41:35 -0700 (PDT) Received: from [128.107.170.99] ([128.107.170.99]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOB24624; Mon, 12 Apr 2004 19:41:34 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 12 Apr 2004 19:41:31 -0700 Subject: Re: [Sipping] User with multiple sessions in Conference Package From: Cullen Jennings To: Alan Johnston , , CC: Orit Levin , Henning Schulzrinne , Jonathan Rosenberg Message-ID: In-Reply-To: <5.2.1.1.0.20040412145825.02c036e0@pop.mcilink.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 > The conference package > should, as you argue, just indicate that Cullen is in the conference, and > perhaps note the media types used. Right now the conference package seems to have a lot more than that in it. It has if I dialed in or out, disconnect reasons, on-hold, etc. that are specific to the session not the user. BTW. I really like the definition of the uri element in the user. I think that was the hard problem and it is right. On 4/12/04 1:02 PM, "Alan Johnston" wrote: > Cullen, > > I agree with your explanation - this is definitely a goal. > > However, I don't understand your initial proposals. The conference package > should, as you argue, just indicate that Cullen is in the conference, and > perhaps note the media types used. Whether these media types are supported > by a single device, or multiple devices doesn't matter as far as the > conference package is concerned. What exactly is the problem you are > trying to solve with your two proposals? I don't think that Contact URIs > belong in the conference package - if a participant wants detailed > information about the way in which a participant is connected to the > conference, the dialog package can be used. > > Thanks, > Alan Johnston > MCI > sip:alan@sipstation.com > > At 10:43 AM 4/12/2004 -0700, Cullen Jennings wrote: > >> I'll take a stab at explaining :-) >> >> If someone has a roster displayed on some device - they want to see that one >> person, Cullen is in the conference they don't want to sees that their are 4 >> participants, Cullen-Cell-Phone, Cullen-Speaker-Phone, >> Cullen-JABBER_GATEWAY, Cullen-VIDEO-ICHAT_GW. More importantly, they want to >> be able to use a user interface to boot Cullen out of the conference not >> have to go and somehow magically figure out which devices to boot out since >> they are being used by Cullen. >> >> If their are 10 participants that are all Anonymous, you still want to be >> able to know their are 10 participants not 1 participant called Anonymous >> that seems to have dialed in from 10 devices. >> >> Given that SIP AOR correspond to a user and is not a single device. There >> are basically three levels off aggregation happening here. >> >> There are users. Each user can have multiple SIP dialogs that got them into >> the conference. Each one of these SIP dialogs can be started and terminated >> independently. For example one may be dialed out while another dialed in and >> one may be active while others may be ongoing. Inside of each SIP dialog, >> there can be multiple media stream (audio, video, etc). The three levels are >> Users, SIP Sessions or Dialogs, Media Sessions. Unfortunately, the draft as >> written supports two things and the User level information and the SIP >> session level information is mixed together. I think this needs to get >> fixed. >> >> One more use case, many audio conference systems announce when a user joins >> of leaves. This is really annoying when someone transfers from the cell >> phone to desk phone. Let me give you a scenario that I think XCON should >> support. >> >> Cullen dials in to conf from cell phone and is announced. Cullen then dials >> in from desk phone and is *not* announced because the user Cullen is already >> in the conference. Cullen hangs up cell phone and this is *not* announced >> because Cullen is still in the conference. Cullen hangs up his desk phone >> and the conference announces that "Fluffy has left the building" because he >> is no longer in the conference. >> >> >> On 4/8/04 5:11 AM, "hisham.khartabil@nokia.com" >> wrote: >> >>> Why do you need the focus to know that it is the same user (human)? I don't >>> understand the use case. Can you elaborate? >>> >>> Thanks, >>> Hisham >>> >>>> -----Original Message----- >>>> From: sipping-admin@ietf.org >>>> [mailto:sipping-admin@ietf.org]On Behalf Of >>>> ext Cullen Jennings >>>> Sent: 08.April.2004 03:30 >>>> To: 'sipping@ietf.org' >>>> Cc: Orit Levin; Henning Schulzrinne; Jonathan Rosenberg >>>> Subject: [Sipping] User with multiple sessions in Conference Package >>>> >>>> >>>> >>>> In a conference, here are many cases where a single user may >>>> have set up >>>> multiple SIP dialogs with the focus. For example, using one >>>> UA instance for >>>> audio and another UA instance for IM. Or connected on both >>>> cell phone and on >>>> desk phone in office. Right now the conference package seems a little >>>> underspecified in how to deal with this and we need to clear this up. >>>> >>>> I'm tossing out two proposal below. Comments? Ideas? Can we >>>> choose one? >>>> Could be close something like this on this list? >>>> >>>> -------------------------------------------------------------- >>>> >>>> Proposal 1: >>>> >>>> The User Element gets a new attribute called contact. This attribute >>>> contains the contact that the focus used for this dialog. Each dialog >>>> results in a separate User Element instance and the uri is >>>> used to correlate >>>> the fact that they are the same user. For anonymous calls the >>>> system needs >>>> to generate separate anonymous user uri's so they can be >>>> separated from one >>>> another. >>>> >>>> For Example, >>>> >>>> >>>> >>>> 1234 >>>> >>>> >>>> 5678 >>>> >>>> >>>> >>>> --------------------------------------------------------------- >>>> >>>> Proposal 2: >>>> >>>> The data in the User Element gets split between a User >>>> Element and a new >>>> Session Element that is placed inside the User Element. The >>>> media stream >>>> elements are put inside the Session. >>>> >>>> >>>> >>>> >>>> 1234 >>>> >>>> >>>> 5678 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>> This list is for NEW development of the application of SIP >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sip@ietf.org for new developments of core SIP >>>> >>> >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Apr 12 23:14:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03522 for ; Mon, 12 Apr 2004 23:14: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 1BDEMs-0004vo-57 for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 23:13:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D3Dk60018956 for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 23:13:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEMp-0004va-V8 for sipping-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 23:13: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 XAA03491 for ; Mon, 12 Apr 2004 23:13:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDEMn-00069j-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 23:13:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDEKD-00064U-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 23:11:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDEIL-0005zi-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 23:09:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEII-0004NC-V9; Mon, 12 Apr 2004 23:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEI4-0004Ml-4K for sipping@optimus.ietf.org; Mon, 12 Apr 2004 23:08: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 XAA03409 for ; Mon, 12 Apr 2004 23:08:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDEHy-0005zC-00 for sipping@ietf.org; Mon, 12 Apr 2004 23:08:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDEFZ-0005uZ-00 for sipping@ietf.org; Mon, 12 Apr 2004 23:06:15 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BDEEK-0005oe-00 for sipping@ietf.org; Mon, 12 Apr 2004 23:04:57 -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 i3D34BGH020179; Mon, 12 Apr 2004 20:04:13 -0700 (PDT) Received: from [128.107.170.99] ([128.107.170.99]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOB25494; Mon, 12 Apr 2004 20:04:10 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 12 Apr 2004 20:04:08 -0700 Subject: Re: [Sipping] Conf stuff in natann draft From: Cullen Jennings To: Alan Johnston , Eric Burger , "'sipping@ietf.org'" , , Message-ID: In-Reply-To: <5.2.1.1.0.20040412145421.02c025e0@pop.mcilink.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 I think I understand the confusion. The name of the focus should have the identify the conference by the user part. However, this is very different than the service invocation that the focus uses to control the media mixer. The term __sip-conf is a bit of a red hearing __sip-mixer would be more appropriate. I think that sip:fluffy-staff@mcisco.com is a perfectly reasonable AOR for a conference. Note my choice of the word AOR and yes this should be routable by a proxy. Now this focus is controlling several media servers. One might be doing video, another audio, and so on. There is certainly an argument to be made that Megaco might be a better protocol for this but the netann draft is about using SIP to perform service invocation on these devices. Let's say that video is done ms1 and audio on ms2 for the same device. The focus needs to be able to send a SIP service invocations to a proxy and get it routed to the appropriate ms. If I was generating a URL to give out externally to join a certain conference. I might give lsik83dk8d@cisco.com to folks that were not the moderator but give 89kkdiek8dke8@cisco.com to folks that did have moderator privileges. Perhaps it is the type of conference that does not start mixing until the moderator arrives. Now these are both valid names to reach the same focus and they will result in service invocation to add them to a mixer. I would expect the conference ID in the service invocation to be some completely other string that perhaps has a conference id of 1234 in it. Presumable folks that were moderators and ones that were not would all be going to 1234 on the audio mixer and perhaps some other id 4567 on a separate video mixer. I want to be able to route to the audio and video mixer via a proxy for firewall traversal and to make TLS work without devices other than the proxy having a TLS certificate. I'll give it all more thought but I don't see how to make it work with a name like sip:conf=1234@ms1.cisco.com being sent to the proxy but I see how to make it work if I send sip:__sip-conf@ms1.cisco.com;conf=1234 even though it is ugly. I'll think about more. In summary, as the the netann draft nicely points out, I don't think I see much of a relation between the external AOR that route to the focus and the internal service invocation names that the focus sends to the mixer. Cullen On 4/12/04 12:57 PM, "Alan Johnston" wrote: > Cullen, > > You are right - there is an inconsistency. However, if we make netann > consistent as you propose (and previous versions of netann use exactly this > format), then netann becomes inconsistent with the conferencing framework > and the rest of the conferencing work. > > The conferencing framework assumes that the conference ID is embedded in > the user portion of the URI, not in URI parameters. > > Can you explain your NAT issue with this approach? > > Thanks, > Alan Johnston > MCI > sip:alan@sipstation.com > > At 08:59 AM 4/12/2004 -0700, Cullen Jennings wrote: > >> Their is a bit of weird inconsistency in the having the parameters that are >> passed to the __sip-conf service invocation embedded in the user portion. >> >> In the annc and dialog service, there are no parameters in the user portion >> of the URI. Yet in the conf service, the conf id is embedded in the user >> portion. >> >> I think this is wrong. It should be >> >> __sip-conf@mediaserver.example.net;conf=uniqueIdentifier >> >> This makes it feasible to specify routing rules for proxies that correctly >> get all the traffic for the service to the media server. Particularly if the >> media server is behind a NAT. >> >> Could you change the draft to make the conf service invocation consistent >> with the annc and dialog? >> >> Cullen >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Apr 12 23:14:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03539 for ; Mon, 12 Apr 2004 23:14: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 1BDEMw-0004w8-Ky for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 23:13:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D3DobW018972 for sipping-archive@odin.ietf.org; Mon, 12 Apr 2004 23:13:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEMw-0004vv-CH for sipping-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 23:13: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 XAA03496 for ; Mon, 12 Apr 2004 23:13:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDEMs-0006A2-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 23:13:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDEKJ-00064g-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 23:11:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDEIL-0005zj-00 for sipping-web-archive@ietf.org; Mon, 12 Apr 2004 23:09:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEIH-0004N2-Ux; Mon, 12 Apr 2004 23:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEHY-0004ME-MO for sipping@optimus.ietf.org; Mon, 12 Apr 2004 23:08: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 XAA03371 for ; Mon, 12 Apr 2004 23:08:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDEHT-0005xm-00 for sipping@ietf.org; Mon, 12 Apr 2004 23:08:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDEFK-0005tz-00 for sipping@ietf.org; Mon, 12 Apr 2004 23:06:00 -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 1BDEE9-0005oB-00 for sipping@ietf.org; Mon, 12 Apr 2004 23:04:45 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2004 19:14:10 +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 i3D3452O010734; Mon, 12 Apr 2004 20:04:05 -0700 (PDT) Received: from [128.107.170.99] ([128.107.170.99]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOB25489; Mon, 12 Apr 2004 20:04:04 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 12 Apr 2004 20:04:01 -0700 From: Cullen Jennings To: Andy Spitzer , Eric Burger , "'sipping@ietf.org'" , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Conf stuff in natann 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 First of all let me say thank you for the very complete response. Few questions inline. Also I put some of my reply to this in the my reply to Alan's email. On 4/12/04 11:32 AM, "Andy Spitzer" wrote: > Cullen, > > It is expected that all sessions into the conference are controlled by an > application server via third party call control. The media servers and > conf id's need not be externally visible. The calls first go to the AS, > then are sent to an MS for IVR (conference selection, record name, collect > PIN, etc), then are sent to (possibly another) MS for the conference. MS > conf id's need not be seen externally, as the AS can re-write the messages > any way it sees fit, acting as a B2BUA Great, this is exactly the type of model I am interested in. > > The application server responsible for controlling the conferences (and > thus creating the conference ids) is the one which decides which > conference lives on which MS. It is up to the AS to REGISTER the > conferences with the proxies if the conf ids are externally visible, as > well as creating the conferences on the MS. Agree the AS is picking the ids. In my case, I don't want to make the id that are valid on the ms externally visible but I do need to route traffic from the AS to the MS through a proxy because the MS is behind a firewall and connecting over TLS. > > You are correct in that the MS doesn't know the conf id's a-prioi. The AS > DOES know the conf id's, however. It knows when they are supposed to > start, end, etc., and as such it sends the appropriate REGSISTER methods My problem is I can't do 3rd Party registration with TLS. The MS connects to the proxy over TLS and needs to bind the TLS connection in the proxy to this particular registration so 3rd party registrations don't work. > to any proxies and any MSCML commands to the > appropriate MS. It also removes the conferences from the proxies and MS's > when the alloted time has expired. > > The approach of externally visible ms1.cisco.com and ms2.cisco.com media > servers does indeed mean you don't have to REGISTER each conference as a > user, as the host name is used for routing instead. That's a fine > solution as well. Even with that approach, something has to figure out > the resources available on any given MS at a particular time, and divide > up the usage across the MS's. That is still in the realm of an AS. Agreed it is still the AS making the decision about which resources to use when. > > So, to walk through an example where the conf id is externally visible, > the MS host name is not, and there is no initial IVR for users: > > 1. AS determines a 1 hour conference is to start at 10:00. It assignes a > conf id to the conference. The conf id it picks is (to stick with your 6 > digit number example) 012345. > > 2. At 9:55 (just an example) the AS figures out which is the best MS to > host this conference on. It creates a control session by sending a > command to the appropriate MS (it picked ms1) to > reserve resources: sip:conf=012345@ms1.cisco.com > > 3. The AS then sends a REGISTER to the proxy for user conf=012345 on > ms1.cisco.com I assume here (based on next point) that you mean conf-012345@cisco.com is bound to the contact ms1.cisco.com. Note the domain of the registrar was cisco.com not ms1.cisco.com. If I was allocating ms1 and ms2 to this conference, I assume I would give them different conference Ids and focus would keep track of how they all mapped together. > > 4. As external calls arrive, they can go via the proxy to the correct > MS. External calls are directed to conf=012345@cisco.com. The proxy > routes it to conf=012345@ms1.cisco.com > Ok, I think it is this step where the 3rd party registration fails to work for me. Rest of the steps make sense. > 5. At 10:05 the AS determines the conference is over. It sends a BYE to > the control session on the MS (the one it created in step 2). This > releases the conference resources and ends up sending BYEs to any > remaining participant legs. > > 6. The AS removes the registration for user conf=012345 from the proxy. > > > For more control over conference participants, usually all calls will go > to the AS first, which will control an IVR session to decide which > conference the caller is to be placed into, record the name, collect other > info, etc. Then it will place that user into the conference. > > So, to walk through this example: > > 1. AS determines a 1 hour conference is to start at 10:00. It assignes a > conf id to the conference. The conf id it picks is (to stick with your 6 > digit number example) 012345. > > 2. At 9:55 (just an example) the AS figures out which is the best MS to > host this conference on. It creates a control session by sending a > command to the appropriate MS (it picked ms1) to > reserve resources: sip:conf=012345@ms1.cisco.com > > 3. External caller INVITES sip:conferences@cicso.com. That hits the AS > which selects an available IVR MS and collects the conference info from > the caller via DTMF. The AS sends an INVITE to the selected IVR MS: > sip:ivr@ms2.cisco.com and uses MSCML in INFO methods to play prompts, > collect digits, and record names. When the IVR session is over it sends a > BYE to the IVR MS. > > 4. The AS verifies the caller via PIN or whatever, and places the caller > into the conference by sending an INVITE to the selected conference MS: > conf=012345@ms1.cisco.com > > 5. After the user joins the conference, the AS uses MSCML in INFO methods > sent to the control leg created in step 2 to play the name of the new > participant to the conference, as in "{recorded name} has joined the > conference". > > 6. As participants leave, they send BYE's to the AS, which sends BYE's to > the conference MS. It uses MSCML in INFO methods sent to the control leg > to inform the other participants "{recorded name} has left the conference". > > 7. At 10:05, the AS decides to destroy the conference so it clears all the > sessions it has with the external users and the MS. > > No external proxies need to know which MS's own which conferences, as that > is the AS's responsibility. > > --Andy Spitzer > woof@snowshore.com Once again, thanks for the completely write up, it really did spell it out clearly. > > > On Mon, 12 Apr 2004 10:29:19 -0700, Cullen Jennings > wrote: > >> >> Thanks for the fast response. I'm lost on how you imagine this working - >> I >> think you will need to walk me through it. Let's say the domain is >> cisco.com and I have two media servers ms1.cisco.com and ms2.cisco.com. >> And >> my conference ID's are 6 digit numbers. >> >> Are you suggesting that ms1.cisco.com and ms2.cisco.com know that >> __sip-conf=1 belongs to ms1 and __sip-conf=2 belongs to ms2 and they both >> send a REGISTER message to the proxy and ms2 registers >> __sip-conf=2@cisco.com with a contact pointing to ms2.cisco.com? I don't >> see >> how they could register all the possible conference Ids in any useful >> way. >> Mostly because the message needs to routed to the ms before the ms will >> create the conference and conference needs to be created before it's id >> can >> be registered and the registration needs to happen before the routing and >> thus we have a circular loop of dependencies in time. >> >> I'm proposing that the proxy route to the correct media server by having >> the >> host portion of the URI be ms1.cisco.com or ms2.cisco.com >> >> >> On 4/12/04 9:28 AM, "Andy Spitzer" wrote: >> >>> Cullen, >>> >>> The reason for having the conf id as part of the user part, was because >>> unlike the other services (annc, ivr, and dialog), conferencing is not >>> stand alone. With annc, ivr, and dialog, each session is unique in >>> independent. With conferencing, however, multiple sessions make up a >>> particular conference. >>> >>> As such, a particular conference must live on a particular media server. >>> All participants into that conference must reach the same media server. >>> By placing the conf id in the user part, it makes the conference look >>> like >>> a user on a particular media server, and as such any proxy can use the >>> correct routing rules for users in order to reach the correct media >>> server >>> assigned to that conference. Just the same way they would route users >>> to >>> a particular endpoint. >>> >>> If the conf id was done as you describe, it would mean proxies would >>> have >>> to look into the parameters to determine which conference was being >>> requested in order to determine which media server to INVITE. We didn't >>> want to force proxies to do that, so it was decided the user part was >>> more >>> proxy friendly. >>> >>> Your approach is certainly feasible, and was indeed originally >>> considered. I believe it may be possible to support both >>> simultainously. >>> >>> --Andy Spitzer >>> woof@snowshore.com >>> >>> On Mon, 12 Apr 2004 08:59:14 -0700, Cullen Jennings >>> wrote: >>> >>>> >>>> Their is a bit of weird inconsistency in the having the parameters that >>>> are >>>> passed to the __sip-conf service invocation embedded in the user >>>> portion. >>>> >>>> In the annc and dialog service, there are no parameters in the user >>>> portion >>>> of the URI. Yet in the conf service, the conf id is embedded in the >>>> user >>>> portion. >>>> >>>> I think this is wrong. It should be >>>> >>>> __sip-conf@mediaserver.example.net;conf=uniqueIdentifier >>>> >>>> This makes it feasible to specify routing rules for proxies that >>>> correctly >>>> get all the traffic for the service to the media server. Particularly >>>> if >>>> the >>>> media server is behind a NAT. >>>> >>>> Could you change the draft to make the conf service invocation >>>> consistent >>>> with the annc and dialog? >>>> >>>> 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 Apr 13 03:14:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25091 for ; Tue, 13 Apr 2004 03:14: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 1BDI6x-0004Ny-1m for sipping-archive@odin.ietf.org; Tue, 13 Apr 2004 03:13:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D7DYtC016850 for sipping-archive@odin.ietf.org; Tue, 13 Apr 2004 03:13:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI6w-0004NZ-N5 for sipping-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 03:13: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 DAA25058 for ; Tue, 13 Apr 2004 03:13:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDI6u-0000aF-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 03:13:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDI37-0000Gw-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 03:09:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDI0f-00004c-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 03:07:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI0b-0002ng-NE; Tue, 13 Apr 2004 03:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI0M-0002mc-Lw for sipping@optimus.ietf.org; Tue, 13 Apr 2004 03:06: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 DAA24643 for ; Tue, 13 Apr 2004 03:06:43 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDI0G-00003V-00 for sipping@ietf.org; Tue, 13 Apr 2004 03:06:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDHyK-0007j3-00 for sipping@ietf.org; Tue, 13 Apr 2004 03:04:42 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BDHvk-0007cB-00 for sipping@ietf.org; Tue, 13 Apr 2004 03:02:00 -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 i3D71JO13929; Tue, 13 Apr 2004 10:01:19 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 10:00:28 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3D70Sje006192; Tue, 13 Apr 2004 10:00:28 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00r5AQG8; Tue, 13 Apr 2004 10:00:27 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 i3D70Is10779; Tue, 13 Apr 2004 10:00:18 +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); Tue, 13 Apr 2004 10:00:16 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 10:00:15 +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, 13 Apr 2004 10:00:15 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978D4@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABCCELaGGR5VRbmbyf4yHwvaEgFJOQ+A To: , Cc: , , , , , , , X-OriginalArrivalTime: 13 Apr 2004 07:00:15.0191 (UTC) FILETIME=[F8EB0E70:01C42124] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: Joint Interim Meeting Mon May 24 - Wed May 26 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 Here is the hotel information: 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=3DBOSSB There are 50 rooms booked for this event at the rate of $99 per night = (from Sunday 23rd until Wednesday 26th). These rooms will be held until = 3th May, so please reserve your room on or before that date. You can reserve online or by telephone using the Group Code: NONOKA Also, please use the links that Rohan provided to confirm your = attendance. This will aid us in determining the catering requirements. = Here is the link again: mailto:rohan@cisco.com?Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim= ]yes Thanks, Hisham > -----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 (Nokia-TP-MSW/Helsinki); Allison > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo 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 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 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 13 03:39:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26193 for ; Tue, 13 Apr 2004 03:39: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 1BDIVs-0008Qm-Hs for sipping-archive@odin.ietf.org; Tue, 13 Apr 2004 03:39:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D7dKCO032404 for sipping-archive@odin.ietf.org; Tue, 13 Apr 2004 03:39:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDIVm-0008QR-6V for sipping-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 03:39: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 DAA26150 for ; Tue, 13 Apr 2004 03:39:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDIVj-0002HC-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 03:39:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDIMG-0001jN-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 03:29:27 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDIIM-0001Ev-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 03:25:22 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDI4c-0000HW-4r for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 03:11:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI4T-0003mu-MW; Tue, 13 Apr 2004 03:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI3p-0003a5-Dt for sipping@optimus.ietf.org; Tue, 13 Apr 2004 03:10: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 DAA24819 for ; Tue, 13 Apr 2004 03:10:18 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDI3k-0000Jo-00 for sipping@ietf.org; Tue, 13 Apr 2004 03:10:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDI14-00007F-00 for sipping@ietf.org; Tue, 13 Apr 2004 03:07:31 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BDHz9-0007m2-00 for sipping@ietf.org; Tue, 13 Apr 2004 03:05:31 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D74Zn15242; Tue, 13 Apr 2004 10:04:35 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 10:03:09 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3D739rY001080; Tue, 13 Apr 2004 10:03:09 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00wfElPN; Tue, 13 Apr 2004 10:03:07 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 i3D72vF15282; Tue, 13 Apr 2004 10:02:57 +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); Tue, 13 Apr 2004 10:02:57 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 10:02:55 +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, 13 Apr 2004 10:02:55 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978D8@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABCCELaGGR5VRbmbyf4yHwvaEgFJOQ+AAAAXmqA= To: , Cc: , , , , , , , X-OriginalArrivalTime: 13 Apr 2004 07:02:55.0974 (UTC) FILETIME=[58C09860:01C42125] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: Joint Interim Meeting Mon May 24 - Wed May 26 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 One small correction: Rooms will be help until 3rd May. Thanks, Hisham > -----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 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 (Nokia-TP-MSW/Helsinki); Allison > > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo 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 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 13 09:22:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10671 for ; Tue, 13 Apr 2004 09:22: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 1BDNrE-0005jI-IL for sipping-archive@odin.ietf.org; Tue, 13 Apr 2004 09:21:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DDLiFW022022 for sipping-archive@odin.ietf.org; Tue, 13 Apr 2004 09:21:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNrE-0005j7-Cd for sipping-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 09:21: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 JAA10644 for ; Tue, 13 Apr 2004 09:21:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNrC-0001Cn-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 09:21:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNoY-000126-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 09:18:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDNnL-0000pe-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 09:17:43 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDNYQ-0008IT-Eq for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 09:02:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNYF-0003TT-Jr; Tue, 13 Apr 2004 09:02:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNXb-00038X-Kp for sipping@optimus.ietf.org; Tue, 13 Apr 2004 09:01: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 JAA09732 for ; Tue, 13 Apr 2004 09:01:25 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNXZ-0007Qt-00 for sipping@ietf.org; Tue, 13 Apr 2004 09:01:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNWk-0007Lu-00 for sipping@ietf.org; Tue, 13 Apr 2004 09:00:35 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BDNVV-0007Gp-00 for sipping@ietf.org; Tue, 13 Apr 2004 08:59:17 -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 i3DCxEH23344 for ; Tue, 13 Apr 2004 15:59:14 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 15:59:01 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3DCx1xJ010820 for ; Tue, 13 Apr 2004 15:59:01 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00oGF9Uj; Tue, 13 Apr 2004 15:58:58 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 i3DCwmF01651 for ; Tue, 13 Apr 2004 15:58:48 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 15:58:29 +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: Tue, 13 Apr 2004 15:58:29 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978DF@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABCCELaGGR5VRbmbyf4yHwvaEgFJOQ+AAAAXmqAADGlLwA== To: X-OriginalArrivalTime: 13 Apr 2004 12:58:29.0857 (UTC) FILETIME=[04BCCD10:01C42157] 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 It was pointed out to me that the Group Code for booking was incorrect. = Here is the correct Group Code: NOKNOKA. Apologies for the inconvenience. 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 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 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 (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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 13 10:04:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12739 for ; Tue, 13 Apr 2004 10:04:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOWN-0003fi-Mq for sipping-archive@odin.ietf.org; Tue, 13 Apr 2004 10:04:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DE4Fgh014110 for sipping-archive@odin.ietf.org; Tue, 13 Apr 2004 10:04:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOWL-0003dy-81 for sipping-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 10:04: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 KAA12664 for ; Tue, 13 Apr 2004 10:04:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDOWD-0004Wu-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 10:04:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDOV3-0004Sn-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 10:02:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDOTK-0004MC-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 10:01:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOTG-0001UZ-VO; Tue, 13 Apr 2004 10: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 1BDOSt-0001CS-TS for sipping@optimus.ietf.org; Tue, 13 Apr 2004 10:00: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 KAA12475 for ; Tue, 13 Apr 2004 10:00:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDOSp-0004HU-00 for sipping@ietf.org; Tue, 13 Apr 2004 10:00:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDORE-0004C6-00 for sipping@ietf.org; Tue, 13 Apr 2004 09:58:57 -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 1BDOQ6-00043y-00 for sipping@ietf.org; Tue, 13 Apr 2004 09:57:46 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Apr 2004 06:07:21 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3DDv3GF023876; Tue, 13 Apr 2004 06:57:08 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHO07164; Tue, 13 Apr 2004 09:57:02 -0400 (EDT) Message-ID: <407BF1AD.2000201@cisco.com> Date: Tue, 13 Apr 2004 09:57:01 -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: Cullen Jennings CC: hisham.khartabil@nokia.com, sipping@ietf.org, Orit Levin , Henning Schulzrinne , Jonathan Rosenberg Subject: Re: [Sipping] User with multiple sessions in Conference Package References: 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, I think what you are trying to achieve is a good thing. But I think the focus may need to be psychic to achieve it. How is it supposed to know which dialogs to group together? I guess it could group all the things that share the same From address, but that won't get all the cases - probably not the interesting ones. Paul Cullen Jennings wrote: > I'll take a stab at explaining :-) > > If someone has a roster displayed on some device - they want to see that one > person, Cullen is in the conference they don't want to sees that their are 4 > participants, Cullen-Cell-Phone, Cullen-Speaker-Phone, > Cullen-JABBER_GATEWAY, Cullen-VIDEO-ICHAT_GW. More importantly, they want to > be able to use a user interface to boot Cullen out of the conference not > have to go and somehow magically figure out which devices to boot out since > they are being used by Cullen. > > If their are 10 participants that are all Anonymous, you still want to be > able to know their are 10 participants not 1 participant called Anonymous > that seems to have dialed in from 10 devices. > > Given that SIP AOR correspond to a user and is not a single device. There > are basically three levels off aggregation happening here. > > There are users. Each user can have multiple SIP dialogs that got them into > the conference. Each one of these SIP dialogs can be started and terminated > independently. For example one may be dialed out while another dialed in and > one may be active while others may be ongoing. Inside of each SIP dialog, > there can be multiple media stream (audio, video, etc). The three levels are > Users, SIP Sessions or Dialogs, Media Sessions. Unfortunately, the draft as > written supports two things and the User level information and the SIP > session level information is mixed together. I think this needs to get > fixed. > > One more use case, many audio conference systems announce when a user joins > of leaves. This is really annoying when someone transfers from the cell > phone to desk phone. Let me give you a scenario that I think XCON should > support. > > Cullen dials in to conf from cell phone and is announced. Cullen then dials > in from desk phone and is *not* announced because the user Cullen is already > in the conference. Cullen hangs up cell phone and this is *not* announced > because Cullen is still in the conference. Cullen hangs up his desk phone > and the conference announces that "Fluffy has left the building" because he > is no longer in the conference. > > > On 4/8/04 5:11 AM, "hisham.khartabil@nokia.com" > wrote: > > >>Why do you need the focus to know that it is the same user (human)? I don't >>understand the use case. Can you elaborate? >> >>Thanks, >>Hisham >> >> >>>-----Original Message----- >>>From: sipping-admin@ietf.org >>>[mailto:sipping-admin@ietf.org]On Behalf Of >>>ext Cullen Jennings >>>Sent: 08.April.2004 03:30 >>>To: 'sipping@ietf.org' >>>Cc: Orit Levin; Henning Schulzrinne; Jonathan Rosenberg >>>Subject: [Sipping] User with multiple sessions in Conference Package >>> >>> >>> >>>In a conference, here are many cases where a single user may >>>have set up >>>multiple SIP dialogs with the focus. For example, using one >>>UA instance for >>>audio and another UA instance for IM. Or connected on both >>>cell phone and on >>>desk phone in office. Right now the conference package seems a little >>>underspecified in how to deal with this and we need to clear this up. >>> >>>I'm tossing out two proposal below. Comments? Ideas? Can we >>>choose one? >>>Could be close something like this on this list? >>> >>>-------------------------------------------------------------- >>> >>>Proposal 1: >>> >>>The User Element gets a new attribute called contact. This attribute >>>contains the contact that the focus used for this dialog. Each dialog >>>results in a separate User Element instance and the uri is >>>used to correlate >>>the fact that they are the same user. For anonymous calls the >>>system needs >>>to generate separate anonymous user uri's so they can be >>>separated from one >>>another. >>> >>>For Example, >>> >>> >>> >>> 1234 >>> >>> >>> 5678 >>> >>> >>> >>>--------------------------------------------------------------- >>> >>>Proposal 2: >>> >>>The data in the User Element gets split between a User >>>Element and a new >>>Session Element that is placed inside the User Element. The >>>media stream >>>elements are put inside the Session. >>> >>> >>> >>> >>> 1234 >>> >>> >>> 5678 >>> >>> >>> >>> >>> >>>_______________________________________________ >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the application of SIP >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sip@ietf.org for new developments of core SIP >>> >> > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Apr 13 11:34: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 LAA17492 for ; Tue, 13 Apr 2004 11:34: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 1BDPv9-0005Xp-Rj for sipping-archive@odin.ietf.org; Tue, 13 Apr 2004 11:33:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DFXtwH021309 for sipping-archive@odin.ietf.org; Tue, 13 Apr 2004 11:33:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDPv9-0005Xc-O3 for sipping-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 11:33: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 LAA17461 for ; Tue, 13 Apr 2004 11:33:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDPv8-00037e-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 11:33:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDPtc-0002z7-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 11:32:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDPsP-0002sV-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 11:31:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDPsL-0005Ej-PL; Tue, 13 Apr 2004 11:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDPrN-0005DP-Ud for sipping@optimus.ietf.org; Tue, 13 Apr 2004 11:30: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 LAA17309 for ; Tue, 13 Apr 2004 11:29:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDPrM-0002mu-00 for sipping@ietf.org; Tue, 13 Apr 2004 11:30:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDPqN-0002gt-00 for sipping@ietf.org; Tue, 13 Apr 2004 11:29:00 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BDPpN-0002bV-00; Tue, 13 Apr 2004 11:27:57 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DFQjN14550; Tue, 13 Apr 2004 08:26:45 -0700 (PDT) Message-Id: <200404131526.i3DFQjN14550@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sipping@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 13 Apr 2004 08:26:45 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Subject: [Sipping] RFC 3680 on A Session Initiation Protocol (SIP) Event Package for Registrations Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-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.8 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3680 Title: A Session Initiation Protocol (SIP) Event Package for Registrations Author(s): J. Rosenberg Status: Standards Track Date: March 2004 Mailbox: jdrosen@dynamicsoft.com Pages: 26 Characters: 35403 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipping-reg-event-00.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3680.txt This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications. This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040413082251.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3680 --OtherAccess Content-Type: Message/External-body; name="rfc3680.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040413082251.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Apr 13 19:41:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20108 for ; Tue, 13 Apr 2004 19:41: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 1BDXUZ-0001et-HM for sipping-archive@odin.ietf.org; Tue, 13 Apr 2004 19:38:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DNcxXO006374 for sipping-archive@odin.ietf.org; Tue, 13 Apr 2004 19:38:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDXQv-0000rZ-3q for sipping-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 19:35: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 TAA19850 for ; Tue, 13 Apr 2004 19:35:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDXQt-0000Qu-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 19:35:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDXPl-0000IL-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 19:34:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDXOA-00004F-00 for sipping-web-archive@ietf.org; Tue, 13 Apr 2004 19:32:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDXJz-0008FT-Ep; Tue, 13 Apr 2004 19:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDXI3-0007hP-Iw for sipping@optimus.ietf.org; Tue, 13 Apr 2004 19:26: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 TAA19246 for ; Tue, 13 Apr 2004 19:26:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDXI1-00079k-00 for sipping@ietf.org; Tue, 13 Apr 2004 19:26:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDXEE-0006mH-00 for sipping@ietf.org; Tue, 13 Apr 2004 19:22:07 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BDXBY-0006P3-00; Tue, 13 Apr 2004 19:19:21 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DNIFN07273; Tue, 13 Apr 2004 16:18:15 -0700 (PDT) Message-Id: <200404132318.i3DNIFN07273@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sipping@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 13 Apr 2004 16:18:15 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Subject: [Sipping] BCP 85, RFC 3725 on Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BIZ_TLD, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. BCP 85 RFC 3725 Title: Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP) Author(s): J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo Status: Best Current Practice Date: April 2004 Mailbox: jdrosen@dynamicsoft.com, jon.peterson@neustar.biz, schulzrinne@cs.columbia.edu Pages: 31 Characters: 77308 SeeAlso: BCP 85 I-D Tag: draft-ietf-sipping-3pcc-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3725.txt Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of SIP for third party call control. This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040413161620.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3725 --OtherAccess Content-Type: Message/External-body; name="rfc3725.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040413161620.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Apr 14 05:49:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12551 for ; Wed, 14 Apr 2004 05:49:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDgvp-0003q4-QL for sipping-archive@odin.ietf.org; Wed, 14 Apr 2004 05:43:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3E9hjdW014756 for sipping-archive@odin.ietf.org; Wed, 14 Apr 2004 05:43:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDgoj-0002SD-5J for sipping-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 05: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 FAA11969 for ; Wed, 14 Apr 2004 05:36:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDgof-0004QY-00 for sipping-web-archive@ietf.org; Wed, 14 Apr 2004 05:36:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDgni-0004KL-00 for sipping-web-archive@ietf.org; Wed, 14 Apr 2004 05:35:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDgnB-0004Ek-00 for sipping-web-archive@ietf.org; Wed, 14 Apr 2004 05:34:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDgcj-000081-IU; Wed, 14 Apr 2004 05:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD4Mh-0008GM-2P for sipping@optimus.ietf.org; Mon, 12 Apr 2004 12:32: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 MAA27729 for ; Mon, 12 Apr 2004 12:32:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD4Mc-0007RV-00 for sipping@ietf.org; Mon, 12 Apr 2004 12:32:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD4L2-0007Fk-00 for sipping@ietf.org; Mon, 12 Apr 2004 12:31:13 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1BD4Ip-0006uv-00 for sipping@ietf.org; Mon, 12 Apr 2004 12:28:55 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 3007; Mon, 12 Apr 2004 12:25:48 -0400 (EDT) Received: from puppy.office.snowshore.com ([192.168.1.75]) by zoe.office.snowshore.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 12 Apr 2004 12:28:15 -0400 To: Cullen Jennings , Eric Burger , "'sipping@ietf.org'" , jvandyke@snowshore.com References: Message-ID: From: Andy Spitzer Organization: SnowShore Networks Content-Type: text/plain; format=flowed; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Mon, 12 Apr 2004 12:28:14 -0400 In-Reply-To: User-Agent: Opera7.21/Linux M2 build 480 X-OriginalArrivalTime: 12 Apr 2004 16:28:15.0199 (UTC) FILETIME=[27C5D6F0:01C420AB] Content-Transfer-Encoding: 8bit Subject: [Sipping] Re: Conf stuff in natann 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Cullen, The reason for having the conf id as part of the user part, was because unlike the other services (annc, ivr, and dialog), conferencing is not stand alone. With annc, ivr, and dialog, each session is unique in independent. With conferencing, however, multiple sessions make up a particular conference. As such, a particular conference must live on a particular media server. All participants into that conference must reach the same media server. By placing the conf id in the user part, it makes the conference look like a user on a particular media server, and as such any proxy can use the correct routing rules for users in order to reach the correct media server assigned to that conference. Just the same way they would route users to a particular endpoint. If the conf id was done as you describe, it would mean proxies would have to look into the parameters to determine which conference was being requested in order to determine which media server to INVITE. We didn't want to force proxies to do that, so it was decided the user part was more proxy friendly. Your approach is certainly feasible, and was indeed originally considered. I believe it may be possible to support both simultainously. --Andy Spitzer woof@snowshore.com On Mon, 12 Apr 2004 08:59:14 -0700, Cullen Jennings wrote: > > Their is a bit of weird inconsistency in the having the parameters that > are > passed to the __sip-conf service invocation embedded in the user portion. > > In the annc and dialog service, there are no parameters in the user > portion > of the URI. Yet in the conf service, the conf id is embedded in the user > portion. > > I think this is wrong. It should be > > __sip-conf@mediaserver.example.net;conf=uniqueIdentifier > > This makes it feasible to specify routing rules for proxies that > correctly > get all the traffic for the service to the media server. Particularly if > the > media server is behind a NAT. > > Could you change the draft to make the conf service invocation consistent > with the annc and dialog? > > 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 Wed Apr 14 05:52:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12724 for ; Wed, 14 Apr 2004 05:52: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 1BDh0i-000527-0n for sipping-archive@odin.ietf.org; Wed, 14 Apr 2004 05:48:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3E9mlo5019342 for sipping-archive@odin.ietf.org; Wed, 14 Apr 2004 05:48:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDgph-0002qy-Br for sipping-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 05:37: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 FAA12027 for ; Wed, 14 Apr 2004 05:37:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDgpd-0004XG-00 for sipping-web-archive@ietf.org; Wed, 14 Apr 2004 05:37:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDgoh-0004Qn-00 for sipping-web-archive@ietf.org; Wed, 14 Apr 2004 05:36:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDgnm-0004Kj-00 for sipping-web-archive@ietf.org; Wed, 14 Apr 2004 05:35:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDgck-00008B-CF; Wed, 14 Apr 2004 05: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 1BD6Kp-0004ia-Pe for sipping@optimus.ietf.org; Mon, 12 Apr 2004 14:39: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 OAA03796 for ; Mon, 12 Apr 2004 14:39:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD6Kl-00010v-00 for sipping@ietf.org; Mon, 12 Apr 2004 14:39:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD6HT-0000e0-00 for sipping@ietf.org; Mon, 12 Apr 2004 14:35:40 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1BD6El-0000D4-00 for sipping@ietf.org; Mon, 12 Apr 2004 14:32:52 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 2990; Mon, 12 Apr 2004 14:29:44 -0400 (EDT) Received: from puppy.office.snowshore.com ([192.168.1.75]) by zoe.office.snowshore.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 12 Apr 2004 14:32:07 -0400 Date: Mon, 12 Apr 2004 14:32:06 -0400 To: Cullen Jennings , Eric Burger , "'sipping@ietf.org'" , jvandyke@snowshore.com References: From: Andy Spitzer Organization: SnowShore Networks Content-Type: text/plain; format=flowed; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera7.21/Linux M2 build 480 X-OriginalArrivalTime: 12 Apr 2004 18:32:07.0828 (UTC) FILETIME=[75F70540:01C420BC] Content-Transfer-Encoding: 8bit Subject: [Sipping] Re: Conf stuff in natann 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Cullen, It is expected that all sessions into the conference are controlled by an application server via third party call control. The media servers and conf id's need not be externally visible. The calls first go to the AS, then are sent to an MS for IVR (conference selection, record name, collect PIN, etc), then are sent to (possibly another) MS for the conference. MS conf id's need not be seen externally, as the AS can re-write the messages any way it sees fit, acting as a B2BUA The application server responsible for controlling the conferences (and thus creating the conference ids) is the one which decides which conference lives on which MS. It is up to the AS to REGISTER the conferences with the proxies if the conf ids are externally visible, as well as creating the conferences on the MS. You are correct in that the MS doesn't know the conf id's a-prioi. The AS DOES know the conf id's, however. It knows when they are supposed to start, end, etc., and as such it sends the appropriate REGSISTER methods to any proxies and any MSCML commands to the appropriate MS. It also removes the conferences from the proxies and MS's when the alloted time has expired. The approach of externally visible ms1.cisco.com and ms2.cisco.com media servers does indeed mean you don't have to REGISTER each conference as a user, as the host name is used for routing instead. That's a fine solution as well. Even with that approach, something has to figure out the resources available on any given MS at a particular time, and divide up the usage across the MS's. That is still in the realm of an AS. So, to walk through an example where the conf id is externally visible, the MS host name is not, and there is no initial IVR for users: 1. AS determines a 1 hour conference is to start at 10:00. It assignes a conf id to the conference. The conf id it picks is (to stick with your 6 digit number example) 012345. 2. At 9:55 (just an example) the AS figures out which is the best MS to host this conference on. It creates a control session by sending a command to the appropriate MS (it picked ms1) to reserve resources: sip:conf=012345@ms1.cisco.com 3. The AS then sends a REGISTER to the proxy for user conf=012345 on ms1.cisco.com 4. As external calls arrive, they can go via the proxy to the correct MS. External calls are directed to conf=012345@cisco.com. The proxy routes it to conf=012345@ms1.cisco.com 5. At 10:05 the AS determines the conference is over. It sends a BYE to the control session on the MS (the one it created in step 2). This releases the conference resources and ends up sending BYEs to any remaining participant legs. 6. The AS removes the registration for user conf=012345 from the proxy. For more control over conference participants, usually all calls will go to the AS first, which will control an IVR session to decide which conference the caller is to be placed into, record the name, collect other info, etc. Then it will place that user into the conference. So, to walk through this example: 1. AS determines a 1 hour conference is to start at 10:00. It assignes a conf id to the conference. The conf id it picks is (to stick with your 6 digit number example) 012345. 2. At 9:55 (just an example) the AS figures out which is the best MS to host this conference on. It creates a control session by sending a command to the appropriate MS (it picked ms1) to reserve resources: sip:conf=012345@ms1.cisco.com 3. External caller INVITES sip:conferences@cicso.com. That hits the AS which selects an available IVR MS and collects the conference info from the caller via DTMF. The AS sends an INVITE to the selected IVR MS: sip:ivr@ms2.cisco.com and uses MSCML in INFO methods to play prompts, collect digits, and record names. When the IVR session is over it sends a BYE to the IVR MS. 4. The AS verifies the caller via PIN or whatever, and places the caller into the conference by sending an INVITE to the selected conference MS: conf=012345@ms1.cisco.com 5. After the user joins the conference, the AS uses MSCML in INFO methods sent to the control leg created in step 2 to play the name of the new participant to the conference, as in "{recorded name} has joined the conference". 6. As participants leave, they send BYE's to the AS, which sends BYE's to the conference MS. It uses MSCML in INFO methods sent to the control leg to inform the other participants "{recorded name} has left the conference". 7. At 10:05, the AS decides to destroy the conference so it clears all the sessions it has with the external users and the MS. No external proxies need to know which MS's own which conferences, as that is the AS's responsibility. --Andy Spitzer woof@snowshore.com On Mon, 12 Apr 2004 10:29:19 -0700, Cullen Jennings wrote: > > Thanks for the fast response. I'm lost on how you imagine this working - > I > think you will need to walk me through it. Let's say the domain is > cisco.com and I have two media servers ms1.cisco.com and ms2.cisco.com. > And > my conference ID's are 6 digit numbers. > > Are you suggesting that ms1.cisco.com and ms2.cisco.com know that > __sip-conf=1 belongs to ms1 and __sip-conf=2 belongs to ms2 and they both > send a REGISTER message to the proxy and ms2 registers > __sip-conf=2@cisco.com with a contact pointing to ms2.cisco.com? I don't > see > how they could register all the possible conference Ids in any useful > way. > Mostly because the message needs to routed to the ms before the ms will > create the conference and conference needs to be created before it's id > can > be registered and the registration needs to happen before the routing and > thus we have a circular loop of dependencies in time. > > I'm proposing that the proxy route to the correct media server by having > the > host portion of the URI be ms1.cisco.com or ms2.cisco.com > > > On 4/12/04 9:28 AM, "Andy Spitzer" wrote: > >> Cullen, >> >> The reason for having the conf id as part of the user part, was because >> unlike the other services (annc, ivr, and dialog), conferencing is not >> stand alone. With annc, ivr, and dialog, each session is unique in >> independent. With conferencing, however, multiple sessions make up a >> particular conference. >> >> As such, a particular conference must live on a particular media server. >> All participants into that conference must reach the same media server. >> By placing the conf id in the user part, it makes the conference look >> like >> a user on a particular media server, and as such any proxy can use the >> correct routing rules for users in order to reach the correct media >> server >> assigned to that conference. Just the same way they would route users >> to >> a particular endpoint. >> >> If the conf id was done as you describe, it would mean proxies would >> have >> to look into the parameters to determine which conference was being >> requested in order to determine which media server to INVITE. We didn't >> want to force proxies to do that, so it was decided the user part was >> more >> proxy friendly. >> >> Your approach is certainly feasible, and was indeed originally >> considered. I believe it may be possible to support both >> simultainously. >> >> --Andy Spitzer >> woof@snowshore.com >> >> On Mon, 12 Apr 2004 08:59:14 -0700, Cullen Jennings >> wrote: >> >>> >>> Their is a bit of weird inconsistency in the having the parameters that >>> are >>> passed to the __sip-conf service invocation embedded in the user >>> portion. >>> >>> In the annc and dialog service, there are no parameters in the user >>> portion >>> of the URI. Yet in the conf service, the conf id is embedded in the >>> user >>> portion. >>> >>> I think this is wrong. It should be >>> >>> __sip-conf@mediaserver.example.net;conf=uniqueIdentifier >>> >>> This makes it feasible to specify routing rules for proxies that >>> correctly >>> get all the traffic for the service to the media server. Particularly >>> if >>> the >>> media server is behind a NAT. >>> >>> Could you change the draft to make the conf service invocation >>> consistent >>> with the annc and dialog? >>> >>> 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 Wed Apr 14 06:17:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13676 for ; Wed, 14 Apr 2004 06:17: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 1BDhK9-00012l-UJ for sipping-archive@odin.ietf.org; Wed, 14 Apr 2004 06:08:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EA8rYh004001 for sipping-archive@odin.ietf.org; Wed, 14 Apr 2004 06:08:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDhH6-0008HN-L0 for sipping-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 06:05: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 GAA13210 for ; Wed, 14 Apr 2004 06:05:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDhH2-0000L6-00 for sipping-web-archive@ietf.org; Wed, 14 Apr 2004 06:05:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDhGK-0000D5-00 for sipping-web-archive@ietf.org; Wed, 14 Apr 2004 06:04:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDhFE-00003n-00 for sipping-web-archive@ietf.org; Wed, 14 Apr 2004 06:03:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDh1u-0005Qp-4x; Wed, 14 Apr 2004 05:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDgwU-00045E-7a for sipping@optimus.ietf.org; Wed, 14 Apr 2004 05:44: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 FAA12210 for ; Wed, 14 Apr 2004 05:44:22 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDgwQ-0005Hc-00 for sipping@ietf.org; Wed, 14 Apr 2004 05:44:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDgvV-0005Bb-00 for sipping@ietf.org; Wed, 14 Apr 2004 05:43:26 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BDgun-00055j-00 for sipping@ietf.org; Wed, 14 Apr 2004 05:42:41 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3E9emk08089; Wed, 14 Apr 2004 12:40:48 +0300 (EET DST) X-Scanned: Wed, 14 Apr 2004 12:40:30 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3E9eUP5000943; Wed, 14 Apr 2004 12:40:30 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00Pq8F1k; Wed, 14 Apr 2004 12:40:29 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 i3E9e7s08281; Wed, 14 Apr 2004 12:40:07 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 14 Apr 2004 12:40: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 Subject: RE: [Sipping] User with multiple sessions in Conference Package Date: Wed, 14 Apr 2004 12:40:01 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978E9@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] User with multiple sessions in Conference Package Thread-Index: AcQhYHQE6xeVrZUnST20ZBN1hmBVZwAo8qfQ To: , Cc: , , , X-OriginalArrivalTime: 14 Apr 2004 09:40:02.0682 (UTC) FILETIME=[75EBD5A0:01C42204] 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 It could based on the asserted identity (unless it is a public = conference and no authentication is needed). By asserted identity I mean = any authentication method available to the conference server/focus. /Hisham > -----Original Message----- > From: sipping-admin@ietf.org=20 > [mailto:sipping-admin@ietf.org]On Behalf Of > ext Paul Kyzivat > Sent: 13.April.2004 16:57 > To: Cullen Jennings > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); sipping@ietf.org; Orit > Levin; Henning Schulzrinne; Jonathan Rosenberg > Subject: Re: [Sipping] User with multiple sessions in=20 > Conference Package >=20 >=20 > Cullen, >=20 > I think what you are trying to achieve is a good thing. But I=20 > think the=20 > focus may need to be psychic to achieve it. How is it=20 > supposed to know=20 > which dialogs to group together? I guess it could group all=20 > the things=20 > that share the same From address, but that won't get all the cases -=20 > probably not the interesting ones. >=20 > Paul >=20 > Cullen Jennings wrote: > > I'll take a stab at explaining :-) > >=20 > > If someone has a roster displayed on some device - they=20 > want to see that one > > person, Cullen is in the conference they don't want to sees=20 > that their are 4 > > participants, Cullen-Cell-Phone, Cullen-Speaker-Phone, > > Cullen-JABBER_GATEWAY, Cullen-VIDEO-ICHAT_GW. More=20 > importantly, they want to > > be able to use a user interface to boot Cullen out of the=20 > conference not > > have to go and somehow magically figure out which devices=20 > to boot out since > > they are being used by Cullen. > >=20 > > If their are 10 participants that are all Anonymous, you=20 > still want to be > > able to know their are 10 participants not 1 participant=20 > called Anonymous > > that seems to have dialed in from 10 devices. > >=20 > > Given that SIP AOR correspond to a user and is not a single=20 > device. There > > are basically three levels off aggregation happening here. > >=20 > > There are users. Each user can have multiple SIP dialogs=20 > that got them into > > the conference. Each one of these SIP dialogs can be=20 > started and terminated > > independently. For example one may be dialed out while=20 > another dialed in and > > one may be active while others may be ongoing. Inside of=20 > each SIP dialog, > > there can be multiple media stream (audio, video, etc). The=20 > three levels are > > Users, SIP Sessions or Dialogs, Media Sessions.=20 > Unfortunately, the draft as > > written supports two things and the User level information=20 > and the SIP > > session level information is mixed together. I think this=20 > needs to get > > fixed.=20 > >=20 > > One more use case, many audio conference systems announce=20 > when a user joins > > of leaves. This is really annoying when someone transfers=20 > from the cell > > phone to desk phone. Let me give you a scenario that I=20 > think XCON should > > support.=20 > >=20 > > Cullen dials in to conf from cell phone and is announced.=20 > Cullen then dials > > in from desk phone and is *not* announced because the user=20 > Cullen is already > > in the conference. Cullen hangs up cell phone and this is=20 > *not* announced > > because Cullen is still in the conference. Cullen hangs up=20 > his desk phone > > and the conference announces that "Fluffy has left the=20 > building" because he > > is no longer in the conference. > >=20 > >=20 > > On 4/8/04 5:11 AM, "hisham.khartabil@nokia.com"=20 > > > wrote: > >=20 > >=20 > >>Why do you need the focus to know that it is the same user=20 > (human)? I don't > >>understand the use case. Can you elaborate? > >> > >>Thanks, > >>Hisham > >> > >> > >>>-----Original Message----- > >>>From: sipping-admin@ietf.org > >>>[mailto:sipping-admin@ietf.org]On Behalf Of > >>>ext Cullen Jennings > >>>Sent: 08.April.2004 03:30 > >>>To: 'sipping@ietf.org' > >>>Cc: Orit Levin; Henning Schulzrinne; Jonathan Rosenberg > >>>Subject: [Sipping] User with multiple sessions in=20 > Conference Package > >>> > >>> > >>> > >>>In a conference, here are many cases where a single user may > >>>have set up > >>>multiple SIP dialogs with the focus. For example, using one > >>>UA instance for > >>>audio and another UA instance for IM. Or connected on both > >>>cell phone and on > >>>desk phone in office. Right now the conference package=20 > seems a little > >>>underspecified in how to deal with this and we need to=20 > clear this up. > >>> > >>>I'm tossing out two proposal below. Comments? Ideas? Can we > >>>choose one? > >>>Could be close something like this on this list? > >>> > >>>-------------------------------------------------------------- > >>> > >>>Proposal 1:=20 > >>> > >>>The User Element gets a new attribute called contact. This=20 > attribute > >>>contains the contact that the focus used for this dialog.=20 > Each dialog > >>>results in a separate User Element instance and the uri is > >>>used to correlate > >>>the fact that they are the same user. For anonymous calls the > >>>system needs > >>>to generate separate anonymous user uri's so they can be > >>>separated from one > >>>another.=20 > >>> > >>>For Example, > >>> > >>> > >>> > >>> 1234 > >>> =20 > >>> > >>> 5678 > >>> > >>> > >>> > >>>--------------------------------------------------------------- > >>> > >>>Proposal 2:=20 > >>> > >>>The data in the User Element gets split between a User > >>>Element and a new > >>>Session Element that is placed inside the User Element. The > >>>media stream > >>>elements are put inside the Session. > >>> > >>> > >>> > >>> > >>> 1234 > >>> > >>> > >>> 5678 > >>> > >>> > >>> > >>> > >>> > >>>_______________________________________________ > >>>Sipping mailing list =20 https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the application of SIP >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sip@ietf.org for new developments of core SIP >>> >> >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 14 10:12:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26715 for ; Wed, 14 Apr 2004 10:12: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 1BDku8-0000hh-PI for sipping-archive@odin.ietf.org; Wed, 14 Apr 2004 09:58:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EDwGM9002700 for sipping-archive@odin.ietf.org; Wed, 14 Apr 2004 09:58:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDknM-0006Dp-AE for sipping-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 09:51: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 JAA24791 for ; Wed, 14 Apr 2004 09:51:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDknK-0007Bw-00 for sipping-web-archive@ietf.org; Wed, 14 Apr 2004 09:51:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDkmS-0006zL-00 for sipping-web-archive@ietf.org; Wed, 14 Apr 2004 09:50:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDklT-0006lo-00 for sipping-web-archive@ietf.org; Wed, 14 Apr 2004 09:49:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkVi-0008Mu-O7; Wed, 14 Apr 2004 09:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkOS-0006HT-ML for sipping@optimus.ietf.org; Wed, 14 Apr 2004 09:25: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 JAA23312 for ; Wed, 14 Apr 2004 09:25:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDkOQ-00032p-00 for sipping@ietf.org; Wed, 14 Apr 2004 09:25:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDkNR-0002ve-00 for sipping@ietf.org; Wed, 14 Apr 2004 09:24:30 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BDkMS-0002i9-00 for sipping@ietf.org; Wed, 14 Apr 2004 09:23:28 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 14 Apr 2004 06:34:16 -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 i3EDMsNP009268; Wed, 14 Apr 2004 09:22:55 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHO88537; Wed, 14 Apr 2004 09:22:53 -0400 (EDT) Message-ID: <407D3B2D.6040304@cisco.com> Date: Wed, 14 Apr 2004 09:22:53 -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: hisham.khartabil@nokia.com CC: fluffy@cisco.com, sipping@ietf.org, oritl@microsoft.com, hgs@cs.columbia.edu, jdrosen@dynamicsoft.com Subject: Re: [Sipping] User with multiple sessions in Conference Package References: <2038BCC78B1AD641891A0D1AE133DBB7017978E9@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > It could based on the asserted identity (unless it is a public conference and no authentication is needed). By asserted identity I mean any authentication method available to the conference server/focus. I wonder how often the endpoints will be authenticated. In most of the conference servers I am familiar with today, authentication is simply based on knowing the conference id. And it probably won't be likely that all the devices a user employs will be bound to the the user in a way known to the conference server. (E.g. I am calling in from the phone tel:+1-978-555-1234, which may just be some phone in a conference room, as well as the IM client sip:pkyzivat@cisco.com. How does the phone get associated with me?) Paul >>-----Original Message----- >>From: sipping-admin@ietf.org >>[mailto:sipping-admin@ietf.org]On Behalf Of >>ext Paul Kyzivat >>Sent: 13.April.2004 16:57 >>To: Cullen Jennings >>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); sipping@ietf.org; Orit >>Levin; Henning Schulzrinne; Jonathan Rosenberg >>Subject: Re: [Sipping] User with multiple sessions in >>Conference Package >> >> >>Cullen, >> >>I think what you are trying to achieve is a good thing. But I >>think the >>focus may need to be psychic to achieve it. How is it >>supposed to know >>which dialogs to group together? I guess it could group all >>the things >>that share the same From address, but that won't get all the cases - >>probably not the interesting ones. >> >> Paul >> >>Cullen Jennings wrote: >> >>>I'll take a stab at explaining :-) >>> >>>If someone has a roster displayed on some device - they >> >>want to see that one >> >>>person, Cullen is in the conference they don't want to sees >> >>that their are 4 >> >>>participants, Cullen-Cell-Phone, Cullen-Speaker-Phone, >>>Cullen-JABBER_GATEWAY, Cullen-VIDEO-ICHAT_GW. More >> >>importantly, they want to >> >>>be able to use a user interface to boot Cullen out of the >> >>conference not >> >>>have to go and somehow magically figure out which devices >> >>to boot out since >> >>>they are being used by Cullen. >>> >>>If their are 10 participants that are all Anonymous, you >> >>still want to be >> >>>able to know their are 10 participants not 1 participant >> >>called Anonymous >> >>>that seems to have dialed in from 10 devices. >>> >>>Given that SIP AOR correspond to a user and is not a single >> >>device. There >> >>>are basically three levels off aggregation happening here. >>> >>>There are users. Each user can have multiple SIP dialogs >> >>that got them into >> >>>the conference. Each one of these SIP dialogs can be >> >>started and terminated >> >>>independently. For example one may be dialed out while >> >>another dialed in and >> >>>one may be active while others may be ongoing. Inside of >> >>each SIP dialog, >> >>>there can be multiple media stream (audio, video, etc). The >> >>three levels are >> >>>Users, SIP Sessions or Dialogs, Media Sessions. >> >>Unfortunately, the draft as >> >>>written supports two things and the User level information >> >>and the SIP >> >>>session level information is mixed together. I think this >> >>needs to get >> >>>fixed. >>> >>>One more use case, many audio conference systems announce >> >>when a user joins >> >>>of leaves. This is really annoying when someone transfers >> >>from the cell >> >>>phone to desk phone. Let me give you a scenario that I >> >>think XCON should >> >>>support. >>> >>>Cullen dials in to conf from cell phone and is announced. >> >>Cullen then dials >> >>>in from desk phone and is *not* announced because the user >> >>Cullen is already >> >>>in the conference. Cullen hangs up cell phone and this is >> >>*not* announced >> >>>because Cullen is still in the conference. Cullen hangs up >> >>his desk phone >> >>>and the conference announces that "Fluffy has left the >> >>building" because he >> >>>is no longer in the conference. >>> >>> >>>On 4/8/04 5:11 AM, "hisham.khartabil@nokia.com" >> >> >> >>>wrote: >>> >>> >>> >>>>Why do you need the focus to know that it is the same user >>> >>(human)? I don't >> >>>>understand the use case. Can you elaborate? >>>> >>>>Thanks, >>>>Hisham >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: sipping-admin@ietf.org >>>>>[mailto:sipping-admin@ietf.org]On Behalf Of >>>>>ext Cullen Jennings >>>>>Sent: 08.April.2004 03:30 >>>>>To: 'sipping@ietf.org' >>>>>Cc: Orit Levin; Henning Schulzrinne; Jonathan Rosenberg >>>>>Subject: [Sipping] User with multiple sessions in >>>> >>Conference Package >> >>>>> >>>>> >>>>>In a conference, here are many cases where a single user may >>>>>have set up >>>>>multiple SIP dialogs with the focus. For example, using one >>>>>UA instance for >>>>>audio and another UA instance for IM. Or connected on both >>>>>cell phone and on >>>>>desk phone in office. Right now the conference package >>>> >>seems a little >> >>>>>underspecified in how to deal with this and we need to >>>> >>clear this up. >> >>>>>I'm tossing out two proposal below. Comments? Ideas? Can we >>>>>choose one? >>>>>Could be close something like this on this list? >>>>> >>>>>-------------------------------------------------------------- >>>>> >>>>>Proposal 1: >>>>> >>>>>The User Element gets a new attribute called contact. This >>>> >>attribute >> >>>>>contains the contact that the focus used for this dialog. >>>> >>Each dialog >> >>>>>results in a separate User Element instance and the uri is >>>>>used to correlate >>>>>the fact that they are the same user. For anonymous calls the >>>>>system needs >>>>>to generate separate anonymous user uri's so they can be >>>>>separated from one >>>>>another. >>>>> >>>>>For Example, >>>>> >>>>> >>>>> >>>>> 1234 >>>>> >>>>> >>>>> 5678 >>>>> >>>>> >>>>> >>>>>--------------------------------------------------------------- >>>>> >>>>>Proposal 2: >>>>> >>>>>The data in the User Element gets split between a User >>>>>Element and a new >>>>>Session Element that is placed inside the User Element. The >>>>>media stream >>>>>elements are put inside the Session. >>>>> >>>>> >>>>> >>>>> >>>>> 1234 >>>>> >>>>> >>>>> 5678 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Sipping mailing list >>>> > https://www1.ietf.org/mailman/listinfo/sipping > >>>>This list is for NEW development of the application of SIP >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sip@ietf.org for new developments of core SIP >>>> >>> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP >> > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Apr 15 05:16:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12743 for ; Thu, 15 Apr 2004 05:16: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 1BE2tE-0007R6-4t for sipping-archive@odin.ietf.org; Thu, 15 Apr 2004 05:10:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F9AWJC028584 for sipping-archive@odin.ietf.org; Thu, 15 Apr 2004 05:10:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2mv-0004RW-9a for sipping-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 05:04: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 FAA12423 for ; Thu, 15 Apr 2004 05:03:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2ms-00049L-00 for sipping-web-archive@ietf.org; Thu, 15 Apr 2004 05:03:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2lz-00045s-00 for sipping-web-archive@ietf.org; Thu, 15 Apr 2004 05:03:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE2lS-00042e-00 for sipping-web-archive@ietf.org; Thu, 15 Apr 2004 05:02:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2cH-0002Fc-DY; Thu, 15 Apr 2004 04: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 1BE2WY-0000Us-PP for sipping@optimus.ietf.org; Thu, 15 Apr 2004 04: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 EAA11798 for ; Thu, 15 Apr 2004 04:47:03 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2WV-0002td-00 for sipping@ietf.org; Thu, 15 Apr 2004 04:47:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2Vc-0002pV-00 for sipping@ietf.org; Thu, 15 Apr 2004 04:46:09 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BE2Uj-0002kF-00 for sipping@ietf.org; Thu, 15 Apr 2004 04:45:13 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3F8iBO12674; Thu, 15 Apr 2004 11:44:11 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 11:44:00 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3F8i0nw011439; Thu, 15 Apr 2004 11:44:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 0097GR6T; Thu, 15 Apr 2004 11:43:58 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 i3F8hds15397; Thu, 15 Apr 2004 11:43:39 +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); Thu, 15 Apr 2004 11:43:19 +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] User with multiple sessions in Conference Package Date: Thu, 15 Apr 2004 11:43:19 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978FE@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] User with multiple sessions in Conference Package Thread-Index: AcQiI/2sCX0LPF8BR/uFIKaWf0walgAoR2KQ To: Cc: , , , , X-OriginalArrivalTime: 15 Apr 2004 08:43:19.0616 (UTC) FILETIME=[B3F2EC00:01C422C5] Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 14.April.2004 16:23 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: fluffy@cisco.com; sipping@ietf.org; oritl@microsoft.com; > hgs@cs.columbia.edu; jdrosen@dynamicsoft.com > Subject: Re: [Sipping] User with multiple sessions in=20 > Conference Package >=20 >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: > > It could based on the asserted identity (unless it is a=20 > public conference and no authentication is needed). By=20 > asserted identity I mean any authentication method available=20 > to the conference server/focus. >=20 > I wonder how often the endpoints will be authenticated. In=20 > most of the=20 > conference servers I am familiar with today, authentication is simply=20 > based on knowing the conference id. In this case, I don't think it is possible to achieve what Cullen wants. = What I had in mind was that either the network hosting the conference = server authenticates the user and asserts him/her to the conference = server or the conference server itself authenticates the USER. >=20 > And it probably won't be likely that all the devices a user=20 > employs will=20 > be bound to the the user in a way known to the conference=20 > server. (E.g.=20 > I am calling in from the phone tel:+1-978-555-1234, which may just be=20 > some phone in a conference room, as well as the IM client=20 > sip:pkyzivat@cisco.com. How does the phone get associated with me?) This does not affect the authentication of the user/caller in the manner = I described above. Hisham >=20 > Paul >=20 > >>-----Original Message----- > >>From: sipping-admin@ietf.org=20 > >>[mailto:sipping-admin@ietf.org]On Behalf Of > >>ext Paul Kyzivat > >>Sent: 13.April.2004 16:57 > >>To: Cullen Jennings > >>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); sipping@ietf.org; Orit > >>Levin; Henning Schulzrinne; Jonathan Rosenberg > >>Subject: Re: [Sipping] User with multiple sessions in=20 > >>Conference Package > >> > >> > >>Cullen, > >> > >>I think what you are trying to achieve is a good thing. But I=20 > >>think the=20 > >>focus may need to be psychic to achieve it. How is it=20 > >>supposed to know=20 > >>which dialogs to group together? I guess it could group all=20 > >>the things=20 > >>that share the same From address, but that won't get all=20 > the cases -=20 > >>probably not the interesting ones. > >> > >> Paul > >> > >>Cullen Jennings wrote: > >> > >>>I'll take a stab at explaining :-) > >>> > >>>If someone has a roster displayed on some device - they=20 > >> > >>want to see that one > >> > >>>person, Cullen is in the conference they don't want to sees=20 > >> > >>that their are 4 > >> > >>>participants, Cullen-Cell-Phone, Cullen-Speaker-Phone, > >>>Cullen-JABBER_GATEWAY, Cullen-VIDEO-ICHAT_GW. More=20 > >> > >>importantly, they want to > >> > >>>be able to use a user interface to boot Cullen out of the=20 > >> > >>conference not > >> > >>>have to go and somehow magically figure out which devices=20 > >> > >>to boot out since > >> > >>>they are being used by Cullen. > >>> > >>>If their are 10 participants that are all Anonymous, you=20 > >> > >>still want to be > >> > >>>able to know their are 10 participants not 1 participant=20 > >> > >>called Anonymous > >> > >>>that seems to have dialed in from 10 devices. > >>> > >>>Given that SIP AOR correspond to a user and is not a single=20 > >> > >>device. There > >> > >>>are basically three levels off aggregation happening here. > >>> > >>>There are users. Each user can have multiple SIP dialogs=20 > >> > >>that got them into > >> > >>>the conference. Each one of these SIP dialogs can be=20 > >> > >>started and terminated > >> > >>>independently. For example one may be dialed out while=20 > >> > >>another dialed in and > >> > >>>one may be active while others may be ongoing. Inside of=20 > >> > >>each SIP dialog, > >> > >>>there can be multiple media stream (audio, video, etc). The=20 > >> > >>three levels are > >> > >>>Users, SIP Sessions or Dialogs, Media Sessions.=20 > >> > >>Unfortunately, the draft as > >> > >>>written supports two things and the User level information=20 > >> > >>and the SIP > >> > >>>session level information is mixed together. I think this=20 > >> > >>needs to get > >> > >>>fixed.=20 > >>> > >>>One more use case, many audio conference systems announce=20 > >> > >>when a user joins > >> > >>>of leaves. This is really annoying when someone transfers=20 > >> > >>from the cell > >> > >>>phone to desk phone. Let me give you a scenario that I=20 > >> > >>think XCON should > >> > >>>support.=20 > >>> > >>>Cullen dials in to conf from cell phone and is announced.=20 > >> > >>Cullen then dials > >> > >>>in from desk phone and is *not* announced because the user=20 > >> > >>Cullen is already > >> > >>>in the conference. Cullen hangs up cell phone and this is=20 > >> > >>*not* announced > >> > >>>because Cullen is still in the conference. Cullen hangs up=20 > >> > >>his desk phone > >> > >>>and the conference announces that "Fluffy has left the=20 > >> > >>building" because he > >> > >>>is no longer in the conference. > >>> > >>> > >>>On 4/8/04 5:11 AM, "hisham.khartabil@nokia.com"=20 > >> > >> > >> > >>>wrote: > >>> > >>> > >>> > >>>>Why do you need the focus to know that it is the same user=20 > >>> > >>(human)? I don't > >> > >>>>understand the use case. Can you elaborate? > >>>> > >>>>Thanks, > >>>>Hisham > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: sipping-admin@ietf.org > >>>>>[mailto:sipping-admin@ietf.org]On Behalf Of > >>>>>ext Cullen Jennings > >>>>>Sent: 08.April.2004 03:30 > >>>>>To: 'sipping@ietf.org' > >>>>>Cc: Orit Levin; Henning Schulzrinne; Jonathan Rosenberg > >>>>>Subject: [Sipping] User with multiple sessions in=20 > >>>> > >>Conference Package > >> > >>>>> > >>>>> > >>>>>In a conference, here are many cases where a single user may > >>>>>have set up > >>>>>multiple SIP dialogs with the focus. For example, using one > >>>>>UA instance for > >>>>>audio and another UA instance for IM. Or connected on both > >>>>>cell phone and on > >>>>>desk phone in office. Right now the conference package=20 > >>>> > >>seems a little > >> > >>>>>underspecified in how to deal with this and we need to=20 > >>>> > >>clear this up. > >> > >>>>>I'm tossing out two proposal below. Comments? Ideas? Can we > >>>>>choose one? > >>>>>Could be close something like this on this list? > >>>>> > >>>>>-------------------------------------------------------------- > >>>>> > >>>>>Proposal 1:=20 > >>>>> > >>>>>The User Element gets a new attribute called contact. This=20 > >>>> > >>attribute > >> > >>>>>contains the contact that the focus used for this dialog.=20 > >>>> > >>Each dialog > >> > >>>>>results in a separate User Element instance and the uri is > >>>>>used to correlate > >>>>>the fact that they are the same user. For anonymous calls the > >>>>>system needs > >>>>>to generate separate anonymous user uri's so they can be > >>>>>separated from one > >>>>>another.=20 > >>>>> > >>>>>For Example, > >>>>> > >>>>> > >>>>> > >>>>> 1234 > >>>>> =20 > >>>>> > >>>>> 5678 > >>>>> > >>>>> > >>>>> > >>>>>--------------------------------------------------------------- > >>>>> > >>>>>Proposal 2:=20 > >>>>> > >>>>>The data in the User Element gets split between a User > >>>>>Element and a new > >>>>>Session Element that is placed inside the User Element. The > >>>>>media stream > >>>>>elements are put inside the Session. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> 1234 > >>>>> > >>>>> > >>>>> 5678 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>Sipping mailing list =20 > >>>> > > 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 > >> > >=20 > >=20 > >=20 > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > >=20 >=20 >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 15 07:14:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17270 for ; Thu, 15 Apr 2004 07:14:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE4nb-0001kR-OL for sipping-archive@odin.ietf.org; Thu, 15 Apr 2004 07:12:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FBCpS7006717 for sipping-archive@odin.ietf.org; Thu, 15 Apr 2004 07:12:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE4mH-0001QU-UN for sipping-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 07:11: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 HAA16961 for ; Thu, 15 Apr 2004 07:11:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE4mD-0005rs-00 for sipping-web-archive@ietf.org; Thu, 15 Apr 2004 07:11:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE4l3-0005fS-00 for sipping-web-archive@ietf.org; Thu, 15 Apr 2004 07:10:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE4k4-0005ZT-00 for sipping-web-archive@ietf.org; Thu, 15 Apr 2004 07:09:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE4bF-0005x5-6p; Thu, 15 Apr 2004 07:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE4ZG-0005PX-LA for sipping@optimus.ietf.org; Thu, 15 Apr 2004 06: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 GAA16550 for ; Thu, 15 Apr 2004 06:57:57 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE4ZC-0004ay-00 for sipping@ietf.org; Thu, 15 Apr 2004 06:57:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE4YJ-0004YK-00 for sipping@ietf.org; Thu, 15 Apr 2004 06:57:04 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BE4XR-0004Uw-00 for sipping@ietf.org; Thu, 15 Apr 2004 06:56:09 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3FAu4O14741; Thu, 15 Apr 2004 13:56:04 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 13:55:51 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3FAtpnX009700; Thu, 15 Apr 2004 13:55:51 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00aocp5Q; Thu, 15 Apr 2004 13:55:49 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 i3FAtYs23098; Thu, 15 Apr 2004 13:55:34 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 13:54:16 +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:draft-camarillo-sipping-uri-list-02.txt Date: Thu, 15 Apr 2004 13:53:38 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797908@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] Re:draft-camarillo-sipping-uri-list-02.txt Thread-Index: AcQegXgOhX1VADGAQaKsbWlzv5Z8bwEVlKOQ To: , X-OriginalArrivalTime: 15 Apr 2004 10:54:16.0958 (UTC) FILETIME=[FF4A29E0:01C422D7] 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 I think this paragraph can be entirely removed. /Hisham > -----Original Message----- > From: sipping-admin@ietf.org=20 > [mailto:sipping-admin@ietf.org]On Behalf Of > ext Paul Kyzivat > Sent: 10.April.2004 01:06 > To: sipping@ietf.org > Subject: [Sipping] Re:draft-camarillo-sipping-uri-list-02.txt >=20 >=20 > Section 4 says: >=20 > As for any other SIP request, the size of requests=20 > carrying URI lists > MUST NOT exceed 1300 bytes, unless the user agent client=20 > has positive > knowledge that the message will not traverse a=20 > congestion-unsafe link > at any hop, or that the message size is at least 200=20 > bytes less than > the lowest MTU value found en route to the server. >=20 > I was curious about the implications of this, so I did some=20 > counting. I=20 > took the example in section 9 and stripped out all the=20 > leading blanks to=20 > get a plausible size estimate. The number I got was 1242,=20 > with four urls=20 > in the list. Each additional URL (of the size in the example) adds 37=20 > bytes. So a list with more than 5 urls exceeds the 1300 byte limit. >=20 > That says to me that this technique is pretty much useless except in=20 > carefully controlled networks, or when compression is used.=20 > Seems pretty=20 > limiting. So it seems likely that in practice content=20 > indirection will=20 > have to be used. >=20 > Paul >=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 Thu Apr 15 12:59: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 MAA04656 for ; Thu, 15 Apr 2004 12:59: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 1BEA4g-0003yI-2J for sipping-archive@odin.ietf.org; Thu, 15 Apr 2004 12:50:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FGoo6B015252 for sipping-archive@odin.ietf.org; Thu, 15 Apr 2004 12:50:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9zQ-0001xi-Qq for sipping-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 12:45: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 MAA03906 for ; Thu, 15 Apr 2004 12:45:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9zP-0005jq-00 for sipping-web-archive@ietf.org; Thu, 15 Apr 2004 12:45:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9ym-0005ed-00 for sipping-web-archive@ietf.org; Thu, 15 Apr 2004 12:44:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE9y3-0005Wz-00 for sipping-web-archive@ietf.org; Thu, 15 Apr 2004 12:43:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9jg-0005hm-N5; Thu, 15 Apr 2004 12:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9gq-0002ya-Tq for sipping@optimus.ietf.org; Thu, 15 Apr 2004 12:26: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 MAA02740 for ; Thu, 15 Apr 2004 12:26:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9gp-0003Sq-00 for sipping@ietf.org; Thu, 15 Apr 2004 12:26:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9fv-0003Pg-00 for sipping@ietf.org; Thu, 15 Apr 2004 12:25:16 -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 1BE9f4-0003I8-00 for sipping@ietf.org; Thu, 15 Apr 2004 12:24:22 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2004 08:33:10 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3FGNenH009578; Thu, 15 Apr 2004 09:23:40 -0700 (PDT) Received: from [128.107.170.152] ([128.107.170.152]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOD38553; Thu, 15 Apr 2004 09:23:39 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 15 Apr 2004 09:23:39 -0700 Subject: Re: [Sipping] User with multiple sessions in Conference Package From: Cullen Jennings To: , Paul H Kyzivat CC: Message-ID: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017978FE@esebe019.ntc.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 I'm very happy with the only correlation to know that two SIP dialogs are the same user is the definition of the "user" uri in the conference package today. If I authenticated as some particular user to the conference system this will work, if not it is not useful. There are several ways this might of happened: 1) my strong sip identity information (ala IAB, S/MIME, etc) 2) my weak sip identity information (whatever I put in my From header) 3) I entered a PIN code to an IVR system 4) the uri of the conference was specific for me and identifies me If people are not willing to provide any information correlate or uncorrelated two different devices then sure this won't work. It's true that many service provider hosted conference systems do not separately identify each participant. However it is the opposite for enterprise based conferencing systems. I have an account on the conference system I use at work. When I dial in from my office phone it recognizes it is me and log me in. When I dial in from some other phone, I enter a user id and pin. It saves all my preferences, what language I want, what time zone I am in, and does not make me record my name for ever conference. If I plan to use a particular conference room, I could add that conference room as a participant to the meeting and it's phone gets placed in the right conference when it dials in. Cullen On 4/15/04 1:43 AM, "hisham.khartabil@nokia.com" wrote: > > >> -----Original Message----- >> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 14.April.2004 16:23 >> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >> Cc: fluffy@cisco.com; sipping@ietf.org; oritl@microsoft.com; >> hgs@cs.columbia.edu; jdrosen@dynamicsoft.com >> Subject: Re: [Sipping] User with multiple sessions in >> Conference Package >> >> >> >> >> hisham.khartabil@nokia.com wrote: >>> It could based on the asserted identity (unless it is a >> public conference and no authentication is needed). By >> asserted identity I mean any authentication method available >> to the conference server/focus. >> >> I wonder how often the endpoints will be authenticated. In >> most of the >> conference servers I am familiar with today, authentication is simply >> based on knowing the conference id. > > In this case, I don't think it is possible to achieve what Cullen wants. What > I had in mind was that either the network hosting the conference server > authenticates the user and asserts him/her to the conference server or the > conference server itself authenticates the USER. > >> >> And it probably won't be likely that all the devices a user >> employs will >> be bound to the the user in a way known to the conference >> server. (E.g. >> I am calling in from the phone tel:+1-978-555-1234, which may just be >> some phone in a conference room, as well as the IM client >> sip:pkyzivat@cisco.com. How does the phone get associated with me?) > > This does not affect the authentication of the user/caller in the manner I > described above. > > Hisham > >> >> Paul >> >>>> -----Original Message----- >>>> From: sipping-admin@ietf.org >>>> [mailto:sipping-admin@ietf.org]On Behalf Of >>>> ext Paul Kyzivat >>>> Sent: 13.April.2004 16:57 >>>> To: Cullen Jennings >>>> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); sipping@ietf.org; Orit >>>> Levin; Henning Schulzrinne; Jonathan Rosenberg >>>> Subject: Re: [Sipping] User with multiple sessions in >>>> Conference Package >>>> >>>> >>>> Cullen, >>>> >>>> I think what you are trying to achieve is a good thing. But I >>>> think the >>>> focus may need to be psychic to achieve it. How is it >>>> supposed to know >>>> which dialogs to group together? I guess it could group all >>>> the things >>>> that share the same From address, but that won't get all >> the cases - >>>> probably not the interesting ones. >>>> >>>> Paul >>>> >>>> Cullen Jennings wrote: >>>> >>>>> I'll take a stab at explaining :-) >>>>> >>>>> If someone has a roster displayed on some device - they >>>> >>>> want to see that one >>>> >>>>> person, Cullen is in the conference they don't want to sees >>>> >>>> that their are 4 >>>> >>>>> participants, Cullen-Cell-Phone, Cullen-Speaker-Phone, >>>>> Cullen-JABBER_GATEWAY, Cullen-VIDEO-ICHAT_GW. More >>>> >>>> importantly, they want to >>>> >>>>> be able to use a user interface to boot Cullen out of the >>>> >>>> conference not >>>> >>>>> have to go and somehow magically figure out which devices >>>> >>>> to boot out since >>>> >>>>> they are being used by Cullen. >>>>> >>>>> If their are 10 participants that are all Anonymous, you >>>> >>>> still want to be >>>> >>>>> able to know their are 10 participants not 1 participant >>>> >>>> called Anonymous >>>> >>>>> that seems to have dialed in from 10 devices. >>>>> >>>>> Given that SIP AOR correspond to a user and is not a single >>>> >>>> device. There >>>> >>>>> are basically three levels off aggregation happening here. >>>>> >>>>> There are users. Each user can have multiple SIP dialogs >>>> >>>> that got them into >>>> >>>>> the conference. Each one of these SIP dialogs can be >>>> >>>> started and terminated >>>> >>>>> independently. For example one may be dialed out while >>>> >>>> another dialed in and >>>> >>>>> one may be active while others may be ongoing. Inside of >>>> >>>> each SIP dialog, >>>> >>>>> there can be multiple media stream (audio, video, etc). The >>>> >>>> three levels are >>>> >>>>> Users, SIP Sessions or Dialogs, Media Sessions. >>>> >>>> Unfortunately, the draft as >>>> >>>>> written supports two things and the User level information >>>> >>>> and the SIP >>>> >>>>> session level information is mixed together. I think this >>>> >>>> needs to get >>>> >>>>> fixed. >>>>> >>>>> One more use case, many audio conference systems announce >>>> >>>> when a user joins >>>> >>>>> of leaves. This is really annoying when someone transfers >>>> >>>> from the cell >>>> >>>>> phone to desk phone. Let me give you a scenario that I >>>> >>>> think XCON should >>>> >>>>> support. >>>>> >>>>> Cullen dials in to conf from cell phone and is announced. >>>> >>>> Cullen then dials >>>> >>>>> in from desk phone and is *not* announced because the user >>>> >>>> Cullen is already >>>> >>>>> in the conference. Cullen hangs up cell phone and this is >>>> >>>> *not* announced >>>> >>>>> because Cullen is still in the conference. Cullen hangs up >>>> >>>> his desk phone >>>> >>>>> and the conference announces that "Fluffy has left the >>>> >>>> building" because he >>>> >>>>> is no longer in the conference. >>>>> >>>>> >>>>> On 4/8/04 5:11 AM, "hisham.khartabil@nokia.com" >>>> >>>> >>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> Why do you need the focus to know that it is the same user >>>>> >>>> (human)? I don't >>>> >>>>>> understand the use case. Can you elaborate? >>>>>> >>>>>> Thanks, >>>>>> Hisham >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: sipping-admin@ietf.org >>>>>>> [mailto:sipping-admin@ietf.org]On Behalf Of >>>>>>> ext Cullen Jennings >>>>>>> Sent: 08.April.2004 03:30 >>>>>>> To: 'sipping@ietf.org' >>>>>>> Cc: Orit Levin; Henning Schulzrinne; Jonathan Rosenberg >>>>>>> Subject: [Sipping] User with multiple sessions in >>>>>> >>>> Conference Package >>>> >>>>>>> >>>>>>> >>>>>>> In a conference, here are many cases where a single user may >>>>>>> have set up >>>>>>> multiple SIP dialogs with the focus. For example, using one >>>>>>> UA instance for >>>>>>> audio and another UA instance for IM. Or connected on both >>>>>>> cell phone and on >>>>>>> desk phone in office. Right now the conference package >>>>>> >>>> seems a little >>>> >>>>>>> underspecified in how to deal with this and we need to >>>>>> >>>> clear this up. >>>> >>>>>>> I'm tossing out two proposal below. Comments? Ideas? Can we >>>>>>> choose one? >>>>>>> Could be close something like this on this list? >>>>>>> >>>>>>> -------------------------------------------------------------- >>>>>>> >>>>>>> Proposal 1: >>>>>>> >>>>>>> The User Element gets a new attribute called contact. This >>>>>> >>>> attribute >>>> >>>>>>> contains the contact that the focus used for this dialog. >>>>>> >>>> Each dialog >>>> >>>>>>> results in a separate User Element instance and the uri is >>>>>>> used to correlate >>>>>>> the fact that they are the same user. For anonymous calls the >>>>>>> system needs >>>>>>> to generate separate anonymous user uri's so they can be >>>>>>> separated from one >>>>>>> another. >>>>>>> >>>>>>> For Example, >>>>>>> >>>>>>> >>>>>>> >>>>>>> 1234 >>>>>>> >>>>>>> >>>>>>> 5678 >>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------- >>>>>>> >>>>>>> Proposal 2: >>>>>>> >>>>>>> The data in the User Element gets split between a User >>>>>>> Element and a new >>>>>>> Session Element that is placed inside the User Element. The >>>>>>> media stream >>>>>>> elements are put inside the Session. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 1234 >>>>>>> >>>>>>> >>>>>>> 5678 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Sipping mailing list >>>>>> >>> https://www1.ietf.org/mailman/listinfo/sipping >>> >>>>>> This list is for NEW development of the application of SIP >>>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>> Use sip@ietf.org for new developments of core SIP >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>> This list is for NEW development of the application of SIP >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sip@ietf.org for new developments of core SIP >>>> >>> >>> >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >>> >> >> > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Apr 15 19:14: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 TAA08808 for ; Thu, 15 Apr 2004 19:14: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 1BEFwf-0007f9-O4 for sipping-archive@odin.ietf.org; Thu, 15 Apr 2004 19:06:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FN6vTT029455 for sipping-archive@odin.ietf.org; Thu, 15 Apr 2004 19:06:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFpZ-0005xY-F0 for sipping-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 18:59: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 SAA07660 for ; Thu, 15 Apr 2004 18:59: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 1BEFpW-0004Gs-Ci for sipping-web-archive@ietf.org; Thu, 15 Apr 2004 18:59:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEFoZ-0004Dq-00 for sipping-web-archive@ietf.org; Thu, 15 Apr 2004 18:58:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEFnc-0004AS-00 for sipping-web-archive@ietf.org; Thu, 15 Apr 2004 18:57:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFUn-0000rv-4V; Thu, 15 Apr 2004 18:38:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFOh-0006zY-Ja for sipping@optimus.ietf.org; Thu, 15 Apr 2004 18:31: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 SAA05386 for ; Thu, 15 Apr 2004 18:31: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 1BEFOe-0002LC-BV for sipping@ietf.org; Thu, 15 Apr 2004 18:31:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEFMf-00021z-00 for sipping@ietf.org; Thu, 15 Apr 2004 18:29:46 -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 1BEFH8-00016p-00 for sipping@ietf.org; Thu, 15 Apr 2004 18:24:02 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2004 14:32:56 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3FMNPnH012932; Thu, 15 Apr 2004 15:23:29 -0700 (PDT) Received: from [128.107.170.152] ([128.107.170.152]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOD80206; Thu, 15 Apr 2004 15:23:24 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 15 Apr 2004 15:23:23 -0700 From: Cullen Jennings To: Andy Spitzer , Eric Burger , "'sipping@ietf.org'" , , Alan Johnston Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Service name stuff in natann 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 I'm going to try and take a second take at this this stuff. Things I think we agree on ... I assume we agree there will be multiple MS and multiple AS and we will use a proxy to broker connections so that we only require the proxy to act as a TLS server instead of every device being a TLS server. There are conference names that link to a particular focus. They route to the AS. We are not talking about conference names. This has nothing to do with conference names. The AS is trying to invoke a service (such as a mixer) on the DSP farm. We are talking about the name of that service. There may be many mixers involved with a single conference. I need a name that is routable to a particular mixer via the proxy. The AS will pick which mixer it wants to use. Where we disagree .... That you can use 3rd party registration to tell a proxy to send invites down some particular TLS connection. I don't think you can. That my proxy needs to keep a binding for every instance of every service. I'm fine with one biding per media service but not per instance of the service. I think it is lots of state that is just not needed in a proxy. That a mixer service is somehow different than other services. I don't see how it is. An IVR system also has to run on a particular box. It may the only box that has the voice prompts needed. My proposal .... Lots of people will build systems differently. We should try and support that. I want to be able to have a GRUU for the contact of a particular service so I can reach it via a proxy over TLS. Others may want to hand configure routes in the proxy. I don't care. However, the parameters for service invocations should not be in the user part because that takes away the ability to configure the name. An example of this is not being able to use a GRU. There are other examples. What I think people should do .... Is there some reason that this mixer service is somehow different and needs to have it parameters in the user part. I just see why - help explain this. Also help explain how we are going to make this 3rd party registration work. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 15 19:31:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09957 for ; Thu, 15 Apr 2004 19:31:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEGIX-0005VO-4C for sipping-archive@odin.ietf.org; Thu, 15 Apr 2004 19:29:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FNTXhB021155 for sipping-archive@odin.ietf.org; Thu, 15 Apr 2004 19:29:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEG91-0003BU-2s for sipping-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 19:19: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 TAA09068 for ; Thu, 15 Apr 2004 19:19: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 1BEG8z-0005jb-IN for sipping-web-archive@ietf.org; Thu, 15 Apr 2004 19:19:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEG82-0005fM-00 for sipping-web-archive@ietf.org; Thu, 15 Apr 2004 19:18:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEG78-0005bL-00 for sipping-web-archive@ietf.org; Thu, 15 Apr 2004 19:17:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEG0e-0000ko-7l; Thu, 15 Apr 2004 19: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 1BEFud-000795-R0 for sipping@optimus.ietf.org; Thu, 15 Apr 2004 19:04: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 TAA07991 for ; Thu, 15 Apr 2004 19:04: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 1BEFua-0004d9-Ij for sipping@ietf.org; Thu, 15 Apr 2004 19:04:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEFtl-0004al-00 for sipping@ietf.org; Thu, 15 Apr 2004 19:03:58 -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 1BEFtA-0004Wr-00 for sipping@ietf.org; Thu, 15 Apr 2004 19:03:20 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2004 15:13:27 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3FN2k0c025090; Thu, 15 Apr 2004 16:02:48 -0700 (PDT) Received: from [128.107.170.152] ([128.107.170.152]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOD84251; Thu, 15 Apr 2004 16:02:46 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 15 Apr 2004 16:02:45 -0700 From: Cullen Jennings To: Andy Spitzer , Eric Burger , "'sipping@ietf.org'" , , Alan Johnston Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Service name stuff in natann 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 On 4/15/04 3:38 PM, "Andy Spitzer" wrote: > Ahh, but for IVR, each and every CALL to the service is independant of > every other call. If call A went to MS 1, and call B went to MS 2, both > would work just fine, they do not need to know about each other; they are > independentof each other. I don't think so. The AS needs to be able to say if it wants MS1 or MS2 even in the IVR case. Perhaps it knows that one of them is busy. Perhaps one of them does ASR and the other does not. I agree there are case were you media servers are interchangeable but there are also cases where they are not and the AS needs to be able to make the choice about that. I agree with you that you for the mixer, you need to the the right one. I just think that is true of all services. I will make an incredible fluffy analogy here ... You are claiming that services invocations are like AOR URI's. I don't think they are. I think they are more like contact URIs. Yes the name of the meeting that gets routed to the focus may be more like an AOR but we are talking about the mixer name. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 16 03:15: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 DAA18277 for ; Fri, 16 Apr 2004 03:15: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 1BENPv-00050a-LA for sipping-archive@odin.ietf.org; Fri, 16 Apr 2004 03:05:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G75dLP019252 for sipping-archive@odin.ietf.org; Fri, 16 Apr 2004 03:05:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENPF-0004py-Cl for sipping-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 03:04: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 DAA17166 for ; Fri, 16 Apr 2004 03:04: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 1BENPB-00013d-JF for sipping-web-archive@ietf.org; Fri, 16 Apr 2004 03:04:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BENOC-0000zF-00 for sipping-web-archive@ietf.org; Fri, 16 Apr 2004 03:03:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BENNI-0000vA-00 for sipping-web-archive@ietf.org; Fri, 16 Apr 2004 03:02:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENFh-0002ze-Vu; Fri, 16 Apr 2004 02:55:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENEX-0002mO-TU for sipping@optimus.ietf.org; Fri, 16 Apr 2004 02:53: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 CAA16668 for ; Fri, 16 Apr 2004 02:53: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 1BENEU-000085-29 for sipping@ietf.org; Fri, 16 Apr 2004 02:53:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BENDW-00003r-00 for sipping@ietf.org; Fri, 16 Apr 2004 02:52:51 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BENCd-0007iv-00 for sipping@ietf.org; Fri, 16 Apr 2004 02:51:55 -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 i3G6pDLc005432; Fri, 16 Apr 2004 01:51:13 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.227]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 23S9LRBB; Fri, 16 Apr 2004 01:51:06 -0500 Message-ID: <407F8265.6070605@ericsson.com> Date: Fri, 16 Apr 2004 09:51:17 +0300 X-Sybari-Trust: 6c669603 2c4885b5 1455e070 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, sipping@ietf.org Subject: Re: [Sipping] Re:draft-camarillo-sipping-uri-list-02.txt References: <2038BCC78B1AD641891A0D1AE133DBB701797908@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797908@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, yes, I had already got this comment before, and I had logged a bug against it. The next revision of the draft will not have this paragraph. Thanks, Gonzalo hisham.khartabil@nokia.com wrote: > I think this paragraph can be entirely removed. > > /Hisham > > >>-----Original Message----- >>From: sipping-admin@ietf.org >>[mailto:sipping-admin@ietf.org]On Behalf Of >>ext Paul Kyzivat >>Sent: 10.April.2004 01:06 >>To: sipping@ietf.org >>Subject: [Sipping] Re:draft-camarillo-sipping-uri-list-02.txt >> >> >>Section 4 says: >> >> As for any other SIP request, the size of requests >>carrying URI lists >> MUST NOT exceed 1300 bytes, unless the user agent client >>has positive >> knowledge that the message will not traverse a >>congestion-unsafe link >> at any hop, or that the message size is at least 200 >>bytes less than >> the lowest MTU value found en route to the server. >> >>I was curious about the implications of this, so I did some >>counting. I >>took the example in section 9 and stripped out all the >>leading blanks to >>get a plausible size estimate. The number I got was 1242, >>with four urls >>in the list. Each additional URL (of the size in the example) adds 37 >>bytes. So a list with more than 5 urls exceeds the 1300 byte limit. >> >>That says to me that this technique is pretty much useless except in >>carefully controlled networks, or when compression is used. >>Seems pretty >>limiting. So it seems likely that in practice content >>indirection will >>have to be used. >> >> Paul >> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP >> > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- 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 Fri Apr 16 10:42:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13124 for ; Fri, 16 Apr 2004 10:42: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 1BEUTp-0001Og-CA for sipping-archive@odin.ietf.org; Fri, 16 Apr 2004 10:38:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GEc9Cx005363 for sipping-archive@odin.ietf.org; Fri, 16 Apr 2004 10:38:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUKA-0007hm-TF for sipping-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 10:28: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 KAA12249 for ; Fri, 16 Apr 2004 10:28: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 1BEUK8-0001Fy-Mx for sipping-web-archive@ietf.org; Fri, 16 Apr 2004 10:28:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEUJE-0001Be-00 for sipping-web-archive@ietf.org; Fri, 16 Apr 2004 10:27:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEUIX-00019g-00 for sipping-web-archive@ietf.org; Fri, 16 Apr 2004 10:26:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEU9M-00042M-SC; Fri, 16 Apr 2004 10:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEU6a-0002hX-64 for sipping@optimus.ietf.org; Fri, 16 Apr 2004 10:14:08 -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 KAA11223 for ; Fri, 16 Apr 2004 10:14:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEU6Y-0000YS-1K for sipping@ietf.org; Fri, 16 Apr 2004 10:14:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEU5b-0000W6-00 for sipping@ietf.org; Fri, 16 Apr 2004 10:13:08 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BEU4f-0000SS-00 for sipping@ietf.org; Fri, 16 Apr 2004 10:12:09 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 16 Apr 2004 07:23:18 -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 i3GEBawb023774; Fri, 16 Apr 2004 10:11:37 -0400 (EDT) Received: from cisco.com (che-vpn-cluster-1-138.cisco.com [10.86.240.138]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHQ60738; Fri, 16 Apr 2004 10:11:35 -0400 (EDT) Message-ID: <407FE996.6000206@cisco.com> Date: Fri, 16 Apr 2004 10:11:34 -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: hisham.khartabil@nokia.com, sipping@ietf.org Subject: Re: [Sipping] Re:draft-camarillo-sipping-uri-list-02.txt References: <2038BCC78B1AD641891A0D1AE133DBB701797908@esebe019.ntc.nokia.com> <407F8265.6070605@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 Why can this be removed? Isn't it still a real issue? Or is this assumed to be fixed by the 3261 requirement that large messages be delivered over TCP? Paul Gonzalo Camarillo wrote: > Hi, > > yes, I had already got this comment before, and I had logged a bug > against it. The next revision of the draft will not have this paragraph. > > Thanks, > > Gonzalo > > hisham.khartabil@nokia.com wrote: > >> I think this paragraph can be entirely removed. >> >> /Hisham >> >> >>> -----Original Message----- >>> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of >>> ext Paul Kyzivat >>> Sent: 10.April.2004 01:06 >>> To: sipping@ietf.org >>> Subject: [Sipping] Re:draft-camarillo-sipping-uri-list-02.txt >>> >>> >>> Section 4 says: >>> >>> As for any other SIP request, the size of requests carrying URI lists >>> MUST NOT exceed 1300 bytes, unless the user agent client has positive >>> knowledge that the message will not traverse a congestion-unsafe link >>> at any hop, or that the message size is at least 200 bytes less than >>> the lowest MTU value found en route to the server. >>> >>> I was curious about the implications of this, so I did some counting. >>> I took the example in section 9 and stripped out all the leading >>> blanks to get a plausible size estimate. The number I got was 1242, >>> with four urls in the list. Each additional URL (of the size in the >>> example) adds 37 bytes. So a list with more than 5 urls exceeds the >>> 1300 byte limit. >>> >>> That says to me that this technique is pretty much useless except in >>> carefully controlled networks, or when compression is used. Seems >>> pretty limiting. So it seems likely that in practice content >>> indirection will have to be used. >>> >>> Paul >>> >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >>> >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 16 11:11:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14933 for ; Fri, 16 Apr 2004 11:11:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUwe-0003Aw-IY for sipping-archive@odin.ietf.org; Fri, 16 Apr 2004 11:08:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GF7uDX012202 for sipping-archive@odin.ietf.org; Fri, 16 Apr 2004 11:07:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUmD-0006i1-II for sipping-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 10:57: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 KAA14162 for ; Fri, 16 Apr 2004 10:57: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 1BEUmA-00030g-Nk for sipping-web-archive@ietf.org; Fri, 16 Apr 2004 10:57:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEUlD-0002wo-00 for sipping-web-archive@ietf.org; Fri, 16 Apr 2004 10:56:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEUkF-0002t2-00 for sipping-web-archive@ietf.org; Fri, 16 Apr 2004 10:55:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUaX-00036Y-3u; Fri, 16 Apr 2004 10:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUWm-0001wW-Oh for sipping@optimus.ietf.org; Fri, 16 Apr 2004 10:41: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 KAA13010 for ; Fri, 16 Apr 2004 10:41: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 1BEUWk-0001xP-Er for sipping@ietf.org; Fri, 16 Apr 2004 10:41:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEUVz-0001sd-00 for sipping@ietf.org; Fri, 16 Apr 2004 10:40:23 -0400 Received: from adsl236-210.advancedsl.com.ar ([200.51.236.210] helo=mail3.telefonica.com.ar) by ietf-mx with esmtp (Exim 4.12) id 1BEUV7-0001oP-00 for sipping@ietf.org; Fri, 16 Apr 2004 10:39:30 -0400 Received: from mailhub.telefonica.com.ar ([10.249.7.11]) by mail3 with InterScan Messaging Security Suite; Fri, 16 Apr 2004 11:39:40 -0300 Received: by mailhub.telefonica.com.ar with Internet Mail Service (5.5.2657.72) id ; Fri, 16 Apr 2004 11:39:10 -0300 Message-ID: From: De Leo Walter To: "'Cullen Jennings'" Cc: "'sipping@ietf.org'" Subject: [Sipping] Use of P-Asserted Date: Fri, 16 Apr 2004 11:38:51 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C423C0.88EF8CB0" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_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_01C423C0.88EF8CB0 Content-Type: text/plain; charset="iso-8859-1" Cullen: I have one concern about a use of a P-Asserted Identity header that some folks are using. It is, from my point of view out of the scope of RFC 3325, but I think it is a reasonable use. The use I am referring to is the following: Calls initiated by UACs inside the trust domain include the P-Asserted Identity (they are part of the network who asserts the identity) header in their own INVITEs. I refer specifically to this scenario: Suppose a SIP an ingress Media Gateway Controller, a B2BUA Service Platform and an egress MGC. Calls initiated (from the SIP viewpoint) by ingress MGC or B2BUA carry the P-Asserted Identity header inserted by themselves. The egress Media Gateway Controller maps allways the content of the P-Assertd Identity header to the ANI field in corresponding ISUP message and the presentation restriction information in the Privacy Header to the corresponding ISUP field. So the egress MGC has always the same policy, INVITES which don't have a P-Asserted Identity header are not trusted, and if they have one either it comes from a UAC authenticated by a proxy in the Trust domain or it comes from inside the Trust domain itself and are, hence, trusted. (I am asuming the communication inside the trust domain is safe). Do you see any problem in this use of P-Asserted Identity header. I write to you because you are co-author of RFC 3325. I hope not having disturbed you with this question. I copy the sipping list just in case someone else has seen this use of P-Asserted Identity header and has something to say. Best Regards. Walter D. De Leo ------_=_NextPart_001_01C423C0.88EF8CB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Sipping] Use of P-Asserted

Cullen:

I have one concern about a use of a P-Asserted = Identity header that some folks are using. It is, from my point of view = out of the scope of RFC 3325, but I think it is a reasonable use.  = The use I am referring to is the following:

Calls initiated by UACs inside the trust domain = include the P-Asserted Identity (they are part of the network who = asserts the identity) header in their own INVITEs.

I refer specifically to this scenario:

Suppose a SIP an ingress Media Gateway Controller, a = B2BUA Service Platform and an egress MGC.
Calls initiated (from the SIP viewpoint) by ingress = MGC or B2BUA carry the P-Asserted Identity header inserted by = themselves. The egress Media Gateway Controller maps allways the = content of the P-Assertd Identity header to the ANI field in = corresponding ISUP message and the presentation restriction information = in the Privacy Header to the corresponding ISUP field.

So the egress MGC has always the same policy, INVITES = which don't have a P-Asserted Identity header are not trusted, and if = they have one either it comes from a UAC authenticated by a proxy in = the Trust domain or it comes from inside the Trust domain itself and = are, hence, trusted. (I am asuming the communication inside the trust = domain is safe).

Do you see any problem in this use of P-Asserted = Identity header.

I write to you because you are co-author of RFC 3325. = I hope not having disturbed you with this question. I copy the sipping = list just in case someone else has seen this use of P-Asserted Identity = header and has something to say.

Best Regards.

Walter D. De Leo


------_=_NextPart_001_01C423C0.88EF8CB0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 16 11:52:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17278 for ; Fri, 16 Apr 2004 11:52: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 1BEVVn-0003RE-7N for sipping-archive@odin.ietf.org; Fri, 16 Apr 2004 11:44:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GFiFUJ013212 for sipping-archive@odin.ietf.org; Fri, 16 Apr 2004 11:44:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVMD-0000w4-7I for sipping-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 11:34: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 LAA16490 for ; Fri, 16 Apr 2004 11:34: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 1BEVMB-0005W1-Ri for sipping-web-archive@ietf.org; Fri, 16 Apr 2004 11:34:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEVL8-0005Pk-00 for sipping-web-archive@ietf.org; Fri, 16 Apr 2004 11:33:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEVKF-0005IM-00 for sipping-web-archive@ietf.org; Fri, 16 Apr 2004 11:32:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVDB-0007Ka-HN; Fri, 16 Apr 2004 11:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEV7h-0006Bg-45 for sipping@optimus.ietf.org; Fri, 16 Apr 2004 11:19: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 LAA15542 for ; Fri, 16 Apr 2004 11:19: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 1BEV7f-0004PM-Vo for sipping@ietf.org; Fri, 16 Apr 2004 11:19:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEV6b-0004Lx-00 for sipping@ietf.org; Fri, 16 Apr 2004 11:18:14 -0400 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1BEV5f-0004Gw-00 for sipping@ietf.org; Fri, 16 Apr 2004 11:17:15 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i3GFGYTN023797; Fri, 16 Apr 2004 10:16:34 -0500 (CDT) Message-ID: <407FF8D1.4020701@alcatel.com> Date: Fri, 16 Apr 2004 10:16:33 -0500 From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Gonzalo Camarillo , hisham.khartabil@nokia.com, sipping@ietf.org Subject: Re: [Sipping] Re:draft-camarillo-sipping-uri-list-02.txt References: <2038BCC78B1AD641891A0D1AE133DBB701797908@esebe019.ntc.nokia.com> <407F8265.6070605@ericsson.com> <407FE996.6000206@cisco.com> In-Reply-To: <407FE996.6000206@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit UDP induced message size limitation should be transparent to the user. 3261 has already specified proper handling for large messages. I think that should be enough to allow the client side deal with the problem transparently. Regards, Alex. Paul Kyzivat wrote: > Why can this be removed? Isn't it still a real issue? > > Or is this assumed to be fixed by the 3261 requirement that large > messages be delivered over TCP? > > Paul > > Gonzalo Camarillo wrote: > >> Hi, >> >> yes, I had already got this comment before, and I had logged a bug >> against it. The next revision of the draft will not have this paragraph. >> >> Thanks, >> >> Gonzalo >> >> hisham.khartabil@nokia.com wrote: >> >>> I think this paragraph can be entirely removed. >>> >>> /Hisham >>> >>> >>>> -----Original Message----- >>>> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On >>>> Behalf Of >>>> ext Paul Kyzivat >>>> Sent: 10.April.2004 01:06 >>>> To: sipping@ietf.org >>>> Subject: [Sipping] Re:draft-camarillo-sipping-uri-list-02.txt >>>> >>>> >>>> Section 4 says: >>>> >>>> As for any other SIP request, the size of requests carrying URI >>>> lists >>>> MUST NOT exceed 1300 bytes, unless the user agent client has >>>> positive >>>> knowledge that the message will not traverse a congestion-unsafe >>>> link >>>> at any hop, or that the message size is at least 200 bytes less >>>> than >>>> the lowest MTU value found en route to the server. >>>> >>>> I was curious about the implications of this, so I did some >>>> counting. I took the example in section 9 and stripped out all the >>>> leading blanks to get a plausible size estimate. The number I got >>>> was 1242, with four urls in the list. Each additional URL (of the >>>> size in the example) adds 37 bytes. So a list with more than 5 urls >>>> exceeds the 1300 byte limit. >>>> >>>> That says to me that this technique is pretty much useless except >>>> in carefully controlled networks, or when compression is used. >>>> Seems pretty limiting. So it seems likely that in practice content >>>> indirection will have to be used. >>>> >>>> Paul >>>> >>>> >>>> _______________________________________________ >>>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>> This list is for NEW development of the application of SIP >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sip@ietf.org for new developments of core SIP >>>> >>> >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >>> >> > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Apr 16 12:09:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18416 for ; Fri, 16 Apr 2004 12:09: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 1BEVkj-0007ID-R2 for sipping-archive@odin.ietf.org; Fri, 16 Apr 2004 11:59:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GFxf3x028029 for sipping-archive@odin.ietf.org; Fri, 16 Apr 2004 11:59:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVcU-0005Fv-V9 for sipping-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 11:51: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 LAA17197 for ; Fri, 16 Apr 2004 11:51: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 1BEVcT-0006UU-RJ for sipping-web-archive@ietf.org; Fri, 16 Apr 2004 11:51:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEVbU-0006PX-00 for sipping-web-archive@ietf.org; Fri, 16 Apr 2004 11:50:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEVaZ-0006MB-00 for sipping-web-archive@ietf.org; Fri, 16 Apr 2004 11:49:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVRj-0002PT-3R; Fri, 16 Apr 2004 11:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVEH-0007av-AE for sipping@optimus.ietf.org; Fri, 16 Apr 2004 11:26: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 LAA15957 for ; Fri, 16 Apr 2004 11:26: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 1BEVEG-0004rL-BD for sipping@ietf.org; Fri, 16 Apr 2004 11:26:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEVDI-0004nH-00 for sipping@ietf.org; Fri, 16 Apr 2004 11:25:09 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BEVCM-0004hg-00 for sipping@ietf.org; Fri, 16 Apr 2004 11:24:10 -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 i3GFNPLc029479; Fri, 16 Apr 2004 10:23:25 -0500 (CDT) Received: from ericsson.com (rvi2-93-39.sw.ericsson.se [153.88.93.39]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 23S9M409; Fri, 16 Apr 2004 10:23:17 -0500 Message-ID: <407FFA6F.9050000@ericsson.com> Date: Fri, 16 Apr 2004 18:23:27 +0300 X-Sybari-Trust: cb3a89b0 2c4885b5 be5c28fb 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: alex.audu@alcatel.com CC: Paul Kyzivat , hisham.khartabil@nokia.com, sipping@ietf.org Subject: Re: [Sipping] Re:draft-camarillo-sipping-uri-list-02.txt References: <2038BCC78B1AD641891A0D1AE133DBB701797908@esebe019.ntc.nokia.com> <407F8265.6070605@ericsson.com> <407FE996.6000206@cisco.com> <407FF8D1.4020701@alcatel.com> In-Reply-To: <407FF8D1.4020701@alcatel.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 Hi, yes, the idea is to reference RFC 3261. That is, we will not define any special handling for large messages in the uri list draft. Thanks, Gonzalo Alex Audu wrote: > UDP induced message size limitation should be transparent to the user. > 3261 has > already specified proper handling for large messages. I think that > should be enough > to allow the client side deal with the problem transparently. > > Regards, > Alex. > > Paul Kyzivat wrote: > >> Why can this be removed? Isn't it still a real issue? >> >> Or is this assumed to be fixed by the 3261 requirement that large >> messages be delivered over TCP? >> >> Paul >> >> Gonzalo Camarillo wrote: >> >>> Hi, >>> >>> yes, I had already got this comment before, and I had logged a bug >>> against it. The next revision of the draft will not have this paragraph. >>> >>> Thanks, >>> >>> Gonzalo >>> >>> hisham.khartabil@nokia.com wrote: >>> >>>> I think this paragraph can be entirely removed. >>>> >>>> /Hisham >>>> >>>> >>>>> -----Original Message----- >>>>> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On >>>>> Behalf Of >>>>> ext Paul Kyzivat >>>>> Sent: 10.April.2004 01:06 >>>>> To: sipping@ietf.org >>>>> Subject: [Sipping] Re:draft-camarillo-sipping-uri-list-02.txt >>>>> >>>>> >>>>> Section 4 says: >>>>> >>>>> As for any other SIP request, the size of requests carrying URI >>>>> lists >>>>> MUST NOT exceed 1300 bytes, unless the user agent client has >>>>> positive >>>>> knowledge that the message will not traverse a congestion-unsafe >>>>> link >>>>> at any hop, or that the message size is at least 200 bytes less >>>>> than >>>>> the lowest MTU value found en route to the server. >>>>> >>>>> I was curious about the implications of this, so I did some >>>>> counting. I took the example in section 9 and stripped out all the >>>>> leading blanks to get a plausible size estimate. The number I got >>>>> was 1242, with four urls in the list. Each additional URL (of the >>>>> size in the example) adds 37 bytes. So a list with more than 5 urls >>>>> exceeds the 1300 byte limit. >>>>> >>>>> That says to me that this technique is pretty much useless except >>>>> in carefully controlled networks, or when compression is used. >>>>> Seems pretty limiting. So it seems likely that in practice content >>>>> indirection will have to be used. >>>>> >>>>> Paul >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>>> This list is for NEW development of the application of SIP >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sip@ietf.org for new developments of core SIP >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>> This list is for NEW development of the application of SIP >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sip@ietf.org for new developments of core SIP >>>> >>> >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the 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 Sun Apr 18 05:49:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10689 for ; Sun, 18 Apr 2004 05:49: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 1BF8lV-00023w-Gn for sipping-archive@odin.ietf.org; Sun, 18 Apr 2004 05:39:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3I9d5or007923 for sipping-archive@odin.ietf.org; Sun, 18 Apr 2004 05:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF8kN-0001Pe-3R for sipping-web-archive@optimus.ietf.org; Sun, 18 Apr 2004 05:37: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 FAA10254 for ; Sun, 18 Apr 2004 05:37:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BF8kJ-0004nn-MC for sipping-web-archive@ietf.org; Sun, 18 Apr 2004 05:37:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF8jH-0004aw-00 for sipping-web-archive@ietf.org; Sun, 18 Apr 2004 05:36:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BF8iK-0004PI-00 for sipping-web-archive@ietf.org; Sun, 18 Apr 2004 05: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 1BF8dh-00068f-O4; Sun, 18 Apr 2004 05:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFcC-0002Be-Kh for sipping@optimus.ietf.org; Thu, 15 Apr 2004 18:45: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 SAA06640 for ; Thu, 15 Apr 2004 18:45: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 1BEFc9-0003NK-GM for sipping@ietf.org; Thu, 15 Apr 2004 18:45:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEFbQ-0003L5-00 for sipping@ietf.org; Thu, 15 Apr 2004 18:45:00 -0400 Received: from sunfish.brooktrout.com ([63.68.86.8] helo=sunfish.netacc.com) by ietf-mx with esmtp (Exim 4.12) id 1BEFag-0003EL-00 for sipping@ietf.org; Thu, 15 Apr 2004 18:44:14 -0400 Received: from pobox2.netacc.com (pobox2.netacc.com [63.68.86.135]) by sunfish.netacc.com (8.11.2/8.11.2) with ESMTP id i3FLcv202217; Thu, 15 Apr 2004 17:38:57 -0400 Received: from puppy.office.snowshore.com (host202 [63.68.87.202]) by pobox2.netacc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HX10QC3P; Thu, 15 Apr 2004 18:39:09 -0400 To: Cullen Jennings , Eric Burger , "'sipping@ietf.org'" , jvandyke@snowshore.com, Alan Johnston References: Message-ID: From: Andy Spitzer Organization: Brooktrout Technologies Content-Type: text/plain; format=flowed; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Thu, 15 Apr 2004 18:38:56 -0400 In-Reply-To: User-Agent: Opera7.21/Linux M2 build 480 Content-Transfer-Encoding: 8bit Subject: [Sipping] Re: Service name stuff in natann 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Cullen, On Thu, 15 Apr 2004 15:23:23 -0700, Cullen Jennings wrote: > That a mixer service is somehow different than other services. I don't > see > how it is. An IVR system also has to run on a particular box. It may the > only box that has the voice prompts needed. Ahh, but for IVR, each and every CALL to the service is independant of every other call. If call A went to MS 1, and call B went to MS 2, both would work just fine, they do not need to know about each other; they are independentof each other. But for mixing, this is not true. Calls for each mix must find the media server hosting THAT mix. If call A went to MS 1, and call B when to MS 2, they would not be talking to each other! Each individual call is NOT indepentant of the other calls in that mix, thus they must "find" the correct MS that hosts that mix. This is why we put the conference id in the user part...so that each conference mix can be assigned a unique name (user part), and calls for that "user" find the correct MS that hosts that particular mix. Using the "normal" user@domain approach seemed like the right way to pin users (aka conference ids) to endpoints. --Andy Spitzer woof@brooktrout.com (new address) _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 19 00:34: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 AAA02508 for ; Mon, 19 Apr 2004 00:34: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 1BFQSo-00057v-UB for sipping-archive@odin.ietf.org; Mon, 19 Apr 2004 00:32:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3J4Ww3g019707 for sipping-archive@odin.ietf.org; Mon, 19 Apr 2004 00:32:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFQQX-0004lj-N3 for sipping-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 00:30: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 AAA02428 for ; Mon, 19 Apr 2004 00:30: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 1BFQQV-0003K0-5b for sipping-web-archive@ietf.org; Mon, 19 Apr 2004 00:30:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFQPZ-00037W-00 for sipping-web-archive@ietf.org; Mon, 19 Apr 2004 00:29:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFQOz-0002v6-00 for sipping-web-archive@ietf.org; Mon, 19 Apr 2004 00:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFQJC-0003EP-PG; Mon, 19 Apr 2004 00:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFQHm-0002u4-Go for sipping@optimus.ietf.org; Mon, 19 Apr 2004 00:21: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 AAA02140 for ; Mon, 19 Apr 2004 00:21: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 1BFQHj-0001O9-V2 for sipping@ietf.org; Mon, 19 Apr 2004 00:21:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFQGl-0001AH-00 for sipping@ietf.org; Mon, 19 Apr 2004 00:20:32 -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 1BFQFj-0000jE-00 for sipping@ietf.org; Mon, 19 Apr 2004 00:19:27 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 18 Apr 2004 20:30:13 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3J4ItnH023503; Sun, 18 Apr 2004 21:18:55 -0700 (PDT) Received: from [10.0.1.3] (sjc-vpn3-730.cisco.com [10.21.66.218]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOF15103; Sun, 18 Apr 2004 21:18:52 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 18 Apr 2004 20:08:47 -0700 Subject: Re: [Sipping] Use of P-Asserted From: Cullen Jennings To: De Leo Walter CC: "'sipping@ietf.org'" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3165167932_2076171" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3165167932_2076171 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Not sure I fully understand but I think what you are saying sounds like a reasonable way to use it. By UAC=B9s in the trust domain I assume you mean GWs, Call Agents, and B2BUA, that are trusted not IP Phones sitting on someone's desk. On 4/16/04 7:38 AM, "De Leo Walter" wrote: > Cullen:=20 >=20 > I have one concern about a use of a P-Asserted Identity header that some = folks > are using. It is, from my point of view out of the scope of RFC 3325, but= I > think it is a reasonable use. The use I am referring to is the following= : >=20 > Calls initiated by UACs inside the trust domain include the P-Asserted > Identity (they are part of the network who asserts the identity) header i= n > their own INVITEs. >=20 > I refer specifically to this scenario: >=20 > Suppose a SIP an ingress Media Gateway Controller, a B2BUA Service Platfo= rm > and an egress MGC. > Calls initiated (from the SIP viewpoint) by ingress MGC or B2BUA carry th= e > P-Asserted Identity header inserted by themselves. The egress Media Gatew= ay > Controller maps allways the content of the P-Assertd Identity header to t= he > ANI field in corresponding ISUP message and the presentation restriction > information in the Privacy Header to the corresponding ISUP field. >=20 > So the egress MGC has always the same policy, INVITES which don't have a > P-Asserted Identity header are not trusted, and if they have one either i= t > comes from a UAC authenticated by a proxy in the Trust domain or it comes= from > inside the Trust domain itself and are, hence, trusted. (I am asuming the > communication inside the trust domain is safe). >=20 > Do you see any problem in this use of P-Asserted Identity header. >=20 > I write to you because you are co-author of RFC 3325. I hope not having > disturbed you with this question. I copy the sipping list just in case so= meone > else has seen this use of P-Asserted Identity header and has something to= say. >=20 > Best Regards.=20 >=20 > Walter D. De Leo=20 >=20 >=20 --B_3165167932_2076171 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sipping] Use of P-Asserted
Not sure I fully understand but I think what you are saying sounds like a r= easonable way to use it.

By UAC’s in the trust domain I assume you mean GWs, Call Agents, and = B2BUA, that are trusted not IP Phones sitting on someone's desk.


On 4/16/04 7:38 AM, "De Leo Walter" <deleow@TELEFONICA.COM.AR&= gt; wrote:

Cullen:

I have one concern about a use of a P-Asserted Identity header that some fo= lks are using. It is, from my point of view out of the scope of RFC 3325, bu= t I think it is a reasonable use.  The use I am referring to is the fol= lowing:

Calls initiated by UACs inside the trust domain include the P-Asserted Iden= tity (they are part of the network who asserts the identity) header in their= own INVITEs.

I refer specifically to this scenario:

Suppose a SIP an ingress Media Gateway Controller, a B2BUA Service Platform= and an egress MGC.
Calls initiated (from the SIP viewpoint) by ingress MGC or B2BUA carry the = P-Asserted Identity header inserted by themselves. The egress Media Gateway = Controller maps allways the content of the P-Assertd Identity header to the = ANI field in corresponding ISUP message and the presentation restriction inf= ormation in the Privacy Header to the corresponding ISUP field.

So the egress MGC has always the same policy, INVITES which don't have a P-= Asserted Identity header are not trusted, and if they have one either it com= es from a UAC authenticated by a proxy in the Trust domain or it comes from = inside the Trust domain itself and are, hence, trusted. (I am asuming the co= mmunication inside the trust domain is safe).

Do you see any problem in this use of P-Asserted Identity header.

I write to you because you are co-author of RFC 3325. I hope not having dis= turbed you with this question. I copy the sipping list just in case someone = else has seen this use of P-Asserted Identity header and has something to sa= y.

Best Regards.

Walter D. De Leo



--B_3165167932_2076171-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 19 08:07:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06500 for ; Mon, 19 Apr 2004 08:07: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 1BFXXP-0004q4-0F for sipping-archive@odin.ietf.org; Mon, 19 Apr 2004 08:06:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JC6AcQ018600 for sipping-archive@odin.ietf.org; Mon, 19 Apr 2004 08:06:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFXWC-0004aL-Q6 for sipping-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 08:04: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 IAA06354 for ; Mon, 19 Apr 2004 08:04: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 1BFXWB-0002qp-Qm for sipping-web-archive@ietf.org; Mon, 19 Apr 2004 08:04:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFXVD-0002df-00 for sipping-web-archive@ietf.org; Mon, 19 Apr 2004 08:03:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFXUQ-0002RM-00 for sipping-web-archive@ietf.org; Mon, 19 Apr 2004 08:03:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFXPV-0003AK-Un; Mon, 19 Apr 2004 07:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFXKe-0001yp-Md for sipping@optimus.ietf.org; Mon, 19 Apr 2004 07:53: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 HAA05891 for ; Mon, 19 Apr 2004 07:52:59 -0400 (EDT) From: sreeram.kanumuri@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFXKd-0000L1-Qz for sipping@ietf.org; Mon, 19 Apr 2004 07:52:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFXJk-00007E-00 for sipping@ietf.org; Mon, 19 Apr 2004 07:52:05 -0400 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1BFXIr-0007Si-00 for sipping@ietf.org; Mon, 19 Apr 2004 07:51:10 -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 i3JBoZIn016579 for ; Mon, 19 Apr 2004 17:20:35 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Mon, 19 Apr 2004 17:20:34 +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); Mon, 19 Apr 2004 17:20:33 +0530 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Apr 2004 17:20:33 +0530 Message-ID: <72001BBBF6CB124BA1C40E415914E21312C5BF@blr-ec-msg04.wipro.com> Thread-Topic: [Sip-implementors] B2BUA for testing.. Thread-Index: AcQmBBz4A0HRSJFjTteZN+5bDKv0lwAAJuOg To: , Cc: X-OriginalArrivalTime: 19 Apr 2004 11:50:33.0954 (UTC) FILETIME=[85C9DC20:01C42604] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: [Sip-implementors] B2BUA for testing.. Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 Look at: www.vovida.org you can find B2B implementation. SReeram -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of badrisree@npd.hcltech.com Sent: Monday, April 19, 2004 5:16 PM To: sip-implementors@cs.columbia.edu Cc: sipping@ietf.org Subject: [Sip-implementors] B2BUA for testing.. Hi: I am developing a test suite for testing a B2BUA implementation..Are there any freely available B2BUA implementation available for this purpose. Any pointers would be of great help. Thanks, Badri Badri Srinivasan S Networking Technology Labs, HCL Technologies, Plot No:66 South Phase Ambattur Industrial Estate Chennai-58 Phone:91 44 26521077, 26521270 Xtn: 2243 Fax 52060485 ------------------------------------------------------------------------ ---- ----------- "After much research, Polycom selected HCL's SIP protocol tester to ensure our products deliver the carrier-grade reliability our conferencing service providers demand. In addition, HCL's tools provide the in-depth testing we need to speed the certification of our Voice over IP solutions and guarantee interoperability," said Matt Taylor, Staff Engineer for Polycom ------------------------------------------------------------------------ ---- ------------ visit us @ http://www.hcltechnologies.com/voip _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 19 10:05: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 KAA11913 for ; Mon, 19 Apr 2004 10:05: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 1BFZIM-00032Y-5w for sipping-archive@odin.ietf.org; Mon, 19 Apr 2004 09:58:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JDwkMd011681 for sipping-archive@odin.ietf.org; Mon, 19 Apr 2004 09: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 1BFZGd-0002mE-5m for sipping-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 09:56: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 JAA11338 for ; Mon, 19 Apr 2004 09:56:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFZGb-0004tc-5b for sipping-web-archive@ietf.org; Mon, 19 Apr 2004 09:56:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZFf-0004eq-00 for sipping-web-archive@ietf.org; Mon, 19 Apr 2004 09:56:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFZEj-0004Pg-00 for sipping-web-archive@ietf.org; Mon, 19 Apr 2004 09:55:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZ45-0008IF-Fy; Mon, 19 Apr 2004 09:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZ1B-0007wn-1V for sipping@optimus.ietf.org; Mon, 19 Apr 2004 09:41: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 JAA10658 for ; Mon, 19 Apr 2004 09:40: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 1BFZ19-0001Ha-7M for sipping@ietf.org; Mon, 19 Apr 2004 09:40:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZ0C-00014Z-00 for sipping@ietf.org; Mon, 19 Apr 2004 09:40:01 -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 1BFYzP-0000eX-00 for sipping@ietf.org; Mon, 19 Apr 2004 09:39:11 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 Apr 2004 05:48:47 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3JDcYnH000587; Mon, 19 Apr 2004 06:38:37 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHR68728; Mon, 19 Apr 2004 09:38:32 -0400 (EDT) Message-ID: <4083D661.6070609@cisco.com> Date: Mon, 19 Apr 2004 09:38:41 -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: badrisree@npd.hcltech.com CC: sip-implementors@cs.columbia.edu, sipping@ietf.org References: <50D40047DC73D611BDA60050BAC4EDD9010C94DC@PILEX> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Sip-implementors] Call Transfer through B2BUA.. Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 badrisree@npd.hcltech.com wrote: > Hi All, > > The 3pcc RFC 3725 depicts call flows that are best current practices for > B2BUAs... > In all the Call Flows the signalling initiates from the B2BUA i.e the INVITE > is sent from the B2BUA that then puts the 2 UAs into a Call. > But in the real life scenario like Call Transfer, the Call originates from > an End Point A that then reaches a IP-PBX (B2BUA) that then tranfers the > Call to End Point B. Pl. find below the flows equivalent to those given in > the RFC 3725 where the Call originates from an End Point. [snip] > Flow 4 in RFC 3725 sends out an INVITE from the B2BUA without any media line > in the Sdp. > This flow is not possible for an INVITE that comes from an external enppoint > that will always have an SDP with some media line. It may be improbable, but it isn't impossible. For instance, suppose A was yet another B2BUA that is itself carrying out flow 4. > I am in the process of coming up with a test Suite for B2BUA. I am assumuing > that a B2BUA that implements Call Transfer functionality will use any one of > the above flows to achieve Call transfer. Am I correct in assuming this. A B2BUA is a very general concept. There are many uses for them. You cannot infer very much about the behavior of a B2BUA *in general*, so it is nearly impossible to test that one is acting correctly, except that both sides of it adhere to the rules for a UA. I suggest you abandon any attempt to generically test a B2BUA. Instead, decide on the behavior you require of the kind of B2BUA you are interested in and test that. If you are interested in a B2BUA that acts as a control point in the middle of calls handled by an IP-PBX, then test for that. You will have to figure out the requirements that need testing, because there are no standards for such a beast. > Also in general in any B2BUA call flow, in a real life situation the Call > originates from an Endpoint and reaches the B2BUA that then ends & initiates > the Call and controls it. Is that correct..? Not in general. For instance it isn't true for a "click to dial" application. Maybe it is true for the kind of B2BUA you are interested in. 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 Apr 20 02:19:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24800 for ; Tue, 20 Apr 2004 02:19: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 1BFoZs-0000YY-9e for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 02:17:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K6HqYf002098 for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 02:17:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFoS1-0004Rb-VQ for sipping-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 02:09: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 CAA21034 for ; Tue, 20 Apr 2004 02:09: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 1BFoRy-0005oh-Ey for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 02:09:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFoR3-0005aY-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 02:08:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFoQS-0005M1-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 02:08:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFoMU-0000jW-1z; Tue, 20 Apr 2004 02:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFUjm-0003K4-CG for sipping@optimus.ietf.org; Mon, 19 Apr 2004 05:06: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 FAA27887 for ; Mon, 19 Apr 2004 05:06:43 -0400 (EDT) From: badrisree@npd.hcltech.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFUjj-0002cG-2A for sipping@ietf.org; Mon, 19 Apr 2004 05:06:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFUik-0002Pg-00 for sipping@ietf.org; Mon, 19 Apr 2004 05:05:43 -0400 Received: from [202.54.64.17] (helo=hclnpd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BFUhi-00021n-00 for sipping@ietf.org; Mon, 19 Apr 2004 05:04:39 -0400 Received: from pilex.hclt-ntl.co.in ([192.168.19.34]) by hclnpd.hcltech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HT657S3H; Mon, 19 Apr 2004 14:34:10 +0530 Received: by PILEX with Internet Mail Service (5.5.2653.19) id <28G615S5>; Mon, 19 Apr 2004 14:36:38 +0530 Message-ID: <50D40047DC73D611BDA60050BAC4EDD9010C94DC@PILEX> To: sip-implementors@cs.columbia.edu Cc: sipping@ietf.org Date: Mon, 19 Apr 2004 14:36:30 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] Call Transfer through B2BUA.. Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 Hi All, The 3pcc RFC 3725 depicts call flows that are best current practices for B2BUAs... In all the Call Flows the signalling initiates from the B2BUA i.e the INVITE is sent from the B2BUA that then puts the 2 UAs into a Call. But in the real life scenario like Call Transfer, the Call originates from an End Point A that then reaches a IP-PBX (B2BUA) that then tranfers the Call to End Point B. Pl. find below the flows equivalent to those given in the RFC 3725 where the Call originates from an End Point. Equivalent to Flow 1 A B2BUA B INV (Sdp A) ------------> 100 Trying INV (Sdp A) <------------ ------------> 200 (Sdp B) <-------------- ACK 200 (Sdp B) -----------> <------------- ACK ------------> RTP <-----------------------------------> Equivalent to Flow 2 A B2BUA B INV (Sdp A) --------------> 200 ( blackhole Sdp) <-------------- INV (Sdp A) ACK -------------> <--------------- 200 (Sdp B) <------------- ACK --------------> ReINV (Sdp B) <-------------- 200 --------------> ACK <-------------- RTP <--------------------------------> Equivalent to Flow 3 A B2BUA B INV (Sdp A) --------------> 200 (black hole Sdp) <-------------- ACK ---------------> INV (No Sdp) ---------------> 200 (Sdp B) <-------------- ReINV (Sdp B) <--------------- 200 (Sdp C) ---------------> ACK (Sdp C) ----------------> ACK <--------------- RTP <---------------------------------> Flow 4 in RFC 3725 sends out an INVITE from the B2BUA without any media line in the Sdp. This flow is not possible for an INVITE that comes from an external enppoint that will always have an SDP with some media line. I am in the process of coming up with a test Suite for B2BUA. I am assumuing that a B2BUA that implements Call Transfer functionality will use any one of the above flows to achieve Call transfer. Am I correct in assuming this. Also in general in any B2BUA call flow, in a real life situation the Call originates from an Endpoint and reaches the B2BUA that then ends & initiates the Call and controls it. Is that correct..? Thanks, Badri Badri Srinivasan S Networking Technology Labs, HCL Technologies, Plot No:66 South Phase Ambattur Industrial Estate Chennai-58 Phone:91 44 26521077, 26521270 Xtn: 2243 Fax 52060485 ---------------------------------------------------------------------------- ----------- "After much research, Polycom selected HCL's SIP protocol tester to ensure our products deliver the carrier-grade reliability our conferencing service providers demand. In addition, HCL's tools provide the in-depth testing we need to speed the certification of our Voice over IP solutions and guarantee interoperability," said Matt Taylor, Staff Engineer for Polycom ---------------------------------------------------------------------------- ------------ visit us @ http://www.hcltechnologies.com/voip _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 20 02:19: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 CAA24910 for ; Tue, 20 Apr 2004 02:19: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 1BFoZv-0000dy-Tb for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 02:17:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K6Htwo002459 for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 02:17:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFoWq-00073W-3H for sipping-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 02:14: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 CAA24363 for ; Tue, 20 Apr 2004 02:14: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 1BFoWm-00070O-GA for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 02:14:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFoVv-0006m9-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 02:13:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFoVK-0006XZ-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 02:13:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFoMU-0000k1-Vb; Tue, 20 Apr 2004 02:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFXE1-0000rp-Nz for sipping@optimus.ietf.org; Mon, 19 Apr 2004 07:46: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 HAA05501 for ; Mon, 19 Apr 2004 07:46:08 -0400 (EDT) From: badrisree@npd.hcltech.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFXE0-0006Wa-Qs for sipping@ietf.org; Mon, 19 Apr 2004 07:46:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFXD2-0006Ha-00 for sipping@ietf.org; Mon, 19 Apr 2004 07:45:09 -0400 Received: from [202.54.64.17] (helo=hclnpd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BFXC3-0005pX-00 for sipping@ietf.org; Mon, 19 Apr 2004 07:44:08 -0400 Received: from pilex.hclt-ntl.co.in ([192.168.19.34]) by hclnpd.hcltech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HT6574L2; Mon, 19 Apr 2004 17:13:37 +0530 Received: by PILEX with Internet Mail Service (5.5.2653.19) id <28G6155G>; Mon, 19 Apr 2004 17:16:05 +0530 Message-ID: <50D40047DC73D611BDA60050BAC4EDD9010C9550@PILEX> To: sip-implementors@cs.columbia.edu Cc: sipping@ietf.org Date: Mon, 19 Apr 2004 17:16:04 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] B2BUA for testing.. Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 Hi: I am developing a test suite for testing a B2BUA implementation..Are there any freely available B2BUA implementation available for this purpose. Any pointers would be of great help. Thanks, Badri Badri Srinivasan S Networking Technology Labs, HCL Technologies, Plot No:66 South Phase Ambattur Industrial Estate Chennai-58 Phone:91 44 26521077, 26521270 Xtn: 2243 Fax 52060485 ---------------------------------------------------------------------------- ----------- "After much research, Polycom selected HCL's SIP protocol tester to ensure our products deliver the carrier-grade reliability our conferencing service providers demand. In addition, HCL's tools provide the in-depth testing we need to speed the certification of our Voice over IP solutions and guarantee interoperability," said Matt Taylor, Staff Engineer for Polycom ---------------------------------------------------------------------------- ------------ visit us @ http://www.hcltechnologies.com/voip _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 20 02:20: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 CAA24964 for ; Tue, 20 Apr 2004 02:20: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 1BFoa0-0000lp-46 for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 02:18:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K6I0GI002949 for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 02:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFoZl-0000Tr-W1 for sipping-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 02: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 CAA24609 for ; Tue, 20 Apr 2004 02: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 1BFoZi-0007j5-EF for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 02:17:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFoYk-0007U6-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 02:16:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFoYH-0007Fl-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 02:16:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFoMV-0000kb-S4; Tue, 20 Apr 2004 02:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFXov-0008WJ-R3 for sipping@optimus.ietf.org; Mon, 19 Apr 2004 08:24: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 IAA07043 for ; Mon, 19 Apr 2004 08:24: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 1BFXou-00071D-J2 for sipping@ietf.org; Mon, 19 Apr 2004 08:24:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFXnq-0006jr-00 for sipping@ietf.org; Mon, 19 Apr 2004 08:23:11 -0400 Received: from web11801.mail.yahoo.com ([216.136.172.155]) by ietf-mx with smtp (Exim 4.12) id 1BFXnK-0006VU-00 for sipping@ietf.org; Mon, 19 Apr 2004 08:22:38 -0400 Message-ID: <20040419122236.74689.qmail@web11801.mail.yahoo.com> Received: from [203.199.179.68] by web11801.mail.yahoo.com via HTTP; Mon, 19 Apr 2004 05:22:36 PDT Date: Mon, 19 Apr 2004 05:22:36 -0700 (PDT) From: Ramachandran Iyer To: badrisree@npd.hcltech.com, sip-implementors@cs.columbia.edu Cc: sipping@ietf.org In-Reply-To: <50D40047DC73D611BDA60050BAC4EDD9010C9550@PILEX> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-303367069-1082377356=:73637" Subject: [Sipping] Re: [Sip-implementors] B2BUA for testing.. Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_MESSAGE autolearn=no version=2.60 --0-303367069-1082377356=:73637 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA07044 Content-Transfer-Encoding: quoted-printable look @ sipcenter.com =20 u can find quite some info on test gears..etc,,, =20 Rama badrisree@npd.hcltech.com wrote: Hi: I am developing a test suite for testing a B2BUA implementation..Are ther= e any freely available B2BUA implementation available for this purpose. Any pointers would be of great help. Thanks, Badri Badri Srinivasan S Networking Technology Labs, HCL Technologies, Plot No:66 South Phase Ambattur Industrial Estate Chennai-58 Phone:91 44 26521077, 26521270 Xtn: 2243 Fax 52060485 -------------------------------------------------------------------------= --- ----------- "After much research, Polycom selected HCL's SIP protocol tester to ensur= e our products deliver the carrier-grade reliability our conferencing servi= ce providers demand. In addition, HCL's tools provide the in-depth testing w= e need to speed the certification of our Voice over IP solutions and guaran= tee interoperability," said Matt Taylor, Staff Engineer for Polycom -------------------------------------------------------------------------= --- ------------ visit us @ http://www.hcltechnologies.com/voip _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors =09 --------------------------------- Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25=A2 --0-303367069-1082377356=:73637 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA07044 Content-Transfer-Encoding: quoted-printable
look @ sipcenter.com 
  u can find quite some info on test gears..etc,,,
 
Rama


badrisree@npd.hcltech.com wrote:
Hi:

I am developing a test suite f= or testing a B2BUA implementation..Are there
any freely available B2BU= A implementation available for this purpose.
Any pointers would be of = great help.

Thanks,
Badri

Badri Srinivasan S
Networki= ng Technology Labs,
HCL Technologies,
Plot No:66 South Phase
Amb= attur Industrial Estate
Chennai-58
Phone:91 44 26521077, 26521270 X= tn: 2243
Fax 52060485

-----------------------------------------= -----------------------------------
-----------
"After much researc= h, Polycom sselected HCL's SIP protocol tester to ensure
our products = deliver the carrier-grade reliability our conferencing service
provide= rs demand. In addition, HCL's tools provide the in-depth testing we
ne= ed to speed the certification of our Voice over IP solutions and guarante= e
interoperability," said Matt Taylor, Staff Engineer for Polycom
------------------------------------------------= ----------------------------
------------

visit us @ http://www= .hclttechnologies.com/voip
___________________________________________= ____
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu=
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25=A2 --0-303367069-1082377356=:73637-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 20 08:05: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 IAA12001 for ; Tue, 20 Apr 2004 08:05: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 1BFtyS-00054Y-7X for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 08:03:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KC3arU019498 for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 08:03:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFtvR-0004Qd-JZ for sipping-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 08:00: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 IAA11407 for ; Tue, 20 Apr 2004 08:00: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 1BFtvQ-0005LG-Qt for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 08:00:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFtu0-0004w4-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 07:59:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFttO-0004fG-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 07:58:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFtlK-0001sx-F4; Tue, 20 Apr 2004 07:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFtgR-0000Xq-EX for sipping@optimus.ietf.org; Tue, 20 Apr 2004 07:44: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 HAA10827 for ; Tue, 20 Apr 2004 07:44: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 1BFtgQ-0001CO-Lo for sipping@ietf.org; Tue, 20 Apr 2004 07:44:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFtfZ-0000wy-00 for sipping@ietf.org; Tue, 20 Apr 2004 07:44:06 -0400 Received: from smtpout-1-2d.secureserver.net ([64.202.165.68]) by ietf-mx with smtp (Exim 4.12) id 1BFtfC-0000gu-00 for sipping@ietf.org; Tue, 20 Apr 2004 07:43:42 -0400 Received: (qmail 30052 invoked from network); 20 Apr 2004 11:43:09 -0000 Received: from unknown (66.120.182.26) by smtpout-1-2d.secureserver.net (64.202.165.68) with ESMTP; 20 Apr 2004 11:43:09 -0000 Reply-To: From: "Scott Keagy" To: , Date: Tue, 20 Apr 2004 04:43:02 -0700 Organization: Emergicom, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQmvJphuov9nmLoTLyB6O1YZmnA7g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-Id: Content-Transfer-Encoding: 7bit Subject: [Sipping] emergency call-back scenarios and requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Need to be specific in managing emergency call-backs (don't know if this has already been discussed). If I'm sips:skeagy@emergicom.com as my call-back, and I have 3 devices (one of which is in my wife's possession in a different state/country while I'm traveling for work), I want to make sure that my wife doesn't answer a call-back first and cut me out of the loop accidentally. I'm sure she'd be happy to be aware of the incident (and stressed it's happening), but it would be disconcerting to me to not have updates or be able to provide more useful details to speed a response. This is aggravated in an enterprise where you have multiple line appearances with same phone number or identifier, and they can be in separate states and answered by people with no real knowledge of or vested interest in each other. So here's a set of requirements (or best practice suggestions) to the problem of handling emergency call-backs: 1) need to recognize when an inbound call to arbitrary subscriber is related to an emergency incident. Would be useful classification for applying call-based precedence/preemption policies (can argue all day about whether or not this is a good thing, but having the nerd knob lets the affected user make the decision), as well as recognizing when to apply the rule of steering the call to a given device. 2) Default configuration of proxies to do a serial search for an end device associated with a URI (as opposed to a forked/parallel search) when the inbound call is recognized as an emergency callback. 3) The first device on the list of serial searches for emergency call-backs is the last one cached that made an emergency call. Apply whatever policies for remainder (for example, whatever is preferred policy for normal calls, or perhaps a forced parallel/forked search to get a quick response on any other related line if no response on primary device). 4) This implies that all emergency calls with a reply-to or From: header are from devices that are in the search-list for the URI in the reply-to or From: header. Client devices should be able to verify whether this is the case, and warn the user or administrator during configuration if it's not the case) Regards, Scott _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 20 09:55: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 JAA18104 for ; Tue, 20 Apr 2004 09:55: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 1BFvZH-0008K0-GB for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 09:45:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KDjhma031983 for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 09:45:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvSu-0003hf-EU for sipping-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 09:39:08 -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 JAA17365 for ; Tue, 20 Apr 2004 09:39: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 1BFvSs-0002UP-Lr for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 09:39:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvS0-0002Ed-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 09:38:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFvRd-0001yA-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 09:37:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvJ9-0000rB-Sh; Tue, 20 Apr 2004 09:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvCT-00070P-Uo for sipping@optimus.ietf.org; Tue, 20 Apr 2004 09:22: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 JAA16354 for ; Tue, 20 Apr 2004 09:22: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 1BFvCS-0005a8-88 for sipping@ietf.org; Tue, 20 Apr 2004 09:22:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvBS-0005K8-00 for sipping@ietf.org; Tue, 20 Apr 2004 09:21:07 -0400 Received: from [200.51.236.210] (helo=mail3.telefonica.com.ar) by ietf-mx with esmtp (Exim 4.12) id 1BFvAo-00054d-00 for sipping@ietf.org; Tue, 20 Apr 2004 09:20:26 -0400 Received: from mailhub.telefonica.com.ar ([10.249.7.11]) by mail3 with InterScan Messaging Security Suite; Tue, 20 Apr 2004 10:20:54 -0300 Received: by mailhub.telefonica.com.ar with Internet Mail Service (5.5.2657.72) id ; Tue, 20 Apr 2004 10:20:21 -0300 Message-ID: From: De Leo Walter Cc: sipping@ietf.org Subject: RE: [Sipping] Use of P-Asserted Date: Tue, 20 Apr 2004 10:20:15 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C426DA.37A17270" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_FONTCOLOR_BLUE, HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C426DA.37A17270 Content-Type: text/plain; charset="iso-8859-1" Thank you for your answer. It is very useful to me to know your opinion. More inline Regards. -----Mensaje original----- De: Cullen Jennings [mailto:fluffy@cisco.com] Enviado el: Lunes, 19 de Abril de 2004 12:09 a.m. Para: De Leo Walter CC: 'sipping@ietf.org' Asunto: Re: [Sipping] Use of P-Asserted Not sure I fully understand but I think what you are saying sounds like a reasonable way to use it. By UAC's in the trust domain I assume you mean GWs, Call Agents, and B2BUA, that are trusted not IP Phones sitting on someone's desk. [WDL] That's correct. We are talking of Call Agents, GW and B2BUA service platforms. On 4/16/04 7:38 AM, "De Leo Walter" wrote: Cullen: I have one concern about a use of a P-Asserted Identity header that some folks are using. It is, from my point of view out of the scope of RFC 3325, but I think it is a reasonable use. The use I am referring to is the following: Calls initiated by UACs inside the trust domain include the P-Asserted Identity (they are part of the network who asserts the identity) header in their own INVITEs. I refer specifically to this scenario: Suppose a SIP an ingress Media Gateway Controller, a B2BUA Service Platform and an egress MGC. Calls initiated (from the SIP viewpoint) by ingress MGC or B2BUA carry the P-Asserted Identity header inserted by themselves. The egress Media Gateway Controller maps allways the content of the P-Assertd Identity header to the ANI field in corresponding ISUP message and the presentation restriction information in the Privacy Header to the corresponding ISUP field. So the egress MGC has always the same policy, INVITES which don't have a P-Asserted Identity header are not trusted, and if they have one either it comes from a UAC authenticated by a proxy in the Trust domain or it comes from inside the Trust domain itself and are, hence, trusted. (I am asuming the communication inside the trust domain is safe). Do you see any problem in this use of P-Asserted Identity header. I write to you because you are co-author of RFC 3325. I hope not having disturbed you with this question. I copy the sipping list just in case someone else has seen this use of P-Asserted Identity header and has something to say. Best Regards. Walter D. De Leo ------_=_NextPart_001_01C426DA.37A17270 Content-Type: text/html; charset="iso-8859-1" Mensaje
Thank you for your answer. It is very useful to me to know your opinion.
More inline
Regards.
-----Mensaje original-----
De: Cullen Jennings [mailto:fluffy@cisco.com]
Enviado el: Lunes, 19 de Abril de 2004 12:09 a.m.
Para: De Leo Walter
CC: 'sipping@ietf.org'
Asunto: Re: [Sipping] Use of P-Asserted

Not sure I fully understand but I think what you are saying sounds like a reasonable way to use it.

By UAC's in the trust domain I assume you mean GWs, Call Agents, and B2BUA, that are trusted not IP Phones sitting on someone's desk. [WDL]  That's correct. We are talking of Call Agents, GW and B2BUA service platforms.


On 4/16/04 7:38 AM, "De Leo Walter" <deleow@TELEFONICA.COM.AR> wrote:

Cullen:

I have one concern about a use of a P-Asserted Identity header that some folks are using. It is, from my point of view out of the scope of RFC 3325, but I think it is a reasonable use.  The use I am referring to is the following:

Calls initiated by UACs inside the trust domain include the P-Asserted Identity (they are part of the network who asserts the identity) header in their own INVITEs.

I refer specifically to this scenario:

Suppose a SIP an ingress Media Gateway Controller, a B2BUA Service Platform and an egress MGC.
Calls initiated (from the SIP viewpoint) by ingress MGC or B2BUA carry the P-Asserted Identity header inserted by themselves. The egress Media Gateway Controller maps allways the content of the P-Assertd Identity header to the ANI field in corresponding ISUP message and the presentation restriction information in the Privacy Header to the corresponding ISUP field.

So the egress MGC has always the same policy, INVITES which don't have a P-Asserted Identity header are not trusted, and if they have one either it comes from a UAC authenticated by a proxy in the Trust domain or it comes from inside the Trust domain itself and are, hence, trusted. (I am asuming the communication inside the trust domain is safe).

Do you see any problem in this use of P-Asserted Identity header.

I write to you because you are co-author of RFC 3325. I hope not having disturbed you with this question. I copy the sipping list just in case someone else has seen this use of P-Asserted Identity header and has something to say.

Best Regards.

Walter D. De Leo



------_=_NextPart_001_01C426DA.37A17270-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 20 11:03:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23871 for ; Tue, 20 Apr 2004 11:03: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 1BFwke-000220-4v for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 11:01:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KF1WpN007804 for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 11:01:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwaf-0006rq-CY for sipping-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 10:51: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 KAA23016 for ; Tue, 20 Apr 2004 10:51: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 1BFwac-0007Yo-UF for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 10:51:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwZj-0007Ih-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 10:50:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFwYz-00072i-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 10:49:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwPs-0003mk-Va; Tue, 20 Apr 2004 10:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwJC-0001Bb-6z for sipping@optimus.ietf.org; Tue, 20 Apr 2004 10:33: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 KAA21846 for ; Tue, 20 Apr 2004 10:33: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 1BFwJ9-0002UX-LC for sipping@ietf.org; Tue, 20 Apr 2004 10:33:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwIC-0002AA-00 for sipping@ietf.org; Tue, 20 Apr 2004 10:32:08 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BFwHD-0001sj-00; Tue, 20 Apr 2004 10:31:07 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KEV3O08090; Tue, 20 Apr 2004 17:31:03 +0300 (EET DST) X-Scanned: Tue, 20 Apr 2004 17:30:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3KEUuQo005960; Tue, 20 Apr 2004 17:30:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00gQUF5i; Tue, 20 Apr 2004 17:30:55 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 i3KEUUs06672; Tue, 20 Apr 2004 17:30:30 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Apr 2004 17:30:33 +0300 Message-ID: <40853408.1020804@nokia.com> Date: Tue, 20 Apr 2004 17:30:32 +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 Ben Campbell CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo References: <406DE1C8.3040309@dynamicsoft.com> In-Reply-To: <406DE1C8.3040309@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2004 14:30:33.0100 (UTC) FILETIME=[09BD0CC0:01C426E4] Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Simple] MESSAGE Exploders 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 Ben: Thanks for your comments. Sorry for my late answer. See my inline comments ext Ben Campbell wrote: > I like this approach overall. > > A couple of comments and questions. Apologies if these have already been > discussed. > > Is it legal for the list parameter to point to something other than a > body part? That is, can I have external lists? I believe this question lies in the field of the URI list draft (draft-camarillo-sipping-uri-list-02.txt). Section 8 of that draft has a discussion. > Saying the exploder MUST NOT include the URI list in the outbound > messages seems a little severe. I can imagine applications where I want > the recipients to know the list. This could be useful for "reply to all" > sort of functions. But if we do allow this, we would need to give the > sender a way to choose, possibly on a per-URI basis. (Sort of a "cc" vs. > "bcc" thing.) It seems reasonable to me. I think what we wanted to say is that the Request-URI of the outboud message SHOULD NOT contain a list parameter. The body need not carry the list, but may carry it for other purposes (such as the one you mentioned). > > Instead of saying that message exploders must always send message > requests, we might consider saying the outbound request method must > match the outbound method. This would allow for exploders that know how > to explode more than one method. No, I don't agree. In the past we got an agreement that we will create a message-specific exploder draft. There is a draft that says how to deal with INVITE, other for SUBSCRIBE, other for REFER, and this draft is about MESSAGE. We don't want to go back and make the draft generic, to be applicable to any method. So I believe the wording is correct as it is now. > > > When condidering DoS issues, it might be worth suggesting behavior if > the exploder finds duplicate URIs on the list. For example, I could put > the same URI in a bunch of times, and have a nice DoS amplifier.' Good point. We will add a discussion on the subject. Miguel. > > > Miguel Garcia wrote: > >>Hi: >> >>I have just submitted a draft that discusses a exploder of MESSAGEs. >> >>While it appears in the repository, you can download them from: >> >>http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt >> >>http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html >> >> >>Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING >>(exploders), I am copying both mailing lists. >> >>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 Tue Apr 20 12:18:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00873 for ; Tue, 20 Apr 2004 12:18: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 1BFxeq-0007at-BT for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 11:59:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KFxaQh029187 for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 11:59:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwym-0007FO-5H for sipping-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 11:16:08 -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 LAA24581 for ; Tue, 20 Apr 2004 11:16: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 1BFwyl-0006jk-Ba for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 11:16:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwy8-0006TE-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 11:15:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFwwv-0006D0-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 11: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 1BFwlF-0002Rb-4H; Tue, 20 Apr 2004 11: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 1BFwWs-0005kK-RS for sipping@optimus.ietf.org; Tue, 20 Apr 2004 10:47: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 KAA22813 for ; Tue, 20 Apr 2004 10: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 1BFwWq-0006SH-7m for sipping@ietf.org; Tue, 20 Apr 2004 10:47:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwVw-0006Bk-00 for sipping@ietf.org; Tue, 20 Apr 2004 10:46:21 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BFwVS-0005ur-00; Tue, 20 Apr 2004 10:45:50 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3KEjRIx023203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Apr 2004 09:45:29 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4085377E.602@dynamicsoft.com> Date: Tue, 20 Apr 2004 09:45:18 -0500 From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo References: <406DE1C8.3040309@dynamicsoft.com> <40853408.1020804@nokia.com> In-Reply-To: <40853408.1020804@nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Simple] MESSAGE Exploders 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Miguel Garcia wrote: [...] >> >> Instead of saying that message exploders must always send message >> requests, we might consider saying the outbound request method must >> match the outbound method. This would allow for exploders that know >> how to explode more than one method. > > > No, I don't agree. In the past we got an agreement that we will create a > message-specific exploder draft. There is a draft that says how to deal > with INVITE, other for SUBSCRIBE, other for REFER, and this draft is > about MESSAGE. We don't want to go back and make the draft generic, to > be applicable to any method. So I believe the wording is correct as it > is now. My concern is, the text as written can be interpreted to mean that device cannot be both a MESSAGE exploder and an INVITE exploder, because exploding INVITE explicitly violates a normative requirement for MESSAGE exploders. I know that is not the intent, but I think it can be misread. Perhaps we simply need to say that exploding non-MESSAGE methods is out of scope for this document. Thanks! Ben. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 20 13:18:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05521 for ; Tue, 20 Apr 2004 13:18: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 1BFycu-0002kK-70 for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 13:01:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KH1e19010552 for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 13:01:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyHj-0001a7-1v for sipping-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 12:39: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 MAA02062 for ; Tue, 20 Apr 2004 12:39: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 1BFyHh-0001KU-Ed for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 12:39:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFyGV-0000zS-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 12:38:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFyFc-0000gt-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 12:37:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxhF-00005n-OC; Tue, 20 Apr 2004 12:02:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFx6g-0002A7-Ny for sipping@optimus.ietf.org; Tue, 20 Apr 2004 11:24: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 LAA25109 for ; Tue, 20 Apr 2004 11:24: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 1BFx6f-00019t-T0 for sipping@ietf.org; Tue, 20 Apr 2004 11:24:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFx5k-0000s2-00 for sipping@ietf.org; Tue, 20 Apr 2004 11:23:21 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BFx4w-0000az-00; Tue, 20 Apr 2004 11:22:30 -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 i3KFMLm15100; Tue, 20 Apr 2004 18:22:21 +0300 (EET DST) X-Scanned: Tue, 20 Apr 2004 18:22:07 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3KFM7u7006218; Tue, 20 Apr 2004 18:22:07 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00MseyvS; Tue, 20 Apr 2004 18:22:04 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 i3KFM2F24506; Tue, 20 Apr 2004 18:22:02 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Apr 2004 18:22:04 +0300 Message-ID: <4085401C.2000008@nokia.com> Date: Tue, 20 Apr 2004 18:22:04 +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 Paul Kyzivat CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo Subject: Re: [Sipping] MESSAGE Exploders draft References: <406DF1EC.4050400@cisco.com> In-Reply-To: <406DF1EC.4050400@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2004 15:22:04.0911 (UTC) FILETIME=[3C99F7F0:01C426EB] Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Paul: Thanks for your comments. Answers inline. ext Paul Kyzivat wrote: > Miguel, > > In general the approach in the draft seems reasonable to me. > > I see one area of ambiguity, having to do with how multipart bodies are > handled. The draft says to remove the list and include everything else. > But even your example doesn't do that - it also removes the > multipart/mixed wrapper. Of course in this particular example that makes > perfect sense, but it goes beyond what the draft says to do. We start from the the fact that there will be as a minimum, two bodies, the list, and the actual payload. There might be more bodies, such as multiple payloads, S/MIME signatures, etc. I guess the algorithm should be: - If there is any kind of security body for the exploder (e.g., signed with the public key of the exploder), then remove that body. - Remove the list itself (in a typical use case, unless an extension says the oposite; I am referring to Ben's suggestion to allow it). - If there is only one body left, then remove the multipart/mixed wrapper. - Send the remaining stuff. > > There are more complex cases: > > - for security there could be signed body parts. > > - The signature could be on the multipart containing the message > and list. It would have to be removed. > > - The signature could be on just the message. Presumably > it should remain. > I agree. > > - There could be other body parts referenced by cid: urls in > other headers in the message. Yes, they should remain. > > I think there needs to be a more prescriptive way of defining what gets > passed on in the exploded messages. This is really just a manifestation > of a more general problem of how to decide how different body parts > should be processed. It potentially exists in a normal, unexploded, MESSAGE. > > I think at least part of the answer lies with Content-Disposition. I > think there should be clarity about the content-disposition should be > for the body part(s) that MESSAGE interprets as message content. > Probably "render" (which is default for sip) would be an appropriate > content-disposition for message content. Agree so far. It may happen that some of this stuff is generic enough (not MESSAGE specific). > > Also, I think there should be some clarity about what the > content-disposition should be for various kinds of multipart containers > when used in the various ways they may be used in sip. I'm not quite > sure what the answer is here. > > The list itself is of course referenced from a cid: url. It is the url > and its placement that determines how the corresponding body part should > be processed. For these, the content-disposition should be some value > that doesn't imply some other sort of processing. I think it can't be > any of "session", "render", "alert", or "icon". Maybe it could be > "attachment". I will be happy to have a very clear deterministic way to find out what to pass and what to keep to the other side of the exploder, base on presumabley the content-disposition. Let's see if I can come up with something. Thanks, Miguel > > Paul > > > > Miguel Garcia wrote: > >>Hi: >> >>I have just submitted a draft that discusses a exploder of MESSAGEs. >> >>While it appears in the repository, you can download them from: >> >>http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt >> >>http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html >> >> >>Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING >>(exploders), I am copying both mailing lists. >> >>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 Tue Apr 20 13:22:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05885 for ; Tue, 20 Apr 2004 13:22: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 1BFyfE-0003wK-Rk for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 13:04:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KH44DF015139 for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 13: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 1BFyJx-0002NF-Fh for sipping-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 12:42: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 MAA02323 for ; Tue, 20 Apr 2004 12:42: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 1BFyJv-000244-VT for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 12:42:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFyIV-0001eP-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 12:40:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFyHN-0001HS-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 12:39:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxn1-00030f-Jq; Tue, 20 Apr 2004 12:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxAJ-0003yT-PI for sipping@optimus.ietf.org; Tue, 20 Apr 2004 11:28: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 LAA25451 for ; Tue, 20 Apr 2004 11:28: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 1BFxAI-0002Lw-P2 for sipping@ietf.org; Tue, 20 Apr 2004 11:28:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFx8h-0001rP-00 for sipping@ietf.org; Tue, 20 Apr 2004 11:26:24 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BFx7T-0001SC-00; Tue, 20 Apr 2004 11:25:07 -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 i3KFP3j15868; Tue, 20 Apr 2004 18:25:03 +0300 (EET DST) X-Scanned: Tue, 20 Apr 2004 18:25:01 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3KFP1oJ019074; Tue, 20 Apr 2004 18:25:01 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 004Iqyi3; Tue, 20 Apr 2004 18:25:01 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 i3KFOms08142; Tue, 20 Apr 2004 18:24:48 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Apr 2004 18:24:48 +0300 Message-ID: <408540BF.6080102@nokia.com> Date: Tue, 20 Apr 2004 18:24:47 +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 Ben Campbell CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo References: <406DE1C8.3040309@dynamicsoft.com> <40853408.1020804@nokia.com> <4085377E.602@dynamicsoft.com> In-Reply-To: <4085377E.602@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2004 15:24:48.0287 (UTC) FILETIME=[9DFB2AF0:01C426EB] Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Simple] MESSAGE Exploders 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 ext Ben Campbell wrote: > > Miguel Garcia wrote: > > [...] > >>> >>> Instead of saying that message exploders must always send message >>> requests, we might consider saying the outbound request method must >>> match the outbound method. This would allow for exploders that know >>> how to explode more than one method. >> >> >> >> No, I don't agree. In the past we got an agreement that we will create >> a message-specific exploder draft. There is a draft that says how to >> deal with INVITE, other for SUBSCRIBE, other for REFER, and this draft >> is about MESSAGE. We don't want to go back and make the draft >> generic, to be applicable to any method. So I believe the wording is >> correct as it is now. > > > My concern is, the text as written can be interpreted to mean that > device cannot be both a MESSAGE exploder and an INVITE exploder, because > exploding INVITE explicitly violates a normative requirement for MESSAGE > exploders. I know that is not the intent, but I think it can be misread. > Perhaps we simply need to say that exploding non-MESSAGE methods is out > of scope for this document. > > Thanks! > > Ben. Ok, I understand your concern, and it sounds fine to me. We will specify that other messages are outside the scope of the document. Thanks. 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 Tue Apr 20 19:54: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 TAA08237 for ; Tue, 20 Apr 2004 19:54: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 1BG4zt-0001Uo-EK for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 19:49:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KNnnWE005744 for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 19:49:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4o1-0005CR-EJ for sipping-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 19:37: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 TAA07441 for ; Tue, 20 Apr 2004 19:37: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 1BG4nz-00059n-N0 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 19:37:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG4n4-00055K-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 19:36:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG4mX-0004zz-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 19:36:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4by-0006pl-Fp; Tue, 20 Apr 2004 19:25:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4Lk-0000Ps-4L for sipping@optimus.ietf.org; Tue, 20 Apr 2004 19:08: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 TAA05886 for ; Tue, 20 Apr 2004 19:08: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 1BG4Lg-0002k1-N2 for sipping@ietf.org; Tue, 20 Apr 2004 19:08:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG4Ko-0002gB-00 for sipping@ietf.org; Tue, 20 Apr 2004 19:07:23 -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 1BG4Jn-0002cT-00 for sipping@ietf.org; Tue, 20 Apr 2004 19:06:19 -0400 Received: from softarmor.com (c-24-1-178-197.client.comcast.net [24.1.178.197]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i3KN6Wu4014472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Apr 2004 18:06:36 -0500 Message-ID: <4085ACCD.6010204@softarmor.com> Date: Tue, 20 Apr 2004 18:05:49 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Spitzer CC: sipping@ietf.org Subject: Re: [Sipping] Re: Service name stuff in natann draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Andy Spitzer wrote: > This is why we put the conference id in the user part...so that each > conference mix can be assigned a unique name (user part), and calls for > that "user" find the correct MS that hosts that particular mix. Using > the "normal" user@domain approach seemed like the right way to pin users > (aka conference ids) to endpoints. Zork! It's a GRUU! -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Apr 20 19:55: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 TAA08386 for ; Tue, 20 Apr 2004 19:55: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 1BG519-0001jh-Ab for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 19:51:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KNp7sC006668 for sipping-archive@odin.ietf.org; Tue, 20 Apr 2004 19:51:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4tY-00078t-Am for sipping-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 19: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 TAA07672 for ; Tue, 20 Apr 2004 19:43: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 1BG4tW-0005YD-Jk for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 19:43:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG4sb-0005Vk-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 19:42:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG4s4-0005TA-00 for sipping-web-archive@ietf.org; Tue, 20 Apr 2004 19:41:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4c2-0006xS-TT; Tue, 20 Apr 2004 19:25:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4Pc-0001PJ-3h for sipping@optimus.ietf.org; Tue, 20 Apr 2004 19:12: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 TAA06090 for ; Tue, 20 Apr 2004 19:12: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 1BG4Pa-00032b-GV for sipping@ietf.org; Tue, 20 Apr 2004 19:12:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG4Od-0002yN-00 for sipping@ietf.org; Tue, 20 Apr 2004 19:11:20 -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 1BG4Nl-0002uN-00 for sipping@ietf.org; Tue, 20 Apr 2004 19:10:25 -0400 Received: from softarmor.com (c-24-1-178-197.client.comcast.net [24.1.178.197]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i3KNAiu4014489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Apr 2004 18:10:45 -0500 Message-ID: <4085ADC9.1050909@softarmor.com> Date: Tue, 20 Apr 2004 18:10:01 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: skeagy@emergicom.com, sipping@ietf.org Subject: Re: [Sipping] emergency call-back scenarios and requirements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Scott Keagy wrote: > Need to be specific in managing emergency call-backs (don't know if this > has already been discussed). Isn't it enough to say that the Contact used for emergency calls SHOULD be a GRUU, and that call-backs made from emergency call centers MUST use the Contact of the original call, not the AOR indicated in the From: field? -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Apr 21 04:37: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 EAA04049 for ; Wed, 21 Apr 2004 04:37: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 1BGDCu-0002bH-2y for sipping-archive@odin.ietf.org; Wed, 21 Apr 2004 04:35:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L8Zm77009995 for sipping-archive@odin.ietf.org; Wed, 21 Apr 2004 04:35:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGDA9-0001XU-DM for sipping-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 04:32: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 EAA03745 for ; Wed, 21 Apr 2004 04:32: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 1BGDA6-0003pT-JS for sipping-web-archive@ietf.org; Wed, 21 Apr 2004 04:32:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGD93-0003iN-00 for sipping-web-archive@ietf.org; Wed, 21 Apr 2004 04:31:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGD8h-0003bj-00 for sipping-web-archive@ietf.org; Wed, 21 Apr 2004 04:31:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCzZ-0006IA-Ab; Wed, 21 Apr 2004 04:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCwU-0004la-PE for sipping@optimus.ietf.org; Wed, 21 Apr 2004 04:18: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 EAA03094 for ; Wed, 21 Apr 2004 04:18: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 1BGCwR-0002FQ-V8 for sipping@ietf.org; Wed, 21 Apr 2004 04:18:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGCvZ-00026W-00 for sipping@ietf.org; Wed, 21 Apr 2004 04:17:54 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BGCuZ-0001yT-00 for sipping@ietf.org; Wed, 21 Apr 2004 04:16:51 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L8Gnk09193 for ; Wed, 21 Apr 2004 11:16:49 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 11:16:40 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3L8GeRl016022 for ; Wed, 21 Apr 2004 11:16:40 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00feN6lL; Wed, 21 Apr 2004 11:16:39 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 i3L8GWF25612 for ; Wed, 21 Apr 2004 11:16:32 +0300 (EET DST) Received: from nokia.com ([172.21.81.173]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 11:15:51 +0300 Message-ID: <40862DB6.80103@nokia.com> Date: Wed, 21 Apr 2004 11:15:50 +0300 From: "Niemi Aki (Nokia-M/Espoo)" User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Miguel Garcia CC: SIPPING WG Subject: Re: [Sipping] Re: [Simple] MESSAGE Exploders draft References: <406DE1C8.3040309@dynamicsoft.com> <40853408.1020804@nokia.com> In-Reply-To: <40853408.1020804@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2004 08:15:51.0148 (UTC) FILETIME=[DBDD2AC0:01C42778] 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 ext Miguel Garcia wrote: [snip] >> Saying the exploder MUST NOT include the URI list in the outbound >> messages seems a little severe. I can imagine applications where I >> want the recipients to know the list. This could be useful for >> "reply to all" sort of functions. But if we do allow this, we would >> need to give the sender a way to choose, possibly on a per-URI >> basis. (Sort of a "cc" vs. "bcc" thing.) > > > It seems reasonable to me. I think what we wanted to say is that the > Request-URI of the outboud message SHOULD NOT contain a list > parameter. The body need not carry the list, but may carry it for > other purposes (such as the one you mentioned). I agree. One other thing, to convey such Cc information to the final recipients of the explosion, message/cpim actually seems like a very good fit. It already has the To, Cc headers defined, and the sender can populate them as it sees fit and the exploder need not care. Including a URI in the MESSAGE resource list, but omitting it from the To, CC in message/cpim would result in exactly the Bcc-type behavior. Cheers, Aki _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 21 05:43:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07323 for ; Wed, 21 Apr 2004 05:43: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 1BGEDk-0001Sy-LK for sipping-archive@odin.ietf.org; Wed, 21 Apr 2004 05:40:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L9eiIS005632 for sipping-archive@odin.ietf.org; Wed, 21 Apr 2004 05:40:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGE43-0006nJ-7f for sipping-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 05:30: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 FAA06659 for ; Wed, 21 Apr 2004 05:30: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 1BGE3z-000340-Rb for sipping-web-archive@ietf.org; Wed, 21 Apr 2004 05:30:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGE33-0002xd-00 for sipping-web-archive@ietf.org; Wed, 21 Apr 2004 05:29:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGE29-0002rB-00 for sipping-web-archive@ietf.org; Wed, 21 Apr 2004 05:28:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGDvg-0003HL-56; Wed, 21 Apr 2004 05:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGDuV-0002ac-1t for sipping@optimus.ietf.org; Wed, 21 Apr 2004 05:20: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 FAA05924 for ; Wed, 21 Apr 2004 05:20: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 1BGDuR-0001e5-LL for sipping@ietf.org; Wed, 21 Apr 2004 05:20:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGDtR-0001Uy-00 for sipping@ietf.org; Wed, 21 Apr 2004 05:19:45 -0400 Received: from [218.1.66.101] (helo=mail.citiz.net) by ietf-mx with smtp (Exim 4.12) id 1BGDsQ-0001Nl-00 for sipping@ietf.org; Wed, 21 Apr 2004 05:18:43 -0400 Received: (umta 8047 invoked by alias); 21 Apr 2004 09:18:44 -0000 X-Lasthop: 218.1.121.106 Received: from unknown (HELO zhangpeihao) (unknown@218.1.121.106) by localhost with SMTP; 21 Apr 2004 09:18:44 -0000 Date: Wed, 21 Apr 2004 17:21:50 +0800 From: "Zhang Peihao" To: "sipping@ietf.org" X-mailer: Foxmail 5.0 beta1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Message-Id: Content-Transfer-Encoding: base64 Subject: [Sipping] When should attended Transferor drop the call Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,MIME_BASE64_TEXT, TO_ADDRESS_EQ_REAL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJbiBkcmFmdC1pZWZ0LXNpcHBpbmctY2MtdHJhbnNmZXItMDIudHh0Lg0KDQpJ IHRha2Ugbm90ZSBvZiB0aGUgYXR0ZW5kZWQgVHJhbnNmZXJvciBzaG91bGQgc2VuZCB0aGUgQllF DQp3aGVuIGhlIHJlY2VpdmVkIE5PVElGWSAoMjAwIE9LKS4NCg0KQnV0IG91ciBnZW5lcmFsIHBy b2Nlc3MgaXMgVHJhbnNmZXJvciBwcmVzc2VkIHRoZSBUcmFuc2Zlcg0Ka2V5IGFuZCB0aGVuIGRy b3AgdGhlIGNhbGwgYXQgb25jZSBkbyBub3Qgd2FpdCB0aGUgVHJhbnNmZXINClRhcmdldCdzIGFu c3dlci4NCg0KRG9zZSB0aGlzIGRyYWZ0IG1lYW4gVHJhbnNnZXJvciBNVVNUIGhhbmcgb24gYmVm b3JlIGhlIHJldmVpdmUNCnRoZSBOT1RJRlkgKDIwMCBPSyk/DQoNClpoYW5nIFBlaWhhbw0Kemhh bmdwZWloYW9AY2l0aXoubmV0DQoyMDA0LTA0LTIxDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCtXCxeDquw0Ko6i4u8q/zai8r83Fo6nJz7qjzajJzM34wufI 7bz+v6q3otPQz965q8u+DQrJz7qjytDM7Mm9wrc2NDG6xcnPuqO727nIsNfDqL/GvLzUsDO6xcKl NTAxytINCrXnu7CjujAyMS01MjUzMDQ5MSC0q9Xmo7owMjEtNTI1MzA1MjMNCtPKseCjujIwMDMz NiAgDQpFLU1haWw6IHpoYW5ncGVpaGFvQG5ldC0yY29tLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 21 18:22: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 SAA23250 for ; Wed, 21 Apr 2004 18:22: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 1BGPpE-0002W4-KJ for sipping-archive@odin.ietf.org; Wed, 21 Apr 2004 18:04:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LM4CjV009672 for sipping-archive@odin.ietf.org; Wed, 21 Apr 2004 18:04:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOoU-0000Kr-FY for sipping-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 16:59: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 QAA13969 for ; Wed, 21 Apr 2004 16:59: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 1BGOoS-0004L1-8V for sipping-web-archive@ietf.org; Wed, 21 Apr 2004 16:59:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGOnb-0004A4-00 for sipping-web-archive@ietf.org; Wed, 21 Apr 2004 16:58:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGOn4-0003yk-00 for sipping-web-archive@ietf.org; Wed, 21 Apr 2004 16:57:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOZn-0003TI-33; Wed, 21 Apr 2004 16:44:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGL3u-00060r-Fi for sipping@optimus.ietf.org; Wed, 21 Apr 2004 12:59: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 MAA02101 for ; Wed, 21 Apr 2004 12:58: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 1BGL3s-0002De-Be for sipping@ietf.org; Wed, 21 Apr 2004 12:59:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGL2y-000249-00 for sipping@ietf.org; Wed, 21 Apr 2004 12:58:06 -0400 Received: from mail3.pi.se ([195.7.64.137] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BGL2C-0001tv-00 for sipping@ietf.org; Wed, 21 Apr 2004 12:57:16 -0400 Received: from vit (136.240.13.217.in-addr.dgcsystems.net [217.13.240.136]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id i3LGsBUM009618; Wed, 21 Apr 2004 18:54:18 +0200 (CEST) From: "Gunnar Hellstrom" To: "Barry Dingle" , "Rosen, Brian" , "Arnoud van Wijk" , , Cc: , , , Subject: RE: Betr.: [Sipping] ToIP Requirements Date: Wed, 21 Apr 2004 18:56:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <00c801c3ff32$4dfb7a40$3d23ddcb@Home> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id i3LGsBUM009618 Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Just found this mail that I want to add some clarification to. A calling V.18 signals the V.8 CI tone signal with the "textphone" call type. It is a tone and a specific V.21 bit pattern. An old answering V.18 answers with ANS followed by a V.21 modulated signa= l called "txp". A newer answering V.18 answers with the full V.8 answering procedure starting with ANSAM. That is valid for proper V.18s Under v.18 interoperability and described in its Annex A-F are older textphone types that do not have these signals. The detection logic of V.= 18 tells you how they signal. All of these calls come as audio or telephony calls in ISDN. Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- > -----Original Message----- > From: Barry Dingle [mailto:barry.dingle@bigfoot.com.au] > Sent: Monday, March 01, 2004 3:10 AM > To: Rosen, Brian; Gunnar Hellstrom; Arnoud van Wijk; > Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > Cc: rrroy@att.com; henry.sinnreich@mci.com; paulej@packetizer.com; > gv@trace.wisc.edu; Barry Dingle > Subject: Re: Betr.: [Sipping] ToIP Requirements > > > Hi Brian, > > There are two issues. The old Textphones that must continue to > be supported > and the more recent V.18 Textphones that have in-built > interworking with the > old Textphone protocols (and will revert to the detected protocol). > > A V.18 Textphone detects the type of Textphone with which it is > interworking > by sending out a sequence of modem signals based on the V.8 modem > identification and control sequence plus it listens for modem > signals from > up to 7 Textphone modem protocols. > > Some Textphone require manual intervention to create a modem > signal. In that > case, V.18 has to assume that someone will send some text so it > can detect > the incoming protocol. > > In summary, V.18 Textphones are easily detectable but some older > Textphone > protocols are not. This becomes a more significant issue when > talking about > emergency service. > > BTW - V.18 only works on analog PSTN lines - not on ISDN lines directly. > > Cheers, > Barry DINGLE > Telecommunications Consultant > Project Manager - ACIF Any-to-Any Text Connectivity Options WG > Fellow of the University of Melbourne > barry.dingle@bigfoot.com.au > Mob: +61 (0)41 911 7578 > Fixed: +61 (0)3 9725 3937 > ----- Original Message ----- > From: "Rosen, Brian" > To: "Gunnar Hellstrom" ; "Arnoud van Wijk" > ; ; > > Cc: ; ; > ; ; > Sent: Monday, March 01, 2004 11:16 AM > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > How does V.18 work? Is the "calling identifier" something in (ISDN > presumably) signalling? Or is it a distinctive tone > > pattern? > > > > Brian > > > > > -----Original Message----- > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > Sent: Friday, February 27, 2004 1:45 AM > > > To: Arnoud van Wijk; 'Rosen, Brian'; Gonzalo.Camarillo@ericsson.com= ; > > > sipping@ietf.org > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > henry.sinnreich@mci.com; > > > paulej@packetizer.com; gv@trace.wisc.edu > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > The INCOM group of the European commission made > recommendations that the > > > same emergency number shall be used for all kinds of terminals. > > > It is dangerous to have different prefixes or other tricks > in different > countries. How shall you keep track of that if you are a visitor? > > > > > > From PSTN, it is only the old textphones that cause problems. > > > A calling V.18 sends a very distinct calling identifier that can be > catched by a gateway or > > > an emergency centre and be properly handled. On the SIP side, the > options are even better. > > > > > > I do not mean that all problems are solved by this > statement, but I do > not > > > think that the prefix is the only solution, and I do not > think we shall > > > recommend it in connection to emergency. > > > > > > > > > Gunnar > > > > > > ------------------------------------------- > > > Gunnar Hellstrom > > > Omnitor AB > > > Renathvagen 2 > > > SE 121 37 Johanneshov > > > SWEDEN > > > +46 8 556 002 03 > > > Mob: +46 708 204 288 > > > www.omnitor.se > > > Gunnar.Hellstrom@Omnitor.se > > > -------------------------------------------- > > > > > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org > > > [mailto:sipping-admin@ietf.org]On Behalf Of > > > Arnoud van Wijk > > > Sent: Thursday, February 26, 2004 4:57 PM > > > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > > > Gonzalo.Camarillo@ericsson.com; > > > sipping@ietf.org > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > henry.sinnreich@mci.com; > > > paulej@packetizer.com; gv@trace.wisc.edu > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > Hello Brian, > > > > > > Yes you are right about that the PSTN cannot detect if it is > > > a voice call or > > > TDD/Textphone call. They are both audio. > > > The PSTN would if it can detect it is a textphone call, route > > > it to the text > > > gateway. And transcode the call into T.140 over RTP as > > > decribed in RFC 2793. > > > This is for PSTNs which use IP to interconnect with other > > > PSTNs or with any > > > SIP telephones. So it is for analoge telephony into SIP > > > telephony here. > > > > > > In the ToIP draft: > > > http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-to > > > ip-01.txt > > > A possible solution is a prefix for textphone users before > > > dialling the > > > selected number. > > > It indeed would mean that you dial e.g. 600-112 instead 112 directl= y. > > > Is that bad? > > > I believe it is not. > > > > > > Most textphones have the emergency number pre programmed. And > > > when textphone > > > users have to use a pre-fix for any textphone call, then the > > > same prefix > > > before 112 or 911 will be fine. > > > In the Netherlands, we have for emergency calls 800-112 > > > instead of 112. It > > > works fine, only almost no deaf users call 112, since they > > > are then mostly > > > in a situation where they do not have a textphone nearby! > > > > > > Maybe there are other solutions that allow the PSTN to > detect that the > > > incoming call is a textphone user and acts on it. > > > > > > For example it is possible to create a database where the > > > PSTN can check if > > > the incoming number is registered as a textphone. > > > > > > But using a text gateway to connect PSTN textphones/TDDs to > > > ToIP is still > > > the best solution, even the only solution in my opinion. > > > There should be no attempts to transport the text telephone > > > tones (e.g. > > > Baudot) over the IP voice channel! I believe that will open > > > Pandora's box. > > > > > > I am not a PSTN expert, and we can surely look into this > > > matter to find a > > > solution. Let it be prefix or any other solution that lets the PSTN > > > immediately route the call to the text gateway. > > > > > > What do you PSTN people think? How would you tackle this > > > problem? Your input > > > will be very welcome. > > > > > > Greetz > > > > > > Arnoud > > > > > > Drs. Arnoud A. T. van Wijk > > > Viataal > > > Research & Development > > > Afdeling RDS > > > Theerestraat 42 > > > 5271 GD Sint-Michielsgestel > > > The Netherlands. > > > Mobile: +31651921948 > > > International text telephone: +31735588408 > > > > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: donderdag 26 februari 2004 15:36 > > > To: 'Arnoud van Wijk'; 'Gunnar Hellstrom'; > > > Gonzalo.Camarillo@ericsson.com; > > > sipping@ietf.org > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > henry.sinnreich@mci.com; > > > paulej@packetizer.com; gv@trace.wisc.edu > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > Arnoud > > > > > > I do not believe this can work. A TDD user dials 112 or 911. > > > Today, this > > > will be routed directly to a "selective router" (a TDM > > > switch) which sends > > > the > > > call to the correct Emergency Response Center. You can't > > > insert a gateway, > > > because you don't know that it's a TDD call until it is > > > answered. To make > > > it work, you would have to establish a special PSTN number > > > for emergency > > > TDD, > > > which would route to the gateway, which would then call the > > > ERC. I don't > > > believe that is practical. > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > > > Sent: Thursday, February 26, 2004 9:17 AM > > > > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > > > > Gonzalo.Camarillo@ericsson.com; > > > > sipping@ietf.org > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > henry.sinnreich@mci.com; > > > > paulej@packetizer.com; gv@trace.wisc.edu > > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > > > Hello Brian, > > > > That is also why we need to look at the emergency call system. > > > > This text gateway is only at the PSTN side, thus another > > > > requirement for a > > > > T140/RTP gateway for the PSTN is that when a local > > > emergency number is > > > > dialled (112, or 911 etc). That the gateway must be able to > > > > receive that > > > > call (even dropping existing calls if necessary). Such a call > > > > is easy to > > > > recognize as an emergency call. (PSTN side). > > > > From that gateway on, it is all IP with RFC2793 interactive > > > > text. And then > > > > it is just all existing SIP as if it was from an IP end-point. > > > > > > > > This gives emergency centers an advantage, all calls will be > > > > T.140/RTP, so > > > > integration in their computer systems will be easy instead > > > > being forced to > > > > have analog textphones available for a textphone call. (or a > > > > separate text > > > > telephone emergency center). > > > > > > > > /Arnoud > > > > > > > > Drs. Arnoud A. T. van Wijk > > > > Viataal > > > > Research & Development > > > > Afdeling RDS > > > > Theerestraat 42 > > > > 5271 GD Sint-Michielsgestel > > > > The Netherlands. > > > > Mobile: +31651921948 > > > > International text telephone: +31735588408 > > > > > > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: donderdag 26 februari 2004 15:04 > > > > To: 'Arnoud van Wijk'; 'Gunnar Hellstrom'; > > > > Gonzalo.Camarillo@ericsson.com; > > > > sipping@ietf.org > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > henry.sinnreich@mci.com; > > > > paulej@packetizer.com; gv@trace.wisc.edu > > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > Arnoud > > > > > > > > Generally, you don't want to rely on very many SIP elements > > > > to complete > > > > an emergency call. Present systems accept TDD at all answering > > > > points because they don't know before the calls is answered that = it > > > > is a TDD call. I certainly don't want the user to have to > > > do anything > > > > other than dial his local emergency number, or complete a device > > > > specific key sequence to complete an emergency call, and I don't > > > > want a gateway busy to prevent an emergency call. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl] > > > > > Sent: Thursday, February 26, 2004 6:07 AM > > > > > To: 'Rosen, Brian'; 'Gunnar Hellstrom'; > > > > > Gonzalo.Camarillo@ericsson.com; > > > > > sipping@ietf.org > > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > > henry.sinnreich@mci.com; > > > > > paulej@packetizer.com; gv@trace.wisc.edu > > > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > > > > > > Actually, > > > > > When using the text gateway, there is no need to detect the > > > > > TDD/Analogue > > > > > text telephone tones/signals. That is the job of the > text gateway. > > > > > > > > > > And for the emergency calling. We have to look closely at this = in > > > > > combination with a text gateway. Possible behaviour/action. > > > > > And possible > > > > > action in SIP. > > > > > > > > > > Right now I cannot say what has to happen, I must study the > > > > > emergency calls > > > > > in depth. But as I see it, using the text gateway, all SIP > > > > > originating and > > > > > receiving emergency calls will be possible for any > textphone user. > > > > > > > > > > Cheers > > > > > > > > > > Arnoud > > > > > > > > > > > > > > > Drs. Arnoud A. T. van Wijk > > > > > Viataal > > > > > Research & Development > > > > > Afdeling RDS > > > > > Theerestraat 42 > > > > > 5271 GD Sint-Michielsgestel > > > > > The Netherlands. > > > > > Mobile: +31651921948 > > > > > International text telephone: +31735588408 > > > > > > > > > > -----Original Message----- > > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > > > On Behalf Of > > > > > Rosen, Brian > > > > > Sent: woensdag 25 februari 2004 23:08 > > > > > To: 'Gunnar Hellstrom'; A vWijk; Gonzalo.Camarillo@ericsson.com= ; > > > > > sipping@ietf.org > > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > > henry.sinnreich@mci.com; > > > > > paulej@packetizer.com; gv@trace.wisc.edu > > > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > I'm particularly interested in the last one, emergency calling. > > > > > > > > > > Given that you propose an appropriate SDP indicating > > > > support for text, > > > > > do you think there is anything else we need to do to in SIP > > > > > to make this > > > > > happen? I don't see anything. > > > > > > > > > > I know that the problem of using a legacy TDD device on > > > any kind of > > > > > adapter is as problematic as current TDD; the call will answere= d > > > > > as if it was a voice call, the baudot/whatever tones will be > > > > > detected, > > > > > and the operator will look for text. > > > > > Can't think of any way to make that better. > > > > > > > > > > Do note that language preference headers should be set!!! > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > > > Sent: Wednesday, February 25, 2004 4:54 PM > > > > > > To: A vWijk; Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > > > henry.sinnreich@mci.com; > > > > > > paulej@packetizer.com; gv@trace.wisc.edu > > > > > > Subject: RE: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > > > > > > > > > I think PSTN textphone gateway invocation is one area where > > > > > > we either need > > > > > > protocol extensions, or need agreements on what current > > > > > > mechanisms to use. > > > > > > > > > > > > Another is invocation of various kinds of relay services or > > > > > > translation > > > > > > services. > > > > > > > > > > > > A third is calling emergency services and reach positions > > > > capable of > > > > > > handling the type of communication that the user prefers. > > > > > > > > > > > > > > > > > > > > > > > > Gunnar > > > > > > ------------------------------------------- > > > > > > Gunnar Hellstrom > > > > > > Omnitor AB > > > > > > Renathvagen 2 > > > > > > SE 121 37 Johanneshov > > > > > > SWEDEN > > > > > > +46 8 556 002 03 > > > > > > Mob: +46 708 204 288 > > > > > > www.omnitor.se > > > > > > Gunnar.Hellstrom@Omnitor.se > > > > > > -------------------------------------------- > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: sipping-admin@ietf.org > > > > > > [mailto:sipping-admin@ietf.org]On Behalf Of > > > > > > A vWijk > > > > > > Sent: Tuesday, February 24, 2004 1:22 PM > > > > > > To: Gonzalo.Camarillo@ericsson.com; sipping@ietf.org > > > > > > Cc: rrroy@att.com; barry.dingle@bigfoot.com.au; > > > > > > henry.sinnreich@mci.com; > > > > > > gunnar.hellstrom@omnitor.se; paulej@packetizer.com; > > > > > gv@trace.wisc.edu > > > > > > Subject: Betr.: [Sipping] ToIP Requirements > > > > > > > > > > > > > > > > > > Hello Gonzalo, > > > > > > While there are device requirements in the text. Those > > > > > > requirements and the > > > > > > explanation on the different analogue text telephone systems > > > > > > is included to > > > > > > give the reader an understanding what kind of devices will > > > > > > connect with > > > > > > ToIP. And the need for the text gateways. And what the > > > > > > different behaviour > > > > > > can/may be compared to end to end IP devices. > > > > > > The most important part will be the ToIP framwork and the > > > > > > text gateways and > > > > > > how such gateways will be used and work with the ToIP > framework. > > > > > > > > > > > > There is a ToIP framework where a terminal uses streaming > > > > > > text as defined in > > > > > > RFC2793 to connect with any other Interactive > > > > > > texting/real-time streaming > > > > > > text device. > > > > > > This can be end-to-end IP, and a direct T140/RTP stream is > > > > > > established with > > > > > > SIP. But in other cases, a text gateway must be used to allow > > > > > > T.140/RTP to > > > > > > connect with a non IP text telephony device. > > > > > > It can be an analogue text telephone (TDD/TTY) that uses a > > > > > > text gateway to > > > > > > be able to understand RFC2793 text. (PSTN-IP) > > > > > > It can be a mobile phone running GPRS that uses the text > > > > gateway to > > > > > > understand RFC2793 text. (this exist right NOW using SIP! And > > > > > > those gateways > > > > > > will be used in mobile networks this year!) > > > > > > Or a mobile text telephone using CTM via the text gateway to > > > > > > communicate > > > > > > with RFC2793 text. > > > > > > Or even one analogue text telephone connecting to another > > > > > > analogue text > > > > > > telephone in a different country, and the PSTN's use IP to > > > > > > connect the call. > > > > > > > > > > > > The question is for example, how do we use that gateway from > > > > > > the IP side? Is > > > > > > it invisible for the IP side? Or do we need special > > > > > > extensions in SIP to > > > > > > that the IP terminal knows it is communicating with the > > > > > > end-device through > > > > > > the text gateway? > > > > > > There may be a slightly different call setup flow when a text > > > > > > gateway is > > > > > > included. > > > > > > Or additional SIP messages indicating gateway activity. When > > > > > > you connect for > > > > > > example to an analogue text telephone with an RFC2793 capable > > > > > > IP terminal > > > > > > the capabilities will be less then IP to IP terminal directly > > > > > > (different > > > > > > transmission speeds, half/full duplex etc). > > > > > > Or what to do with emergency calls that are in RFC 2793 > > > text only? > > > > > > > > > > > > That are requirements that will be defined and worked out in > > > > > > this draft. > > > > > > Also, we want to make everybody in SIP and SIPPING aware > > > > > > about those text > > > > > > gateways. So that complicated matters like how to send > > > > analogue text > > > > > > telephone text through a PSTN and connect with a SIP > > > > > > telephone using RFC2793 > > > > > > interactive texting. When using the text gateway, there is > > > > > > then no need for > > > > > > RFC 2833 events at the PSTN for text telephones. > > > > > > > > > > > > So, yes. I believe that this should be in the SIPPING WG. And > > > > > > it will fit in > > > > > > the charter - support for hearing-/speech-impaired calling. > > > > > > > > > > > > greetz > > > > > > > > > > > > Arnoud > > > > > > > > > > > > > > > > > > > > > > > > Drs. Arnoud A. T. van Wijk > > > > > > Viataal > > > > > > Research & Development > > > > > > Afdeling RDS > > > > > > Theerestraat 42 > > > > > > 5271 GD Sint-Michielsgestel > > > > > > The Netherlands. > > > > > > Mobile: +31651921948 > > > > > > International text telephone: +31735588408 > > > > > > > > > > > > >>> Gonzalo Camarillo > > > > > > 24-02-04 10:21 >>> > > > > > > Hello, > > > > > > > > > > > > the draft below provides a set of requirements for real-time > > > > > > conversations using SIP. > > > > > > http://www.ietf.org/internet-drafts/draft-manyfolks-sipping-t= o > > > > > ip-01.txt > > > > > > > > > > Nevertheless, I have found a lot of device requirements in > > > > > the text, but > > > > > I fail to understand which particular protocol requirements > > > > we need to > > > > > fulfill with new protocol extensions. > > > > > > > > > > While SIPPING is the right place to handle requirements > > > > that will lead > > > > > to new SIP protocol extensions, SIPPING may not be the > > > > right place to > > > > > deal with device requirements (e.g., text phones MUST have a > > > > > display of > > > > > at least 100 characters). > > > > > > > > > > Thanks, > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > This communication is confidential and intended solely for > > > > > the addressee(s). > > > > > Any unauthorized review, use, disclosure or distribution is > > > > > prohibited. If > > > > > you believe this message has been sent to you in error, > > > > > please notify the > > > > > sender by replying to this transmission and delete the > > > > message without > > > > > disclosing it. Thank you. > > > > > > > > > > E-mail including attachments is susceptible to data corruption, > > > > > interruption, unauthorized amendment, tampering and viruses, > > > > > and we only > > > > > send and receive e-mails on the basis that we are not liable > > > > > for any such > > > > > corruption, interception, amendment, tampering or viruses or an= y > > > > > consequences thereof. > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list > > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > This list is for NEW development of the application of SIP > > > > > Use sip-implementors@cs.columbia.edu for questions on current s= ip > > > > > 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 s= ip > > > > > 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 s= ip > > > > > 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 s= ip > > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sippin= g > > > This list is for NEW development of the 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 Apr 21 19:19:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29392 for ; Wed, 21 Apr 2004 19:19: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 1BGQbk-0000Y5-7N for sipping-archive@odin.ietf.org; Wed, 21 Apr 2004 18:54:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LMsK6k002093 for sipping-archive@odin.ietf.org; Wed, 21 Apr 2004 18:54:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQGx-0005qJ-1h for sipping-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 18:32: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 SAA25398 for ; Wed, 21 Apr 2004 18:32: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 1BGQGt-0001gz-Nd for sipping-web-archive@ietf.org; Wed, 21 Apr 2004 18:32:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQFN-0001Ct-00 for sipping-web-archive@ietf.org; Wed, 21 Apr 2004 18:31:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGQBI-0000Gf-00 for sipping-web-archive@ietf.org; Wed, 21 Apr 2004 18:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPqG-0003G6-MT; Wed, 21 Apr 2004 18:05:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOtX-0003Z2-Ar for sipping@optimus.ietf.org; Wed, 21 Apr 2004 17:04: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 RAA14279 for ; Wed, 21 Apr 2004 17:04: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 1BGOtV-0005Ot-3N for sipping@ietf.org; Wed, 21 Apr 2004 17:04:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGOsU-00058Q-00 for sipping@ietf.org; Wed, 21 Apr 2004 17:03:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BGOrb-0004oJ-00; Wed, 21 Apr 2004 17:02:35 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2004 14:01:31 -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 i3LL226L014439; Wed, 21 Apr 2004 17:02:03 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHT76259; Wed, 21 Apr 2004 17:02:02 -0400 (EDT) Message-ID: <4086E14A.6080403@cisco.com> Date: Wed, 21 Apr 2004 17:02: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: Miguel Garcia CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo References: <406DF1EC.4050400@cisco.com> <4085401C.2000008@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] 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 I changed the subject of this because it is generalized. See below for details. The general question is: Is there a need for some sort of draft (beyond what is already in 3261) explaining how body parts are to be arranged and tagged so that they will be found and processed in an interoperable way? I think there is. I have spent time working on sip stack support for managing body parts, and I came up with all kinds of questions about what is valid and what is not. Paul Miguel Garcia wrote: > Hi Paul: > > Thanks for your comments. Answers inline. > > ext Paul Kyzivat wrote: > >> Miguel, >> >> In general the approach in the draft seems reasonable to me. >> >> I see one area of ambiguity, having to do with how multipart bodies >> are handled. The draft says to remove the list and include everything >> else. But even your example doesn't do that - it also removes the >> multipart/mixed wrapper. Of course in this particular example that >> makes perfect sense, but it goes beyond what the draft says to do. > > > We start from the the fact that there will be as a minimum, two bodies, > the list, and the actual payload. There might be more bodies, such as > multiple payloads, S/MIME signatures, etc. > > I guess the algorithm should be: > > - If there is any kind of security body for the exploder (e.g., signed > with the public key of the exploder), then remove that body. > > - Remove the list itself (in a typical use case, unless an extension > says the oposite; I am referring to Ben's suggestion to allow it). > > - If there is only one body left, then remove the multipart/mixed wrapper. > > - Send the remaining stuff. This seems like the ad hoc approach. It will probably work in a lot of cases. In the absence of more general rules this is probably a pragmatic approach to take. But I think there is a more general problem - not specific to message exploders, or exploders, or message - that applies to management of body parts in general. Part of it is just: - in a hierarchy of mime entities, how do I identify the body parts that interest me? And the flip side of that is: - How do I arrange the body parts that I need to convey into a hierarchy of mime entities so that the recipient will find and process them correctly? This is then further complicated by servers in the signaling path that are permitted to mess with body parts. (That currently is only B2BUAs, but with the m2m and m2e discussions it may eventually include proxies.) For them there are the following additional questions: - Should I (and if so how) modify the mime entity hierarchy to remove body parts that I have processed? - How should I modify the mime entity hierarchy to add additional body parts that are to be processed further downstream, so that the recipient will process them correctly? >> There are more complex cases: >> >> - for security there could be signed body parts. >> >> - The signature could be on the multipart containing the message >> and list. It would have to be removed. >> >> - The signature could be on just the message. Presumably >> it should remain. > > > > > I agree. > >> >> - There could be other body parts referenced by cid: urls in >> other headers in the message. > > > Yes, they should remain. > >> >> I think there needs to be a more prescriptive way of defining what >> gets passed on in the exploded messages. This is really just a >> manifestation of a more general problem of how to decide how different >> body parts should be processed. It potentially exists in a normal, >> unexploded, MESSAGE. >> >> I think at least part of the answer lies with Content-Disposition. I >> think there should be clarity about the content-disposition should be >> for the body part(s) that MESSAGE interprets as message content. >> Probably "render" (which is default for sip) would be an appropriate >> content-disposition for message content. > > > Agree so far. It may happen that some of this stuff is generic enough > (not MESSAGE specific). Yes, very much so. >> Also, I think there should be some clarity about what the >> content-disposition should be for various kinds of multipart >> containers when used in the various ways they may be used in sip. I'm >> not quite sure what the answer is here. >> >> The list itself is of course referenced from a cid: url. It is the url >> and its placement that determines how the corresponding body part >> should be processed. For these, the content-disposition should be some >> value that doesn't imply some other sort of processing. I think it >> can't be any of "session", "render", "alert", or "icon". Maybe it >> could be "attachment". > > > I will be happy to have a very clear deterministic way to find out what > to pass and what to keep to the other side of the exploder, base on > presumabley the content-disposition. Let's see if I can come up with > something. I'm interested in this. Do you think this is suitable as a new work item? (Probably for sipping at first.) 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 Apr 22 09:03:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24357 for ; Thu, 22 Apr 2004 09:03: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 1BGdpH-0005pY-6B for sipping-archive@odin.ietf.org; Thu, 22 Apr 2004 09:01:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MD1Bbn022412 for sipping-archive@odin.ietf.org; Thu, 22 Apr 2004 09:01:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdhL-000388-TJ for sipping-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 08:53: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 IAA23638 for ; Thu, 22 Apr 2004 08:52: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 1BGdhE-00045g-QO for sipping-web-archive@ietf.org; Thu, 22 Apr 2004 08:52:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdgF-0003pl-00 for sipping-web-archive@ietf.org; Thu, 22 Apr 2004 08:51:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGdfK-0003bh-00 for sipping-web-archive@ietf.org; Thu, 22 Apr 2004 08:50:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdWo-0007bc-Dg; Thu, 22 Apr 2004 08:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdPc-0005E1-QD for sipping@optimus.ietf.org; Thu, 22 Apr 2004 08:34: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 IAA22198 for ; Thu, 22 Apr 2004 08:34: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 1BGdPV-0006o6-NG for sipping@ietf.org; Thu, 22 Apr 2004 08:34:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdNH-0006Ip-00 for sipping@ietf.org; Thu, 22 Apr 2004 08:32:16 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1BGdM2-0005gK-00; Thu, 22 Apr 2004 08:30:58 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i3MCULfX001167; Thu, 22 Apr 2004 07:30:21 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.44]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id J170J6QL; Thu, 22 Apr 2004 07:30:01 -0500 Message-ID: <4087BADB.70004@ericsson.com> Date: Thu, 22 Apr 2004 15:30:19 +0300 X-Sybari-Trust: d9940463 2c4885b5 0a80fa4f 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 , SIMPLE mailing list , SIPPING mailing list References: <406DF1EC.4050400@cisco.com> <4085401C.2000008@nokia.com> <4086E14A.6080403@cisco.com> In-Reply-To: <4086E14A.6080403@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] 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 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. What sort of things do you have in mind, besides the ones I mentioned? Thanks, Gonzalo Paul Kyzivat wrote: > I changed the subject of this because it is generalized. > > See below for details. The general question is: > > Is there a need for some sort of draft (beyond what is already in 3261) > explaining how body parts are to be arranged and tagged so that they > will be found and processed in an interoperable way? > > I think there is. I have spent time working on sip stack support for > managing body parts, and I came up with all kinds of questions about > what is valid and what is not. > > Paul > > Miguel Garcia wrote: > >> Hi Paul: >> >> Thanks for your comments. Answers inline. >> >> ext Paul Kyzivat wrote: >> >>> Miguel, >>> >>> In general the approach in the draft seems reasonable to me. >>> >>> I see one area of ambiguity, having to do with how multipart bodies >>> are handled. The draft says to remove the list and include everything >>> else. But even your example doesn't do that - it also removes the >>> multipart/mixed wrapper. Of course in this particular example that >>> makes perfect sense, but it goes beyond what the draft says to do. >> >> >> >> We start from the the fact that there will be as a minimum, two >> bodies, the list, and the actual payload. There might be more bodies, >> such as multiple payloads, S/MIME signatures, etc. >> >> I guess the algorithm should be: >> >> - If there is any kind of security body for the exploder (e.g., signed >> with the public key of the exploder), then remove that body. >> >> - Remove the list itself (in a typical use case, unless an extension >> says the oposite; I am referring to Ben's suggestion to allow it). >> >> - If there is only one body left, then remove the multipart/mixed >> wrapper. >> >> - Send the remaining stuff. > > > This seems like the ad hoc approach. It will probably work in a lot of > cases. In the absence of more general rules this is probably a pragmatic > approach to take. > > But I think there is a more general problem - not specific to message > exploders, or exploders, or message - that applies to management of body > parts in general. > > Part of it is just: > - in a hierarchy of mime entities, how do I identify the body parts that > interest me? > > And the flip side of that is: > - How do I arrange the body parts that I need to convey into a hierarchy > of mime entities so that the recipient will find and process them > correctly? > > This is then further complicated by servers in the signaling path that > are permitted to mess with body parts. (That currently is only B2BUAs, > but with the m2m and m2e discussions it may eventually include proxies.) > For them there are the following additional questions: > > - Should I (and if so how) modify the mime entity hierarchy to remove > body parts that I have processed? > > - How should I modify the mime entity hierarchy to add additional body > parts that are to be processed further downstream, so that the recipient > will process them correctly? > >>> There are more complex cases: >>> >>> - for security there could be signed body parts. >>> >>> - The signature could be on the multipart containing the message >>> and list. It would have to be removed. >>> >>> - The signature could be on just the message. Presumably >>> it should remain. >> >> >> > >> >> I agree. >> >>> >>> - There could be other body parts referenced by cid: urls in >>> other headers in the message. >> >> >> >> Yes, they should remain. >> >>> >>> I think there needs to be a more prescriptive way of defining what >>> gets passed on in the exploded messages. This is really just a >>> manifestation of a more general problem of how to decide how >>> different body parts should be processed. It potentially exists in a >>> normal, unexploded, MESSAGE. >>> >>> I think at least part of the answer lies with Content-Disposition. I >>> think there should be clarity about the content-disposition should be >>> for the body part(s) that MESSAGE interprets as message content. >>> Probably "render" (which is default for sip) would be an appropriate >>> content-disposition for message content. >> >> >> >> Agree so far. It may happen that some of this stuff is generic enough >> (not MESSAGE specific). > > > Yes, very much so. > >>> Also, I think there should be some clarity about what the >>> content-disposition should be for various kinds of multipart >>> containers when used in the various ways they may be used in sip. I'm >>> not quite sure what the answer is here. >>> >>> The list itself is of course referenced from a cid: url. It is the >>> url and its placement that determines how the corresponding body part >>> should be processed. For these, the content-disposition should be >>> some value that doesn't imply some other sort of processing. I think >>> it can't be any of "session", "render", "alert", or "icon". Maybe it >>> could be "attachment". >> >> >> >> I will be happy to have a very clear deterministic way to find out >> what to pass and what to keep to the other side of the exploder, base >> on presumabley the content-disposition. Let's see if I can come up >> with something. > > > I'm interested in this. Do you think this is suitable as a new work > item? (Probably for sipping at first.) > > 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 Thu Apr 22 10:20:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29653 for ; Thu, 22 Apr 2004 10:20: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 1BGemN-0000Kp-LD for sipping-archive@odin.ietf.org; Thu, 22 Apr 2004 10:02:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ME2FK2001282 for sipping-archive@odin.ietf.org; Thu, 22 Apr 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 1BGefL-0005WM-T9 for sipping-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 09:55: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 JAA27052 for ; Thu, 22 Apr 2004 09:54:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGefE-0004TB-8c for sipping-web-archive@ietf.org; Thu, 22 Apr 2004 09:54:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGeeF-0004CE-00 for sipping-web-archive@ietf.org; Thu, 22 Apr 2004 09:53:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGedB-0003iz-00 for sipping-web-archive@ietf.org; Thu, 22 Apr 2004 09:52:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGeL3-00086r-57; Thu, 22 Apr 2004 09:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGINL-0004OU-8b for sipping@optimus.ietf.org; Wed, 21 Apr 2004 10:06: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 KAA22517 for ; Wed, 21 Apr 2004 10:06: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 1BGINJ-0004LO-1V for sipping@ietf.org; Wed, 21 Apr 2004 10:06:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGIMH-0004A3-00 for sipping@ietf.org; Wed, 21 Apr 2004 10:05:49 -0400 Received: from sunfish.brooktrout.com ([63.68.86.8] helo=sunfish.netacc.com) by ietf-mx with esmtp (Exim 4.12) id 1BGILI-0003mt-00 for sipping@ietf.org; Wed, 21 Apr 2004 10:04:48 -0400 Received: from pobox2.netacc.com (pobox2.netacc.com [63.68.86.135]) by sunfish.netacc.com (8.11.2/8.11.2) with ESMTP id i3LD0l226869; Wed, 21 Apr 2004 09:00:47 -0400 Received: from puppy.office.snowshore.com (host253 [63.68.87.253]) by pobox2.netacc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HX10QHFW; Wed, 21 Apr 2004 10:01:32 -0400 Cc: sipping@ietf.org To: Dean Willis Subject: Re: [Sipping] Re: Service name stuff in natann draft References: <4085ACCD.6010204@softarmor.com> Message-ID: From: Andy Spitzer Organization: Brooktrout Technologies Content-Type: text/plain; format=flowed; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Wed, 21 Apr 2004 10:01:07 -0400 In-Reply-To: <4085ACCD.6010204@softarmor.com> User-Agent: Opera7.21/Linux M2 build 480 Content-Transfer-Encoding: 8bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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: 8bit Content-Transfer-Encoding: 8bit Dean, Yep. But netann pre-dates GRUU. --Andy Spitzer On Tue, 20 Apr 2004 18:05:49 -0500, Dean Willis wrote: > Andy Spitzer wrote: > >> This is why we put the conference id in the user part...so that each >> conference mix can be assigned a unique name (user part), and calls for >> that "user" find the correct MS that hosts that particular mix. Using >> the "normal" user@domain approach seemed like the right way to pin >> users (aka conference ids) to endpoints. > > Zork! It's a GRUU! > > -- > Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Apr 22 11:09: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 LAA04037 for ; Thu, 22 Apr 2004 11:09: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 1BGffc-0005Qy-Pi for sipping-archive@odin.ietf.org; Thu, 22 Apr 2004 10:59:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MExKN4020881 for sipping-archive@odin.ietf.org; Thu, 22 Apr 2004 10:59:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfSq-0002XZ-2V for sipping-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 10:46:08 -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 KAA01547 for ; Thu, 22 Apr 2004 10:46:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfSi-0002c2-3c for sipping-web-archive@ietf.org; Thu, 22 Apr 2004 10:46:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfRm-0002Mk-00 for sipping-web-archive@ietf.org; Thu, 22 Apr 2004 10:45:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGfRM-00027s-00 for sipping-web-archive@ietf.org; Thu, 22 Apr 2004 10:44:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfAO-0005Ff-Hm; Thu, 22 Apr 2004 10:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGf1q-0000w4-Fx for sipping@optimus.ietf.org; Thu, 22 Apr 2004 10:18: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 KAA29495 for ; Thu, 22 Apr 2004 10:18: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 1BGf1i-0002rF-DQ for sipping@ietf.org; Thu, 22 Apr 2004 10:18:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGf0s-0002bO-00 for sipping@ietf.org; Thu, 22 Apr 2004 10:17:15 -0400 Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BGezy-00029s-00 for sipping@ietf.org; Thu, 22 Apr 2004 10:16:18 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i3MEFb3w016399 for ; Thu, 22 Apr 2004 10:15:50 -0400 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh0i.attrh.att.com (6.5.032) id 40703259002DF0C0; Thu, 22 Apr 2004 10:11:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.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: Service name stuff in natann draft Date: Thu, 22 Apr 2004 10:15:50 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A06DC1AD2@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Sipping] Re: Service name stuff in natann draft Thread-Index: AcQocR8zKEs7U+JySjGI81JbjKF3bwAArdWg From: "Roy, Radhika R, ALABS" To: "Andy Spitzer" , "Dean Willis" Cc: 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=none autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QW5keSBhbmQgRGVhbjoNCg0KSWYgc28sIGxldCB1cyBtYWtlIGl0IGNsZWFyLg0KDQpEZWFuOiBB IGdyZWF0IGFwcHJlY2lhdGlvbiBmb3IgeW91ciBoZWxwIHVzaW5nIHRoaXMgbWFnaWMgd29yZCAi R1JVVSIgYmVjYXVzZSBpdCBoYXMgc29sdmVkIGFuIGltcG9ydGFudCBwdXp6bGUgd2hhdCBBbmR5 IGhhcyBiZWVuIHRyeWluZyB0byBleHBsYWluIHdpdGggc28gbWFueSBlbWFpbHMuDQoNCkJlc3Qg cmVnYXJkcywNClJhZGhpa2ENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNp cHBpbmctYWRtaW5AaWV0Zi5vcmcgW21haWx0bzpzaXBwaW5nLWFkbWluQGlldGYub3JnXU9uIEJl aGFsZiBPZg0KQW5keSBTcGl0emVyDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDIxLCAyMDA0IDEw OjAxIEFNDQpUbzogRGVhbiBXaWxsaXMNCkNjOiBzaXBwaW5nQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW1NpcHBpbmddIFJlOiBTZXJ2aWNlIG5hbWUgc3R1ZmYgaW4gbmF0YW5uIGRyYWZ0DQoNCg0K RGVhbiwNCg0KWWVwLiAgQnV0IG5ldGFubiBwcmUtZGF0ZXMgR1JVVS4NCg0KLS1BbmR5IFNwaXR6 ZXINCg0KT24gVHVlLCAyMCBBcHIgMjAwNCAxODowNTo0OSAtMDUwMCwgRGVhbiBXaWxsaXMgDQo8 ZGVhbi53aWxsaXNAc29mdGFybW9yLmNvbT4gd3JvdGU6DQoNCj4gQW5keSBTcGl0emVyIHdyb3Rl Og0KPg0KPj4gVGhpcyBpcyB3aHkgd2UgcHV0IHRoZSBjb25mZXJlbmNlIGlkIGluIHRoZSB1c2Vy IHBhcnQuLi5zbyB0aGF0IGVhY2ggDQo+PiBjb25mZXJlbmNlIG1peCBjYW4gYmUgYXNzaWduZWQg YSB1bmlxdWUgbmFtZSAodXNlciBwYXJ0KSwgYW5kIGNhbGxzIGZvciANCj4+IHRoYXQgInVzZXIi IGZpbmQgdGhlIGNvcnJlY3QgTVMgdGhhdCBob3N0cyB0aGF0IHBhcnRpY3VsYXIgbWl4LiAgVXNp bmcgDQo+PiB0aGUgIm5vcm1hbCIgdXNlckBkb21haW4gYXBwcm9hY2ggc2VlbWVkIGxpa2UgdGhl IHJpZ2h0IHdheSB0byBwaW4gDQo+PiB1c2VycyAoYWthIGNvbmZlcmVuY2UgaWRzKSB0byBlbmRw b2ludHMuDQo+DQo+IFpvcmshIEl0J3MgYSBHUlVVIQ0KPg0KPiAtLQ0KPiBEZWFuDQoNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU2lwcGluZyBt YWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcHBp bmcNClRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBhcHBsaWNhdGlvbiBv ZiBTSVANClVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25z IG9uIGN1cnJlbnQgc2lwDQpVc2Ugc2lwQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9m IGNvcmUgU0lQDQo= _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 22 11:42: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 LAA06327 for ; Thu, 22 Apr 2004 11:42: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 1BGgE5-0000fj-AP for sipping-archive@odin.ietf.org; Thu, 22 Apr 2004 11:34:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MFYv4e002579 for sipping-archive@odin.ietf.org; Thu, 22 Apr 2004 11:34:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGg5b-0006KS-Rj for sipping-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 11:26: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 LAA05094 for ; Thu, 22 Apr 2004 11:26: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 1BGg5Z-0005tX-0e for sipping-web-archive@ietf.org; Thu, 22 Apr 2004 11:26:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGg4d-0005c0-00 for sipping-web-archive@ietf.org; Thu, 22 Apr 2004 11:25:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGg3t-0005Kp-00 for sipping-web-archive@ietf.org; Thu, 22 Apr 2004 11:24:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfnE-0007kx-8A; Thu, 22 Apr 2004 11:07:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfbe-0004PN-Bi for sipping@optimus.ietf.org; Thu, 22 Apr 2004 10:55: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 KAA02181 for ; Thu, 22 Apr 2004 10:55: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 1BGfbW-00056f-47 for sipping@ietf.org; Thu, 22 Apr 2004 10:55:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfak-0004r2-00 for sipping@ietf.org; Thu, 22 Apr 2004 10:54:19 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BGfa5-0004Xc-00; Thu, 22 Apr 2004 10:53:38 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2004 07:53:14 -0700 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 i3MEr6W9024399; Thu, 22 Apr 2004 07:53:07 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHU25730; Thu, 22 Apr 2004 10:53:05 -0400 (EDT) Message-ID: <4087DC51.2050508@cisco.com> Date: Thu, 22 Apr 2004 10:53: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: Gonzalo Camarillo CC: Miguel Garcia , SIMPLE mailing list , SIPPING mailing list References: <406DF1EC.4050400@cisco.com> <4085401C.2000008@nokia.com> <4086E14A.6080403@cisco.com> <4087BADB.70004@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] 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 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 Apr 22 18:06: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 SAA05685 for ; Thu, 22 Apr 2004 18:06: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 1BGlyG-0008F4-Pg for sipping-archive@odin.ietf.org; Thu, 22 Apr 2004 17:43:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MLh0ME031678 for sipping-archive@odin.ietf.org; Thu, 22 Apr 2004 17:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlZV-000805-Hm for sipping-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 17:17: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 RAA01551 for ; Thu, 22 Apr 2004 17:17: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 1BGlZR-0007Qr-Be for sipping-web-archive@ietf.org; Thu, 22 Apr 2004 17:17:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlYZ-0007BD-00 for sipping-web-archive@ietf.org; Thu, 22 Apr 2004 17:16:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGlXx-0006v0-00 for sipping-web-archive@ietf.org; Thu, 22 Apr 2004 17:15:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkbU-0005pl-9d; Thu, 22 Apr 2004 16:15:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkG8-0004vI-Ir for sipping@optimus.ietf.org; Thu, 22 Apr 2004 15:53: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 PAA24044 for ; Thu, 22 Apr 2004 15:53: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 1BGkG5-0004lz-0K for sipping@ietf.org; Thu, 22 Apr 2004 15:53:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGkFN-0004V2-00 for sipping@ietf.org; Thu, 22 Apr 2004 15:52:33 -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 1BGkEU-0003ur-00; Thu, 22 Apr 2004 15:51:38 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2004 12:01:56 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3MJp8Su019862; Thu, 22 Apr 2004 12:51:08 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA20166; Thu, 22 Apr 2004 12:51:06 -0700 (PDT) Message-Id: <4.3.2.7.2.20040422144516.02607ba8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Apr 2004 14:51:23 -0500 To: Hisham Khartabil , Rohan Mahy , Dean Willis From: "James M. Polk" Cc: sipping@ietf.org, sip@ietf.org In-Reply-To: <200404221531.LAA05708@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sipping] Re: 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.0 required=5.0 tests=AWL autolearn=no version=2.60 What happened to time for Emergency and E2M Security? In Seoul, these were mentioned as two of the prevailing topic areas for the interim (along with Session Policy and Exploders). At 11:31 AM 4/22/2004 -0400, Hisham Khartabil wrote: >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. > > > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Apr 23 05:48:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24992 for ; Fri, 23 Apr 2004 05:48: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 1BGxHV-0006sx-QR for sipping-archive@odin.ietf.org; Fri, 23 Apr 2004 05:47:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N9lbk5026467 for sipping-archive@odin.ietf.org; Fri, 23 Apr 2004 05:47:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGx64-00049G-IY for sipping-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 05:35: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 FAA24623 for ; Fri, 23 Apr 2004 05:35: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 1BGx5z-0006Wo-72 for sipping-web-archive@ietf.org; Fri, 23 Apr 2004 05:35:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGx50-0006Gc-00 for sipping-web-archive@ietf.org; Fri, 23 Apr 2004 05:34:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGx49-00060p-00 for sipping-web-archive@ietf.org; Fri, 23 Apr 2004 05:33:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwxb-0001zw-8s; Fri, 23 Apr 2004 05:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwtT-0008V2-MV for sipping@optimus.ietf.org; Fri, 23 Apr 2004 05:22: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 FAA24183 for ; Fri, 23 Apr 2004 05:22: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 1BGwtO-0003Bn-3f for sipping@ietf.org; Fri, 23 Apr 2004 05:22:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGwsP-0002w9-00 for sipping@ietf.org; Fri, 23 Apr 2004 05:21:42 -0400 Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BGwrQ-0002RW-00 for sipping@ietf.org; Fri, 23 Apr 2004 05:20:41 -0400 Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <20KSXN61>; Fri, 23 Apr 2004 10:20:05 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803E52B00@baker.datcon.co.uk> From: "Paul D.Smith" To: SIPPING WG Date: Fri, 23 Apr 2004 10:20:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] FW: I-D ACTION:draft-smith-sip-auth-examples-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Please note that I am aware that the name of this draft, and the indicated WG, names the "SIP WG". After discussion with the WG chairs, this draft is offered to the "Sipping WG". Later version of this draft will reflect the Sipping WG. Paul DS. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 22 April 2004 20:39 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-smith-sip-auth-examples-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Digest Authentication Examples for Session Initiation Protocol (SIP) Author(s) : P. Smith, I. Clarkson Filename : draft-smith-sip-auth-examples-00.txt Pages : 29 Date : 2004-4-22 RFC3261 [2] recommends that SIP requests be authenticated using HTTP Digest authentication as defined in RFC2617 [3], and many vendors have successfully added this function to their products. However implementation bugs are still being observed both at interoperability events and in the field. This document provides worked examples of Digest authentication usage in SIP. It is intended to help new SIP implementers, and to provide a common set of test authentication examples against which an implementation may be checked. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-smith-sip-auth-examples-00.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-smith-sip-auth-examples-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-smith-sip-auth-examples-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Apr 26 18:07:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28006 for ; Mon, 26 Apr 2004 18:07:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEDe-0003wa-2Q for sipping-archive@odin.ietf.org; Mon, 26 Apr 2004 18:04:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QM4s0Z015158 for sipping-archive@odin.ietf.org; Mon, 26 Apr 2004 18:04:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIE2X-00088H-4J for sipping-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:53: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 RAA26549 for ; Mon, 26 Apr 2004 17:53: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 1BIE2U-00005B-IO for sipping-web-archive@ietf.org; Mon, 26 Apr 2004 17:53:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIE1b-00002N-00 for sipping-web-archive@ietf.org; Mon, 26 Apr 2004 17:52:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIE1K-0007mS-00 for sipping-web-archive@ietf.org; Mon, 26 Apr 2004 17:52:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDtX-00065l-UX; Mon, 26 Apr 2004 17:44:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDbf-0001dv-GB for sipping@optimus.ietf.org; Mon, 26 Apr 2004 17:25: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 RAA24664 for ; Mon, 26 Apr 2004 17:25: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 1BIDbd-0005h8-5J for sipping@ietf.org; Mon, 26 Apr 2004 17:25:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDaB-0005Od-00 for sipping@ietf.org; Mon, 26 Apr 2004 17:24:08 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 1BIDY9-00051M-00; Mon, 26 Apr 2004 17:22:01 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i3QLLMSt004289; Mon, 26 Apr 2004 21:21:22 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Apr 2004 17:21:22 -0400 Message-ID: <4F29BE4689992A4B994A440C3EC924DB012D5450@stntexch01.cis.neustar.com> From: "Yu, James" To: "'Deepak.Pant@utstar.com'" Cc: sipping@ietf.org, iptel@ietf.org Date: Mon, 26 Apr 2004 17:21:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] RE: Question about draft-yu-tel-url-08.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.6 required=5.0 tests=AWL,BIZ_TLD autolearn=no version=2.60 Deepak, Sorry that I saw your questions just now. Please see responses below. James -----Original Message----- From: Deepak.Pant@utstar.com [mailto:Deepak.Pant@utstar.com] Sent: Friday, March 19, 2004 8:53 AM To: sipping@ietf.org; iptel@ietf.org; james.yu@neustar.biz Subject: Question about draft-yu-tel-url-08.txt I have the following questions about conveying carrier identitification code in SIP. On the ISUP side we get three information 1. Type of network identification 2. Network identification plan(3 digits or 4 digits) 3. Digits 1-3 or 1-4 Q1. The draft draft-yu-tel-url-08.txt provides a mechanism to convey the digit information on the sip network. However how do we convey the type of network identification information on the SIP network. [YU] I guess that you were referring to the carrier selection info. parameter. I'm working with other co-authors to propose tel URI parameters such as the dail around indicator (dai) that would indicate the type of cic. Q2. On a UAS receiving an INVITE message with cic=+11234 or cic=1234, what is the difference between the two cic information. Does this mean something different needs to be conveyed on the ISUP side. [YU] If the cic does not begin with "+" it should have a "cic-content=+1" if cic=1234. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 28 10:45:47 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19669 for ; Wed, 28 Apr 2004 10:45:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqG3-0003KF-EG for sipping-archive@odin.ietf.org; Wed, 28 Apr 2004 10:41:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SEftDx012783 for sipping-archive@odin.ietf.org; Wed, 28 Apr 2004 10:41:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqAp-0001RP-Nn for sipping-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 10:36: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 KAA18362 for ; Wed, 28 Apr 2004 10:36: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 1BIqAQ-0002EA-2f for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 10:36:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIq2s-0000nJ-00 for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 10:28:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIq2K-0000hx-00 for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 10:27:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIoyw-0003sX-S6; Wed, 28 Apr 2004 09:20:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIon8-0000aU-6a for sipping@optimus.ietf.org; Wed, 28 Apr 2004 09:07:58 -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 JAA13515 for ; Wed, 28 Apr 2004 09:07: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 1BIon6-0002lx-9k for sipping@ietf.org; Wed, 28 Apr 2004 09:07:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIomH-0002iQ-00 for sipping@ietf.org; Wed, 28 Apr 2004 09:07:06 -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 1BIolO-0002dJ-00 for sipping@ietf.org; Wed, 28 Apr 2004 09:06:10 -0400 Received: from softarmor.com (port-213-160-6-4.reverse.qsc.de [213.160.6.4]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i3SD71u4002555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Apr 2004 08:07:03 -0500 Message-ID: <408FAC28.3010005@softarmor.com> Date: Wed, 28 Apr 2004 08:05:44 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat , sipping@ietf.org References: <0C1353ABB1DEB74DB067ADFF749C4EEF029E151D@esebe004.ntc.nokia.com > <408E841B.70900@softarmor.com> <408E9687.2090008@cisco.com> In-Reply-To: <408E9687.2090008@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Application identification with callee caps/caller preferences (Was SIP) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Moving to SIPPING, because that's where this belongs. Following up on a previous thread: Paul Kyzivat wrote: > Dean Willis wrote >> Of course, I'm still deeply confused between: >> 1) preference/capability negotiation enabled by offer/answer >> 2) preference/capability negotiation enabled by callee-caps/caller-pref. > > Forking and offer/answer provide a partial solution. But offer/answer > doesn't give you a way to say you don't want the call unless your > offered media are accepted. At least not an easy way. Conceivably some > new extension to preconditions could be made to handle this kind of > thing. Lacking that you run the risk of having an unsuitable device > answer, even if there is a suitable device present. > > Callerprefs gives you an increased likelihood that you will end up with > a suitable device. The above is a "good start". One of the challenges I'm faced with regularly is helping SIP-using designers decide what to negotiate with O/A and what to negotiate with prefs/caps. Someone even asked me yesterday why we don't just do everything with prefs/caps and deprecate O/A. So, if somebody out there is looking for a meaningful task, it might be reasonable to undertake a clear explanation of the relationship and usage of these related mechanisms. Perhaps we should see what kind of consensus we have here on the list . . . Here's a debate to consider: Let's say I want to make a voice push-to-talk call to somebody. This means I'm wanting to use push-to-talk behavior, and negotiate a floor control protocol and voice codec to be used within the call. We seem to have consensus that the voice codec, port numbers, and IP addresses involved are to be described in SDP and negotiated in O/A mode. That's "traditional SIP". How about the floor control protocol to use? Prefs/Caps or O/A? My personal guess is that this is O/A. And here's the hard one -- Is the desire for push-to-talk behavior something that should be expressed as caller preferences and matched by the routing function to a termination whose callee-caps indicate compatibility, or is it something that should be described in an SDP offer/answer? Or something else entirely? -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Apr 28 12:22:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25681 for ; Wed, 28 Apr 2004 12:22: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 1BIrd6-0004pV-Uz for sipping-archive@odin.ietf.org; Wed, 28 Apr 2004 12:09:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SG9mg9018561 for sipping-archive@odin.ietf.org; Wed, 28 Apr 2004 12:09:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrQj-0001ek-Pp for sipping-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 11:57: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 LAA23839 for ; Wed, 28 Apr 2004 11:56: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 1BIrQh-0002ID-9b for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 11:56:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrOL-0001lw-00 for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 11:54:35 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIrMF-0001JL-00 for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 11:52:23 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIrEJ-0002bg-4F for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 11:44:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqmp-0007m4-Fx; Wed, 28 Apr 2004 11:15:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqfv-0006r0-E2 for sipping@optimus.ietf.org; Wed, 28 Apr 2004 11:08: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 LAA20617 for ; Wed, 28 Apr 2004 11: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 1BIqfV-0005Rv-C4 for sipping@ietf.org; Wed, 28 Apr 2004 11:08:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqeW-0005NM-00 for sipping@ietf.org; Wed, 28 Apr 2004 11:07:13 -0400 Received: from [204.57.52.4] (helo=commserver.iperia.com) by ietf-mx with esmtp (Exim 4.12) id 1BIqdY-0005FJ-00 for sipping@ietf.org; Wed, 28 Apr 2004 11:06:12 -0400 Received: by COMMSERVER with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Apr 2004 11:05:31 -0400 Message-ID: <7CA1B27CD297D811A17100B0D024CF710477DF@COMMSERVER> From: Gordon Ledgard To: "'Dean Willis'" , Paul Kyzivat , sipping@ietf.org Subject: RE: [Sipping] Application identification with callee caps/caller preferences (Was SIP) Date: Wed, 28 Apr 2004 11:05:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Isn't the difference between O/A and Pref/Caps simply the difference between media negotiation (transport layer) and application capability? I would not have thought this to be a complicated distinction. O/A says "I have all the hardware and infrastructure to support this". Pref/Caps says "I'm not set up to deal with this (I do not have certain features loaded) or I don't want to right now." Life is a grey area. :) Gordon Ledgard IPeria, Inc. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, April 28, 2004 9:06 AM > To: Paul Kyzivat; sipping@ietf.org > Subject: [Sipping] Application identification with callee caps/caller > preferences (Was SIP) > > > > Moving to SIPPING, because that's where this belongs. > > Following up on a previous thread: > > Paul Kyzivat wrote: > > > Dean Willis wrote > >> Of course, I'm still deeply confused between: > >> 1) preference/capability negotiation enabled by offer/answer > >> 2) preference/capability negotiation enabled by > callee-caps/caller-pref. > > > > Forking and offer/answer provide a partial solution. But > offer/answer > > doesn't give you a way to say you don't want the call unless your > > offered media are accepted. At least not an easy way. > Conceivably some > > new extension to preconditions could be made to handle this kind of > > thing. Lacking that you run the risk of having an unsuitable device > > answer, even if there is a suitable device present. > > > > Callerprefs gives you an increased likelihood that you will > end up with > > a suitable device. > > The above is a "good start". > > One of the challenges I'm faced with regularly is helping SIP-using > designers decide what to negotiate with O/A and what to > negotiate with > prefs/caps. > > Someone even asked me yesterday why we don't just do everything with > prefs/caps and deprecate O/A. > > So, if somebody out there is looking for a meaningful task, > it might be > reasonable to undertake a clear explanation of the relationship and > usage of these related mechanisms. Perhaps we should see what kind of > consensus we have here on the list . . . > > Here's a debate to consider: Let's say I want to make a voice > push-to-talk call to somebody. This means I'm wanting to use > push-to-talk behavior, and negotiate a floor control protocol > and voice > codec to be used within the call. > > We seem to have consensus that the voice codec, port numbers, and IP > addresses involved are to be described in SDP and negotiated in O/A > mode. That's "traditional SIP". > > How about the floor control protocol to use? Prefs/Caps or O/A? My > personal guess is that this is O/A. > > And here's the hard one -- Is the desire for push-to-talk behavior > something that should be expressed as caller preferences and > matched by > the routing function to a termination whose callee-caps indicate > compatibility, or is it something that should be described in an SDP > offer/answer? Or something else entirely? > > -- > Dean > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Apr 28 12:38: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 MAA27198 for ; Wed, 28 Apr 2004 12:38: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 1BIrun-00019T-7v for sipping-archive@odin.ietf.org; Wed, 28 Apr 2004 12:28:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SGS5Nb004422 for sipping-archive@odin.ietf.org; Wed, 28 Apr 2004 12:28:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrhE-0006Rt-Nw for sipping-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 12:14: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 MAA24984 for ; Wed, 28 Apr 2004 12:14: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 1BIrhB-0003uW-SP for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 12:14:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrgE-0003kl-00 for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 12:13:03 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIrfG-0003ca-01 for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 12:12:02 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIrWe-0003LT-2Q for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 12:03:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrLy-0000GN-Jl; Wed, 28 Apr 2004 11:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIr60-0002kv-Pv for sipping@optimus.ietf.org; Wed, 28 Apr 2004 11:35: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 LAA22072 for ; Wed, 28 Apr 2004 11:35: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 1BIr5y-0007l1-AO for sipping@ietf.org; Wed, 28 Apr 2004 11:35:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIr54-0007fN-00 for sipping@ietf.org; Wed, 28 Apr 2004 11:34:38 -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 1BIr4F-0007UZ-00 for sipping@ietf.org; Wed, 28 Apr 2004 11:33:47 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 28 Apr 2004 07:46:25 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SFXFW9005881; Wed, 28 Apr 2004 08:33:16 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOM09753; Wed, 28 Apr 2004 08:33:14 -0700 (PDT) Date: Wed, 28 Apr 2004 11:33:13 -0400 From: David Oran To: Dean Willis , Paul Kyzivat , sipping@ietf.org Subject: Re: [Sipping] Application identification with callee caps/caller preferences (Was SIP) Message-ID: In-Reply-To: <408FAC28.3010005@softarmor.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEF029E151D@esebe004.ntc.nokia.com > <408E841B.70900@softarmor.com> <408E9687.2090008@cisco.com> <408FAC28.3010005@softarmor.com> X-Mailer: Mulberry/3.1.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Wednesday, April 28, 2004 8:05 AM -0500 Dean Willis wrote: > [snip] > Here's a debate to consider: Let's say I want to make a voice > push-to-talk call to somebody. This means I'm wanting to use push-to-talk > behavior, and negotiate a floor control protocol and voice codec to be > used within the call. > > We seem to have consensus that the voice codec, port numbers, and IP > addresses involved are to be described in SDP and negotiated in O/A mode. > That's "traditional SIP". > and traditional everything else multimedia as well... > How about the floor control protocol to use? Prefs/Caps or O/A? My > personal guess is that this is O/A. > I'd say O/A as well, since for me the dividing line is: - am I singaling WHAT media I want to do or can do: Callerprefs/calleecaps - am I signaling HOW I can do it (codec, protocol, etc.): O/A So, I guess I'd express the need to a cnference with floor control through callerprefs and negotiate the floor control protocol and parameters thereof with O/A. > And here's the hard one -- Is the desire for push-to-talk behavior > something that should be expressed as caller preferences and matched by > the routing function to a termination whose callee-caps indicate > compatibility, or is it something that should be described in an SDP > offer/answer? Or something else entirely? > What exactly is "push-to-talk" as an application? Is it a half-duplex session? If so, I suspect I'd signal that I want a half-duplex session in the prefs/caps. Whether push-to-talk is just a form of floor control is, I think, the interesting design question. Dave. > -- > Dean > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Apr 28 13:31: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 NAA01447 for ; Wed, 28 Apr 2004 13:31: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 1BIsnD-0006Sf-Hi for sipping-archive@odin.ietf.org; Wed, 28 Apr 2004 13:24:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SHOJsT024832 for sipping-archive@odin.ietf.org; Wed, 28 Apr 2004 13:24:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsbd-00034U-0l for sipping-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:12: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 NAA29580 for ; Wed, 28 Apr 2004 13:12: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 1BIsbZ-0007cj-Nw for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 13:12:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsac-0007ZN-00 for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 13:11:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsZe-0007We-00 for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 13:10:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsTZ-0000Tx-3M; Wed, 28 Apr 2004 13:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsCy-0005OL-3F for sipping@optimus.ietf.org; Wed, 28 Apr 2004 12:46: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 MAA27742 for ; Wed, 28 Apr 2004 12:46: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 1BIsCv-00062i-0Z for sipping@ietf.org; Wed, 28 Apr 2004 12:46:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsBx-0005yh-00 for sipping@ietf.org; Wed, 28 Apr 2004 12:45:50 -0400 Received: from pmesmtp04.mci.com ([199.249.20.36]) by ietf-mx with esmtp (Exim 4.12) id 1BIsB2-0005vG-00 for sipping@ietf.org; Wed, 28 Apr 2004 12:44:52 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HWW00M2V3ELKE@firewall.mci.com> for sipping@ietf.org; Wed, 28 Apr 2004 16:35:09 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HWW001013D71J@pmismtp01.mcilink.com>; Wed, 28 Apr 2004 16:35:09 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.112.240]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HWW000E83EAQF@pmismtp01.mcilink.com>; Wed, 28 Apr 2004 16:35:05 +0000 (GMT) Date: Wed, 28 Apr 2004 11:34:57 -0500 From: Alan Johnston Subject: Re: [Sipping] Application identification with callee caps/caller preferences (Was SIP) In-reply-to: X-Sender: Alan.Johnston@pop.mcilink.com To: David Oran , Dean Willis , Paul Kyzivat , sipping@ietf.org Message-id: <5.2.1.1.0.20040428112837.038b6a58@pop.mcilink.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <408FAC28.3010005@softarmor.com> <0C1353ABB1DEB74DB067ADFF749C4EEF029E151D@esebe004.ntc.nokia.com> <408E841B.70900@softarmor.com> <408E9687.2090008@cisco.com> <408FAC28.3010005@softarmor.com> Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 11:33 AM 4/28/2004 -0400, David Oran wrote: >--On Wednesday, April 28, 2004 8:05 AM -0500 Dean Willis > wrote: > >[snip] >>Here's a debate to consider: Let's say I want to make a voice >>push-to-talk call to somebody. This means I'm wanting to use push-to-talk >>behavior, and negotiate a floor control protocol and voice codec to be >>used within the call. >> >>We seem to have consensus that the voice codec, port numbers, and IP >>addresses involved are to be described in SDP and negotiated in O/A mode. >>That's "traditional SIP". >and traditional everything else multimedia as well... > >>How about the floor control protocol to use? Prefs/Caps or O/A? My >>personal guess is that this is O/A. >I'd say O/A as well, since for me the dividing line is: >- am I singaling WHAT media I want to do or can do: Callerprefs/calleecaps >- am I signaling HOW I can do it (codec, protocol, etc.): O/A > >So, I guess I'd express the need to a cnference with floor control through >callerprefs and negotiate the floor control protocol and parameters >thereof with O/A. It depends. SIP is often used to establish multimedia sessions, which result in RTP flows. If the floor control "session" is established using SIP, then O/A applies. However, if floor control is not established through SIP but is a parallel control stream, then what is needed is a conference focus that supports the required floor control protocol, and an ability for the focus to provide a URI to the user to establish this separate channel. In this case, then a Require/420 exchange is appropriate. Thanks, Alan Johnston MCI sip:alan@sipstation.com >>And here's the hard one -- Is the desire for push-to-talk behavior >>something that should be expressed as caller preferences and matched by >>the routing function to a termination whose callee-caps indicate >>compatibility, or is it something that should be described in an SDP >>offer/answer? Or something else entirely? >What exactly is "push-to-talk" as an application? Is it a half-duplex >session? If so, I suspect I'd signal that I want a half-duplex session in >the prefs/caps. Whether push-to-talk is just a form of floor control is, I >think, the interesting design question. > >Dave. > >>-- >>Dean >> >> >> >> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP > > > > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 28 13:37:02 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 NAA01983 for ; Wed, 28 Apr 2004 13:37: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 1BIssG-0007av-3d for sipping-archive@odin.ietf.org; Wed, 28 Apr 2004 13:29:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SHTW9M029188 for sipping-archive@odin.ietf.org; Wed, 28 Apr 2004 13:29:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsiQ-00052J-Et for sipping-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:19: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 NAA00207 for ; Wed, 28 Apr 2004 13:19: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 1BIsiN-0000PZ-6M for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 13:19:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIshV-0000MK-00 for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 13:18:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsgg-0000HT-00 for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 13:17:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsUZ-0000ut-Em; Wed, 28 Apr 2004 13:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsIG-0006Wh-3V for sipping@optimus.ietf.org; Wed, 28 Apr 2004 12:52: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 MAA28238 for ; Wed, 28 Apr 2004 12:52: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 1BIsID-0006R4-3F for sipping@ietf.org; Wed, 28 Apr 2004 12:52:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsHJ-0006OT-00 for sipping@ietf.org; Wed, 28 Apr 2004 12:51:21 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BIsGT-0006Ja-00 for sipping@ietf.org; Wed, 28 Apr 2004 12:50:29 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 28 Apr 2004 09:51:21 -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 i3SGnuW9006036; Wed, 28 Apr 2004 09:49:56 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOM18942; Wed, 28 Apr 2004 09:49:54 -0700 (PDT) Date: Wed, 28 Apr 2004 12:49:53 -0400 From: David Oran To: Alan Johnston , Dean Willis , Paul Kyzivat , sipping@ietf.org Subject: Re: [Sipping] Application identification with callee caps/caller preferences (Was SIP) Message-ID: <5A9BEB1D2CAE9D222122B03F@[10.32.245.156]> In-Reply-To: <5.2.1.1.0.20040428112837.038b6a58@pop.mcilink.com> References: <408FAC28.3010005@softarmor.com> <0C1353ABB1DEB74DB067ADFF749C4EEF029E151D@esebe004.ntc.nokia.com> <408E841B.70900@softarmor.com> <408E9687.2090008@cisco.com> <408FAC28.3010005@softarmor.com> <5.2.1.1.0.20040428112837.038b6a58@pop.mcilink.com> X-Mailer: Mulberry/3.1.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Wednesday, April 28, 2004 11:34 AM -0500 Alan Johnston wrote: > At 11:33 AM 4/28/2004 -0400, David Oran wrote: > [snip] >> So, I guess I'd express the need to a cnference with floor control >> through callerprefs and negotiate the floor control protocol and >> parameters thereof with O/A. > > It depends. > > SIP is often used to establish multimedia sessions, which result in RTP > flows. If the floor control "session" is established using SIP, then O/A > applies. > Sure. I agree. > However, if floor control is not established through SIP but is a > parallel control stream, then what is needed is a conference focus that > supports the required floor control protocol, and an ability for the > focus to provide a URI to the user to establish this separate channel. > Yes, I agree. > In this case, then a Require/420 exchange is appropriate. > It seems that if the two protocols are "parallel" then I'm not sure SIP should have any say on how the state synchronization is done. Using requires/420 is one possibility, of course, an alternative might be using SDP preconditions. Dave. > Thanks, > Alan Johnston > MCI > sip:alan@sipstation.com > >>> And here's the hard one -- Is the desire for push-to-talk behavior >>> something that should be expressed as caller preferences and matched by >>> the routing function to a termination whose callee-caps indicate >>> compatibility, or is it something that should be described in an SDP >>> offer/answer? Or something else entirely? >> What exactly is "push-to-talk" as an application? Is it a half-duplex >> session? If so, I suspect I'd signal that I want a half-duplex session >> in the prefs/caps. Whether push-to-talk is just a form of floor control >> is, I think, the interesting design question. >> >> Dave. >> >>> -- >>> Dean >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >> >> >> >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Apr 28 14:50: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 OAA07021 for ; Wed, 28 Apr 2004 14:50:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItzX-0007We-01 for sipping-archive@odin.ietf.org; Wed, 28 Apr 2004 14:41:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SIf65V028924 for sipping-archive@odin.ietf.org; Wed, 28 Apr 2004 14:41:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIttT-0005JT-UD for sipping-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 14:34: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 OAA06005 for ; Wed, 28 Apr 2004 14:34: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 1BIttQ-0005nb-1P for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 14:34:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItsD-0005dh-00 for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 14:33:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BItrs-0005aV-01 for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 14:33:12 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BItr2-0005qF-Tx for sipping-web-archive@ietf.org; Wed, 28 Apr 2004 14:32:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIth4-0002V2-6b; Wed, 28 Apr 2004 14:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItcb-0001XJ-1g for sipping@optimus.ietf.org; Wed, 28 Apr 2004 14:17: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 OAA05325 for ; Wed, 28 Apr 2004 14:17: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 1BItcX-0004vV-AL for sipping@ietf.org; Wed, 28 Apr 2004 14:17:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItbe-0004sY-00 for sipping@ietf.org; Wed, 28 Apr 2004 14:16:27 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BItap-0004nS-00 for sipping@ietf.org; Wed, 28 Apr 2004 14:15:35 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 28 Apr 2004 11:14:01 -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 i3SIF16L017084; Wed, 28 Apr 2004 14:15:02 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHY20157; Wed, 28 Apr 2004 14:14:59 -0400 (EDT) Message-ID: <408FF4A3.4070205@cisco.com> Date: Wed, 28 Apr 2004 14:14:59 -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: Dean Willis CC: sipping@ietf.org References: <0C1353ABB1DEB74DB067ADFF749C4EEF029E151D@esebe004.ntc.nokia.com > <408E841B.70900@softarmor.com> <408E9687.2090008@cisco.com> <408FAC28.3010005@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Application identification with callee caps/caller preferences (Was SIP) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dean Willis wrote: > > Moving to SIPPING, because that's where this belongs. > > Following up on a previous thread: > > Paul Kyzivat wrote: > > > Dean Willis wrote > >>> Of course, I'm still deeply confused between: >>> 1) preference/capability negotiation enabled by offer/answer >>> 2) preference/capability negotiation enabled by callee-caps/caller-pref. >> >> >> Forking and offer/answer provide a partial solution. But offer/answer >> doesn't give you a way to say you don't want the call unless your >> offered media are accepted. At least not an easy way. Conceivably some >> new extension to preconditions could be made to handle this kind of >> thing. Lacking that you run the risk of having an unsuitable device >> answer, even if there is a suitable device present. >> >> Callerprefs gives you an increased likelihood that you will end up >> with a suitable device. > > > The above is a "good start". > > One of the challenges I'm faced with regularly is helping SIP-using > designers decide what to negotiate with O/A and what to negotiate with > prefs/caps. > > Someone even asked me yesterday why we don't just do everything with > prefs/caps and deprecate O/A. Well, that would be silly. Prefs/caps don't provide sufficient detail to establish a media session. Clearly prefs/caps is the way to go for things that aren't expressed at all in O/A - things that don't have to do with the media streams themselves. There is an area of overlap around media-related things. IMO it would be better to enhance O/A to cover those cases. For instance, saying "I only want a session if I can have both audio and video", or "I want an audio session but I'm not yet prepared to tell you where to send it - please respond, if you can, with an audio offer". This sort of thing *could* be done with preconditions. But there seems to be a (justifiable) reluctance to invent new uses for preconditions. (Or even to use the existing ones.) Prefs/caps provides *some" of this functionality using what is perceived to be a lighter weight mechanism. In the absence of something better, it is reasonable to use it. > So, if somebody out there is looking for a meaningful task, it might be > reasonable to undertake a clear explanation of the relationship and > usage of these related mechanisms. Perhaps we should see what kind of > consensus we have here on the list . . . Does the above help? > Here's a debate to consider: Let's say I want to make a voice > push-to-talk call to somebody. This means I'm wanting to use > push-to-talk behavior, and negotiate a floor control protocol and voice > codec to be used within the call. > > We seem to have consensus that the voice codec, port numbers, and IP > addresses involved are to be described in SDP and negotiated in O/A > mode. That's "traditional SIP". > > How about the floor control protocol to use? Prefs/Caps or O/A? My > personal guess is that this is O/A. I need to know more about how the floor control is intended to work before I would begin to answer this. > And here's the hard one -- Is the desire for push-to-talk behavior > something that should be expressed as caller preferences and matched by > the routing function to a termination whose callee-caps indicate > compatibility, or is it something that should be described in an SDP > offer/answer? Or something else entirely? I don't think this can be done entirely with O/A if you really require the push-to-talk behavior, at least for any plausible definition of push-to-talk that I can imagine. I think anything you might offer would be answered by a regular sip phone, ignoring/refusing the push-to-talk features. 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 Apr 29 04:35:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13887 for ; Thu, 29 Apr 2004 04:35:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6y7-0002fi-U4 for sipping-archive@odin.ietf.org; Thu, 29 Apr 2004 04:32:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T8WV3h010270 for sipping-archive@odin.ietf.org; Thu, 29 Apr 2004 04:32:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6tm-0001Ta-9t for sipping-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 04:28: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 EAA13450 for ; Thu, 29 Apr 2004 04:27:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ6te-0006dh-Fy for sipping-web-archive@ietf.org; Thu, 29 Apr 2004 04:27:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ6si-0006U2-00 for sipping-web-archive@ietf.org; Thu, 29 Apr 2004 04:26:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ6ro-0006KG-00 for sipping-web-archive@ietf.org; Thu, 29 Apr 2004 04:26:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6m9-0008NH-K1; Thu, 29 Apr 2004 04:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6cO-0005iB-C1 for sipping@optimus.ietf.org; Thu, 29 Apr 2004 04:10: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 EAA12588 for ; Thu, 29 Apr 2004 04:09: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 1BJ6cG-0003XV-Nh for sipping@ietf.org; Thu, 29 Apr 2004 04:09:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ6bF-0003N1-00 for sipping@ietf.org; Thu, 29 Apr 2004 04:08:54 -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 1BJ6aH-0003DQ-00 for sipping@ietf.org; Thu, 29 Apr 2004 04:07:53 -0400 Received: from softarmor.com (port-213-160-6-4.reverse.qsc.de [213.160.6.4]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i3T88Pu4007312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Apr 2004 03:08:28 -0500 Message-ID: <4090B7A5.4020607@softarmor.com> Date: Thu, 29 Apr 2004 03:07:01 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org CC: Rohan Mahy , Gonzalo Camarillo , Allison Mankin References: <408F9D5F.6020407@softarmor.com> In-Reply-To: <408F9D5F.6020407@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: WGLC for draft-ietf-sipping-transc-3pcc-00 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'd like to announce working group last call for the 3PCC transcoding draft: draft-ietf-sipping-transc-3pcc-00.txt This last call period starts immediately and will run through May 15, 2004. There are two known minor textual issues with this draft which will be corrected following the WGLC comments: 1) Split the references into normative and non-normative. 2) Correct the example domains -- s/domain.com/example.com. Please review this draft and get your comments, if any, back to the author (and to the list, if reasonable) as soon as possible. As I understand it, we'll be requesting that this draft be published as an informational RFC. The procedure for informationals seems to be evolving, and my understanding is that they will now receive significantly less scrutiny from the IESG. So, we need to make sure we do a VERY thorough job of reviewing this in the working group. 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 Thu Apr 29 15:27:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22616 for ; Thu, 29 Apr 2004 15:27:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH87-0005Kw-LV for sipping-archive@odin.ietf.org; Thu, 29 Apr 2004 15:23:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJNVt0020515 for sipping-archive@odin.ietf.org; Thu, 29 Apr 2004 15:23:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGra-0003FW-CH for sipping-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:06: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 PAA20234 for ; Thu, 29 Apr 2004 15:06: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 1BJGrU-00036y-2s for sipping-web-archive@ietf.org; Thu, 29 Apr 2004 15:06:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGqX-00034n-00 for sipping-web-archive@ietf.org; Thu, 29 Apr 2004 15:05:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJGpq-00032h-00 for sipping-web-archive@ietf.org; Thu, 29 Apr 2004 15:04:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGgN-0003iv-Bj; Thu, 29 Apr 2004 14:54:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFRf-0000sr-Ad for sipping@optimus.ietf.org; Thu, 29 Apr 2004 13:35: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 NAA15399 for ; Thu, 29 Apr 2004 13:35: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 1BJFRZ-0002Ym-Tk for sipping@ietf.org; Thu, 29 Apr 2004 13:35:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFQg-0002Hn-00 for sipping@ietf.org; Thu, 29 Apr 2004 13:34:35 -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 1BJFQ5-0001zb-00 for sipping@ietf.org; Thu, 29 Apr 2004 13:33:58 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Apr 2004 09:46:50 +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 i3THXPWB011611; Thu, 29 Apr 2004 10:33:28 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIA70358; Thu, 29 Apr 2004 13:33:24 -0400 (EDT) Message-ID: <40913C65.3050305@cisco.com> Date: Thu, 29 Apr 2004 13:33:25 -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: Dean Willis CC: sipping@ietf.org, Rohan Mahy , Gonzalo Camarillo , Allison Mankin Subject: Re: [Sipping] Re: WGLC for draft-ietf-sipping-transc-3pcc-00 References: <408F9D5F.6020407@softarmor.com> <4090B7A5.4020607@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Somehow I missed this draft altogether. (Asleep at the wheel I guess.) I see a couple of limitations in the approaches recommended, and have some ideas for how to fix them: 3.2 (Figure 2): This may be appropriate if B wants to hide its actual capabilities and expose T's instead. But suppose A is also deaf and also prefers text? In that case you might end up with two transcoders in the call. (Although there is no flow here that would cause that.) Also, the transcoding service may cost something so it would be good to delay requesting it until it is known to be needed. I understand that there is a desire to offer voice, because without that a call may never be established a dumb voice peer. As an alternative, if T is flexible in what codecs it can use, and B knows what those are, it can respons with an initial offer that includes a text stream as well as a voice stream that is black-holed. (C=0). That doesn't actually permit voice communication but offers voice and gives a a chance to pick what it wants. And it doesn't yet bother T. Then, if A's answer accepts the voice, B will invite T and then reinvite A to splice the streams. If A accepts text and refuses voice, all is cool. 3.3 (Figure 3): This again will be suboptimal if B prefers text. A perhaps more serious problem is that the handshake between A and T may unnecessarily restrict the set of codecs that A offers B. A may offer a bunch to T, but T may only be able to use one at a time, and so may restrict its answer to a single codec even though it could also do one of the others. Both of these issues could be solved using the same tactic I just suggested above - offering test and black-holed voice. This however might result in clipping B, who doesn't know the situation and is likely to start talking immediately. This could be dealt with using PRACK and UPDATE to refine the media stream selections before the call is answered. An alternative that works reasonably well with my suggetion above is for A to initiate the call with an offerless invite. If the offer that comes back contains only voice, then A can invite T at that time. Paul Dean Willis wrote: > > I'd like to announce working group last call for the 3PCC transcoding > draft: > > draft-ietf-sipping-transc-3pcc-00.txt > > This last call period starts immediately and will run through May 15, 2004. > > There are two known minor textual issues with this draft which will be > corrected following the WGLC comments: > > 1) Split the references into normative and non-normative. > > 2) Correct the example domains -- s/domain.com/example.com. > > Please review this draft and get your comments, if any, back to the > author (and to the list, if reasonable) as soon as possible. > > As I understand it, we'll be requesting that this draft be published as > an informational RFC. The procedure for informationals seems to be > evolving, and my understanding is that they will now receive > significantly less scrutiny from the IESG. So, we need to make sure we > do a VERY thorough job of reviewing this in the working group. > > 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 Apr 29 16:01: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 QAA24917 for ; Thu, 29 Apr 2004 16:01: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 1BJHa1-0004us-Eb for sipping-archive@odin.ietf.org; Thu, 29 Apr 2004 15:52:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJqL4s018893 for sipping-archive@odin.ietf.org; Thu, 29 Apr 2004 15:52:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHQc-00022O-BZ for sipping-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15: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 PAA23790 for ; Thu, 29 Apr 2004 15:42: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 1BJHQV-0005dW-Oz for sipping-web-archive@ietf.org; Thu, 29 Apr 2004 15:42:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJHPg-0005ZV-00 for sipping-web-archive@ietf.org; Thu, 29 Apr 2004 15:41:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJHP7-0005Uo-00 for sipping-web-archive@ietf.org; Thu, 29 Apr 2004 15:41:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH9y-0005su-5b; Thu, 29 Apr 2004 15:25:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGyM-0007W2-PI for sipping@optimus.ietf.org; Thu, 29 Apr 2004 15:13: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 PAA20988 for ; Thu, 29 Apr 2004 15:13: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 1BJGyG-0003Px-E8 for sipping@ietf.org; Thu, 29 Apr 2004 15:13:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGxI-0003Mh-00 for sipping@ietf.org; Thu, 29 Apr 2004 15:12:21 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJGwL-0003Hr-00 for sipping@ietf.org; Thu, 29 Apr 2004 15:11: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 i3TJ9bLc004220; Thu, 29 Apr 2004 14:09:37 -0500 (CDT) Received: from ericsson.com (sealwa01m009.sw.ericsson.se [130.100.251.138]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQWKQLKW; Thu, 29 Apr 2004 14:09:32 -0500 Message-ID: <409152F0.70209@ericsson.com> Date: Thu, 29 Apr 2004 22:09:36 +0300 X-Sybari-Trust: f23af5f2 c38aee8b 00db2f9f 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> In-Reply-To: <40913C65.3050305@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul, thanks for your comments. The flows you are referring to describe how to invoke a transcoder by the caller and by the callee. Nevertheless, this document does not recommend *when* you have to invoke it. This is dealt with by the framework document: draft-ietf-sipping-transc-framework-00.txt In particular, the framework says: " 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." I guess the paragraph above addresses your concern. In any event, if you want to see more explanatory text included in any of these drafts, let me know. Thanks, Gonzalo Paul Kyzivat wrote: > Somehow I missed this draft altogether. (Asleep at the wheel I guess.) > > I see a couple of limitations in the approaches recommended, and have > some ideas for how to fix them: > > 3.2 (Figure 2): > > This may be appropriate if B wants to hide its actual capabilities and > expose T's instead. But suppose A is also deaf and also prefers text? In > that case you might end up with two transcoders in the call. (Although > there is no flow here that would cause that.) Also, the transcoding > service may cost something so it would be good to delay requesting it > until it is known to be needed. > > I understand that there is a desire to offer voice, because without that > a call may never be established a dumb voice peer. > > As an alternative, if T is flexible in what codecs it can use, and B > knows what those are, it can respons with an initial offer that includes > a text stream as well as a voice stream that is black-holed. (C=0). That > doesn't actually permit voice communication but offers voice and gives a > a chance to pick what it wants. And it doesn't yet bother T. > > Then, if A's answer accepts the voice, B will invite T and then reinvite > A to splice the streams. If A accepts text and refuses voice, all is cool. > > 3.3 (Figure 3): > > This again will be suboptimal if B prefers text. A perhaps more serious > problem is that the handshake between A and T may unnecessarily restrict > the set of codecs that A offers B. A may offer a bunch to T, but T may > only be able to use one at a time, and so may restrict its answer to a > single codec even though it could also do one of the others. > > Both of these issues could be solved using the same tactic I just > suggested above - offering test and black-holed voice. This however > might result in clipping B, who doesn't know the situation and is likely > to start talking immediately. This could be dealt with using PRACK and > UPDATE to refine the media stream selections before the call is answered. > > An alternative that works reasonably well with my suggetion above is for > A to initiate the call with an offerless invite. If the offer that comes > back contains only voice, then A can invite T at that time. > > Paul > > > Dean Willis wrote: > >> >> I'd like to announce working group last call for the 3PCC transcoding >> draft: >> >> draft-ietf-sipping-transc-3pcc-00.txt >> >> This last call period starts immediately and will run through May 15, >> 2004. >> >> There are two known minor textual issues with this draft which will be >> corrected following the WGLC comments: >> >> 1) Split the references into normative and non-normative. >> >> 2) Correct the example domains -- s/domain.com/example.com. >> >> Please review this draft and get your comments, if any, back to the >> author (and to the list, if reasonable) as soon as possible. >> >> As I understand it, we'll be requesting that this draft be published >> as an informational RFC. The procedure for informationals seems to be >> evolving, and my understanding is that they will now receive >> significantly less scrutiny from the IESG. So, we need to make sure we >> do a VERY thorough job of reviewing this in the working group. >> >> Thanks, >> -- 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 Thu Apr 29 17:32: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 RAA04031 for ; Thu, 29 Apr 2004 17:32: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 1BJIt6-0006PY-8y for sipping-archive@odin.ietf.org; Thu, 29 Apr 2004 17:16:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TLG8rr024639 for sipping-archive@odin.ietf.org; Thu, 29 Apr 2004 17:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJIh2-00078o-Jy for sipping-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 17:03: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 RAA01319 for ; Thu, 29 Apr 2004 17:03: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 1BJIgv-0005Yp-C4 for sipping-web-archive@ietf.org; Thu, 29 Apr 2004 17:03:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJIft-0005Vu-00 for sipping-web-archive@ietf.org; Thu, 29 Apr 2004 17:02:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJIey-0005Tc-00 for sipping-web-archive@ietf.org; Thu, 29 Apr 2004 17:01:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJICQ-0002lq-6f; Thu, 29 Apr 2004 16: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 1BJHfy-0006EI-Pv for sipping@optimus.ietf.org; Thu, 29 Apr 2004 15:58: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 PAA24803 for ; Thu, 29 Apr 2004 15:58: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 1BJHfr-0006WM-Tc for sipping@ietf.org; Thu, 29 Apr 2004 15:58:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJHeu-0006TH-00 for sipping@ietf.org; Thu, 29 Apr 2004 15:57: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 1BJHel-0006Qk-00 for sipping@ietf.org; Thu, 29 Apr 2004 15:57:15 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 29 Apr 2004 12:08:56 +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 i3TJukW9013005; Thu, 29 Apr 2004 12:56:46 -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 ASO28616; Thu, 29 Apr 2004 12:55:56 -0700 (PDT) In-Reply-To: <4.3.2.7.2.20040422144516.02607ba8@localhost> References: <4.3.2.7.2.20040422144516.02607ba8@localhost> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Dean Willis , sipping (E-mail) , Rohan Mahy , Hisham Khartabil , Gonzalo Camarillo From: Rohan Mahy Date: Thu, 29 Apr 2004 12:59:05 -0700 To: "James M. Polk" X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Narrowing this to just SIPPING... For E2M: I believe that we will discuss the most fundamental issue of E2M (piggyback vs. redirect) at the interim as part of Session Policy. If we decide this issue, there will be much more work that needs to be done before the WG as a whole can comment on the specifics of any proposed mechanisms. For Emergency: I don't think the working group will be familiar enough with the output of the emergency design team to have a productive discussion at the interim. There were more than a dozen open issues in Korea that the design team had not yet addressed; we should get to the point where the design team has something like 2 or 4 open issues before we use significant meeting time with the WG. thanks, -rohan On Apr 22, 2004, at 12:51 PM, James M. Polk wrote: > What happened to time for Emergency and E2M Security? In Seoul, these > were mentioned as two of the prevailing topic areas for the interim > (along with Session Policy and Exploders). > > At 11:31 AM 4/22/2004 -0400, Hisham Khartabil wrote: >> 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. >> >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf-announce > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Apr 29 18:53: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 SAA08822 for ; Thu, 29 Apr 2004 18:53: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 1BJKDx-00010I-45 for sipping-archive@odin.ietf.org; Thu, 29 Apr 2004 18:41:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TMfjl4003823 for sipping-archive@odin.ietf.org; Thu, 29 Apr 2004 18:41:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJK9v-0008R9-G2 for sipping-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 18:37: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 SAA08211 for ; Thu, 29 Apr 2004 18:37: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 1BJK9n-0004ic-6g for sipping-web-archive@ietf.org; Thu, 29 Apr 2004 18:37:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJK8s-0004fF-00 for sipping-web-archive@ietf.org; Thu, 29 Apr 2004 18:36:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJK8B-0004bj-00 for sipping-web-archive@ietf.org; Thu, 29 Apr 2004 18:35:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJK1e-0006HZ-Cd; Thu, 29 Apr 2004 18:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJtQ-0004u1-OJ for sipping@optimus.ietf.org; Thu, 29 Apr 2004 18:20: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 SAA07380 for ; Thu, 29 Apr 2004 18:20: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 1BJJtI-0003Vc-HF for sipping@ietf.org; Thu, 29 Apr 2004 18:20:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJsN-0003Sd-00 for sipping@ietf.org; Thu, 29 Apr 2004 18:19:28 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BJJrV-0003MJ-00 for sipping@ietf.org; Thu, 29 Apr 2004 18:18:33 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 29 Apr 2004 15:19:15 -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 i3TMHwpI022055; Thu, 29 Apr 2004 18:17:58 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIA98512; Thu, 29 Apr 2004 18:17:58 -0400 (EDT) Message-ID: <40917F16.90604@cisco.com> Date: Thu, 29 Apr 2004 18:17:58 -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> 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, > > thanks for your comments. > > The flows you are referring to describe how to invoke a transcoder by > the caller and by the callee. Nevertheless, this document does not > recommend *when* you have to invoke it. This is dealt with by the > framework document: draft-ietf-sipping-transc-framework-00.txt > > In particular, the framework says: > > " 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." > > I guess the paragraph above addresses your concern. I don't know. Putting it in the framework doesn't make it happen. It has to be in something else other than just the framework before it becomes functional. 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. I would expect that the stuff you quote from the framework would appear as steps in the call flow that determine those capabilities. Also, the framework has nothing to do with the codec restriction problem. > In any event, if you > want to see more explanatory text included in any of these drafts, let > me know. This isn't a hot button of mine. If nobody else is bothered then I will be happy to leave it be. This isn't normative stuff anyway. Paul > Thanks, > > Gonzalo > > Paul Kyzivat wrote: > >> Somehow I missed this draft altogether. (Asleep at the wheel I guess.) >> >> I see a couple of limitations in the approaches recommended, and have >> some ideas for how to fix them: >> >> 3.2 (Figure 2): >> >> This may be appropriate if B wants to hide its actual capabilities and >> expose T's instead. But suppose A is also deaf and also prefers text? >> In that case you might end up with two transcoders in the call. >> (Although there is no flow here that would cause that.) Also, the >> transcoding service may cost something so it would be good to delay >> requesting it until it is known to be needed. >> >> I understand that there is a desire to offer voice, because without >> that a call may never be established a dumb voice peer. >> >> As an alternative, if T is flexible in what codecs it can use, and B >> knows what those are, it can respons with an initial offer that >> includes a text stream as well as a voice stream that is black-holed. >> (C=0). That doesn't actually permit voice communication but offers >> voice and gives a a chance to pick what it wants. And it doesn't yet >> bother T. >> >> Then, if A's answer accepts the voice, B will invite T and then >> reinvite A to splice the streams. If A accepts text and refuses voice, >> all is cool. >> >> 3.3 (Figure 3): >> >> This again will be suboptimal if B prefers text. A perhaps more >> serious problem is that the handshake between A and T may >> unnecessarily restrict the set of codecs that A offers B. A may offer >> a bunch to T, but T may only be able to use one at a time, and so may >> restrict its answer to a single codec even though it could also do one >> of the others. >> >> Both of these issues could be solved using the same tactic I just >> suggested above - offering test and black-holed voice. This however >> might result in clipping B, who doesn't know the situation and is >> likely to start talking immediately. This could be dealt with using >> PRACK and UPDATE to refine the media stream selections before the call >> is answered. >> >> An alternative that works reasonably well with my suggetion above is >> for A to initiate the call with an offerless invite. If the offer that >> comes back contains only voice, then A can invite T at that time. >> >> Paul >> >> >> Dean Willis wrote: >> >>> >>> I'd like to announce working group last call for the 3PCC transcoding >>> draft: >>> >>> draft-ietf-sipping-transc-3pcc-00.txt >>> >>> This last call period starts immediately and will run through May 15, >>> 2004. >>> >>> There are two known minor textual issues with this draft which will be >>> corrected following the WGLC comments: >>> >>> 1) Split the references into normative and non-normative. >>> >>> 2) Correct the example domains -- s/domain.com/example.com. >>> >>> Please review this draft and get your comments, if any, back to the >>> author (and to the list, if reasonable) as soon as possible. >>> >>> As I understand it, we'll be requesting that this draft be published >>> as an informational RFC. The procedure for informationals seems to be >>> evolving, and my understanding is that they will now receive >>> significantly less scrutiny from the IESG. So, we need to make sure >>> we do a VERY thorough job of reviewing this in the working group. >>> >>> 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 Fri Apr 30 06:06: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 GAA07771 for ; Fri, 30 Apr 2004 06:06: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 1BJUpZ-0007yg-TV for sipping-archive@odin.ietf.org; Fri, 30 Apr 2004 06:01:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UA1H54030662 for sipping-archive@odin.ietf.org; Fri, 30 Apr 2004 06:01:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJUoL-0007oZ-B5 for sipping-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 06:00: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 FAA07342 for ; Fri, 30 Apr 2004 05:59: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 1BJUoE-0003ts-9p for sipping-web-archive@ietf.org; Fri, 30 Apr 2004 05:59:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJUnK-0003kP-00 for sipping-web-archive@ietf.org; Fri, 30 Apr 2004 05:58:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJUmo-0003bh-00 for sipping-web-archive@ietf.org; Fri, 30 Apr 2004 05:58:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJUfi-0006bD-Uk; Fri, 30 Apr 2004 05:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJUcj-000615-Hw for sipping@optimus.ietf.org; Fri, 30 Apr 2004 05:48: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 FAA06690 for ; Fri, 30 Apr 2004 05:47: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 1BJUcc-0001ng-DB for sipping@ietf.org; Fri, 30 Apr 2004 05:47:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJUbd-0001d4-00 for sipping@ietf.org; Fri, 30 Apr 2004 05:46:54 -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 1BJUan-0001Tu-00 for sipping@ietf.org; Fri, 30 Apr 2004 05:46:02 -0400 Received: from softarmor.com (port-213-160-6-4.reverse.qsc.de [213.160.6.4]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i3U9kpu4013740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Apr 2004 04:46:56 -0500 Message-ID: <4092202F.2030303@softarmor.com> Date: Fri, 30 Apr 2004 04:45:19 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 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 References: <408F9D5F.6020407@softarmor.com> <4090B7A5.4020607@softarmor.com> <40913C65.3050305@cisco.com> <409152F0.70209@ericsson.com> <40917F16.90604@cisco.com> In-Reply-To: <40917F16.90604@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.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 From exim@www1.ietf.org Fri Apr 30 09:38:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01256 for ; Fri, 30 Apr 2004 09:38: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 1BJY6o-0001YA-2W for sipping-archive@odin.ietf.org; Fri, 30 Apr 2004 09:31:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UDVIfS005958 for sipping-archive@odin.ietf.org; Fri, 30 Apr 2004 09:31:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXzw-0000Pw-2j for sipping-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 09:24: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 JAA00460 for ; Fri, 30 Apr 2004 09:24: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 1BJXzu-0007lR-Hn for sipping-web-archive@ietf.org; Fri, 30 Apr 2004 09:24:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJXyy-0007ak-00 for sipping-web-archive@ietf.org; Fri, 30 Apr 2004 09:23:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJXyf-0007QB-00 for sipping-web-archive@ietf.org; Fri, 30 Apr 2004 09:22:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXpB-0006Ih-7E; Fri, 30 Apr 2004 09:13:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXkQ-0005Ir-I2 for sipping@optimus.ietf.org; Fri, 30 Apr 2004 09:08: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 JAA29666 for ; Fri, 30 Apr 2004 09:08: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 1BJXkP-0004sp-1J for sipping@ietf.org; Fri, 30 Apr 2004 09:08:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJXjT-0004ie-00 for sipping@ietf.org; Fri, 30 Apr 2004 09:07:12 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BJXim-0004Ow-00 for sipping@ietf.org; Fri, 30 Apr 2004 09:06:28 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 30 Apr 2004 06:03:58 -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 i3UD5qYu019385; Fri, 30 Apr 2004 09:05:52 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIB26288; Fri, 30 Apr 2004 09:05:53 -0400 (EDT) Message-ID: <40924F31.6030504@cisco.com> Date: Fri, 30 Apr 2004 09:05:53 -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: Dean Willis CC: Gonzalo Camarillo , 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> 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 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